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

["Philippe Houdoin" <philippe.houdoin@xxxxxxx>]

*cought*

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

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

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/*

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.

Until this PPP *API* is fully ready for public usage, I beg you to put 
headers under private subtree:
/current/headers/private/net/ppp/*        
May I suggest to create a PPP.h main header to include them all?         

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

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.

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.

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:
thru a socket, calling ioctl() with one of the headers/private/net/sys/
sockio.h opcodes allow you to control any kind of stack part, including 
sub-modules.
But... it's messy. Look at src/add-ons/kernel/network/core/
socket.c:socket_ioctl() for details...

From what I've understood, the _IOW[R] macro do some magic encoding of 
the destination ('i' for interfaces manager, 'r' for routes manager, 
's' for socket settings), 
command code and argument size.

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.

6) About:
> The history of a file is much more important once you have a somewhat 
> stable version.
> The history of the development process is often not that important to 
> use at a later point. So if Philippe is too lazy (hehe :-)) I think 
> it's okay to have to look in the test/net/ attic for it (it's not 
> lost, 
> just in an unusual place).
> You could mention the old location in the import comment.

You read my (lazy) mind, Axel. :-)
A comment pointing at src/test/kits/net/ppp/* in the first import log 
message would be enough.
 
7)
> I actually wanted to call the ppp interface module "ppp". 

Good choice.
:-)

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

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

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   



- Philippe

--
Fortune Cookie Says:

"I am not now, and never have been, a girlfriend of Henry Kissinger."
                -- Gloria Steinem