[openbeosnetteam] Re: moving ppp to other location
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Thu, 18 Sep 2003 14:13:46 +0200 CEST
"Waldemar Kornewald" <Waldemar.Kornewald@xxxxxx> wrote:
> > 1) the shared PPP code should not be called/considered a shared
> > library, as our kernel don't and most probably won't support kernel
> > land shared libraries soon, not by R1 but maybe even not by R2...
> Too bad. :(
> Maybe I will have to sit down on my own...but I already planned some
> experiments with file/data management after having finished PPP.
> Why is it so difficult to add shared library support? Cannot we add a
> directory /beos/system/kernellibs where all kernel-only libraries are
> located? Why cannot the userland code be reused for the kernel
> modules?
Just deal with it - you knew it before, or at least we tried to tell
you.
It might come in R2, but certainly not in R1.
> > 2) So far, I suggest we consider it as shared code for all PPP-
> > related
> > *stuffs*, like the static library libprint.a used by several of our
> > printer drivers add-ons.
> >
> > It's why I suggest to move this code here:
> > /current/src/add-ons/kernel/network/ppp/shared/*
>
> The compiled libprint.a binary is put into distro/R1.x86/system/libs,
> right?
> As far as I understood you (mostly Axel) the compiled binary should
> not be
> put there. Or did you intend to make the location for the binary not
> match
> the location for the source of libkernelppp.a?
> If libkernelppp.a will be moved into distro/xxx/system/libs I am
> totally
> fine with network/ppp/shared.
Huh? A .a will *never* end up in /system/libs - if it's a public .a, it
would belong to develop/libs/<arch>/
> I will try to do that.
> The PPP module for our core stack will probably be called
> "ppp_interface_manager".
> I actually wanted to call it "ppp", but this will conflict with the
> subdirectory "ppp" where the module binaries should be put into.
Why not just put the ppp module into network/ppp/?
> And open_module_list() is not used because the module names are
> supplied by
> the user (or GUI preflet) through a driver_settings structure.
You know that there is no direct possibility to say open_module(const
char *path)?
You need to know the module name, not its file name to open it.
> I would like to add a general
> status_t (*control) (uint32 op, void *data, size_t length)
> function to the module interface and some ioctl() ops for calling
> these
> functions from userland. This would mean that ethernet and loopback
> need to
> add a new function to their exported functions (this may be NULL).
> The question is: Should the net_stack_driver or the core module call
> the
> control() function? The net_stack_driver would need an additional
> interface
> to the core module to iterate through all available interface modules
> (at
> the moment only ethernet and loopback). Alternatively, the core could
> export
> an additional control() function which is called by the
> net_stack_driver.
>
> Do we really need the control() function? Cannot we use std_ops()?
std_ops() are kernel private - you just don't touch them.
> Well, some will like it, others will not. ;)
> So, it will be called
> "network/ppp/pppoe/v1"? Did I understand you correctly?
That sounds good.
> I will have to do something against the huge binary size. >200K is
> too much.
> Should the List template be replaced with a BList-like base class for
> void
> pointers and a SimplePointerList that just wraps all BList methods to
> typed
> methods? It could be added to "kernel/util". This could probably
> reduce the
> size to around 120-130K, I think (and hope). But this will be done at
> some
How does your list implementation look like when it is that big?
Anyway, the large file sizes are something you accepted when going the
"I want a shared library" approach.
Adios...
Axel.
Other related posts:
