FreeLists / openbeosnetteam / [openbeosnetteam] Re: moving ppp to other location

["Waldemar Kornewald" <Waldemar.Kornewald@xxxxxx>]

> Okay, time that I read & reply my duty ML posts.
> Sorry for my silence the whole last week, still life issue(s)...

No problem. ;)

> However, here my suggestions about this topic:
>
> 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?

> 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.

> All PPP-related kernel modules (PPP "virtual interface(s)" manager,
> PPPoE, etc) should live under
> /current/src/add-ons/kernel/network/ppp in their own subfolder
> themselves, and refering the shared PPP code.

Agreed.

> Until this PPP *API* is fully ready for public usage, I beg you to put
> headers under private subtree:
> /current/headers/private/net/ppp/*

Okay.

> May I suggest to create a PPP.h main header to include them all?

That should be no problem, but I will call it KPPP.h because there will be a
PPP.h file belonging to the userland API, too. ;)

> >> Why not just headers/private/net/ppp?
> >
> > Because the API is only available for kernel modules. Later there
> > will be a
> > userland API that talks to the pppcontrol driver to query all
> > interfaces.
>
> There is already kernelland only (internals) interfaces/API for network
> modules defined in this very same place.
> Putting headers here or under headers/os/* is only a matter of making
> public or not.
> As already stated by Axel, I myself tend to resist tentation to expand
> public BeOS API before we reach R1.
> Beside that, it's not like we don't release the API, but putting it
> under private/net help to say
> "you fool, beware, it's private API, and it may change at any time!"

Okay, as long as I did not have a look at _every_ possible protocol it is
better to be sure.

> 3) Instead of being shared code, it would have be better if this code
> would have being exported by the main PPP network kernel module.
> But, due to C++ usage, it won't work with R5 or our current kernel.
> So, linking each PPP module, the main included, against a static
> library libkernelppp.a is a valid (and enough from my POV) solution.

Very nice. :)

> 4) I guess your future PPP interface(s) manager module (which should be
> named "network/interfaces/ppp_manager_or_whatever" to be load by the
> current stack) will load his own sub (PPP) modules by calling
> open_module_list("network/ppp").
> However, please match the source code location with the PPP modules
> names as much as possible, it make find them easer.

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.
And open_module_list() is not used because the module names are supplied by
the user (or GUI preflet) through a driver_settings structure.

> 5) Stack sub-modules control from userland. Argh. Well, in fact there
> is a official way, but it's messy to see it looking at the stack code
> today:
[*snip*]
> Even if I would like to move to a less cryptic way to control any stack
> components, it's already possible (or should be).
> If it's lacking, not enough flexible or even broken, the current
> net_stack_driver.c and stack modules should be modified to support a
> working way, but please don't add
> a ppp-only driver where the current net_stack_driver should be the
> single one gateway to network stack from userland.

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()?

> 7)
> > I actually wanted to call the ppp interface module "ppp".
>
> Good choice.
> :-)

Yes, but as I stated above it is not possible because it conflicts with the
directory name for the PPP modules. ;)

> > Where should the
> > modules go then? How should the user know that "network/ppp" is the
> > directory to put modules into?
>
> Because he don't know that a "module", only a add-on.
> Hence the "put into /boot/home/config/add-ons/kernel/network/ppp
> folder, create it if required" instruction.
> Beside that, friendly as BeOS is, you surely won't let the user do it
> himself but package any (new) PPP sub-modules with at least
> a easy symlink named "drop PPPoA file here", or with a installation
> script...

Okay.

> > IMHO, "network/ppp-modules" is much more intuitive.
>
> 'What's in a name?!" will have said David, I guess ;-)
> Fun put apart, I find this naming bad, because your sub modules names
> should then publish this module name:
> "network/ppp-modules/pppoe/v1", which sound ugly...

Well, some will like it, others will not. ;)
So, it will be called
"network/ppp/pppoe/v1"? Did I understand you correctly?

> Beside that, please follow the way network modules are currently named,
> and keep in mind their source location match the binary final location,
> which in kernel modules case imply to have the exact same prefix path
> name.
> You don't want to have your "network/ppp-modules/pppoe" module code in
> src/add-ons/kernel/network/ppp-modules
> when we are that short to agree on putting it under src/add-ons/kernel/
> network/ppp/pppoe, do you?
> ;-p

No, no, no, of course not. ;)

Okay, it seems we are coming to a decision.
Soon, libkernelppp.a should be alpha and there will be a feature-freeze
until all other modules are done.

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
later point because at first it has to become stable and it must be possible
to connect (at least) using a PPPoE connection.
Also, the nameserver implementation needs to be fixed before I can test PPP
extensively (replacing BONE with our netstack). Any status reports? :)

Waldemar