[openbeosnetteam] Re: moving ppp to other location

"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: