[openbeosnetteam] Re: moving ppp to other location

"Waldemar Kornewald" <Waldemar.Kornewald@xxxxxx> wrote:
> > Exactly, and that's why it should go there - it's not a shared 
> > library,
> > it won't be used by anything else than the kernel modules, so it 
> > should
> > be in that directory.
> > Don't regard it as a library, just an archive that your module 
> > links
> > against (just like any other object file).
> Why then is it better to put it into an add-on directory? It is no 
> add-on
> that is loaded by something, but merely an object.

Exactly, an object that's exlusively used by modules, hence that 
directory.
It's the same for i.e. the kernel/core/util directory - its contents 
are build as libkernel_util.a - and are just linked against the kernel 
like everything else, it's just a *part* of the kernel.

> > > This makes people think it is a kernel-loadable module, but it is
> > > not.
> > Well it is part of one. And it will be hard to find if it's in the 
> > src/
> > libs/libkernelppp anyway (and it really doesn't belong there, since 
> > it
> > won't be in /system/libs and is a part of a system component, at 
> > least
> > that's how I understand our repository).
> I would actually put it into /boot/develop/libs/, but we do not have 
> such a
> directory.
> Cannot we add a private libs directory? src/private/libs or 
> something?

Sure we could, but I really don't see a point in doing this - it would 
make finding anything much harder, when everything is spread over the 
repository that much - I wouldn't expect it, there, anyway.

> > AFAIR Philippe (me too, that's why I remember, hopefully correctly)
> > wasn't too fond of the extra PPP driver.
> > Why shouldn't that functionality be served by the core stack 
> > itself?
> Because then you cannot create a new connection from userland. How do 
> you
> want to tell the core stack's PPP module that it should create a new
> connection? There is no interface to the core stack (through which I 
> could
> talk to the PPP stack).
> This is the reason why I need the ppp driver. It does nothing except 
> call
> some of those exported functions (mainly create_interface() and 
> control()).
> I even removed all C++ stuff from those exported functions. The ppp 
> driver
> does not link against libkernelppp.a. It is a light-weight wrapper to 
> the
> ppp_interface_manager (the ppp stack).
> I think after I told you that it is a 3-4k mini-driver you accepted 
> my
> decision.

Well, in that case I don't see a point for another driver even more. 
The main stack *is* accessed by a driver, you can just add the few 
wrapper functions to it directly.
Since we've chosen to put the networking code into modules, we have a 
driver that will be opened from userland in order to talk to the stack, 
anyway.

> The problem is that I cannot call the needed functions from userland. 
> IOCTL
> would be enough for that task, but our network stack does not even 
> have a
> general driver with which you can iterate through the interface 
> modules and
> talk to them (as I said above).
> Or am I wrong here? If I can talk to the manager using an IOCTL-like
> function, then there is no need for the driver.

That seems to explain the issue: you can just add your ioctl() commands 
to the existing driver.

> > So even if it will be a real shared library at one point in the 
> > future
> > (which is obviously not now or in the realm of R1), that location 
> > looks
> > appropriate to me, unless someone convinces me otherwise.
> > Does that make my point a bit clearer?
> Some day we will have shared libs support in the kernel, so it will 
> become a
> real module (at the moment it is only intended to be a module).
> From this point of view I can accept your suggestion.

You still don't like the "is-part-of" explanation I tried to advertise 
above? :-)

> I understand this. I did not really talk with someone about the API 
> because
> there are not many people who understand this protocol (and thus 
> could help
> me). What you can do is look at the API and say: "this is too 
> complicated"
> or "this is bad design" (or "cool!" ;).
> I would really appreciate your suggestions. But until now nobody made 
> a
> _real_ comment on the API (and I cannot expect this from you because 
> you
> would have to read the PPP, PPPoE, IPCP, MP, etc. RFCs to make a real
> comment which is too much). What you could do is take a short look at 
> the
> headers and tell me what you think about it (which is of great help
> already).

I know, having someone have a look at your sources/headers is a great 
thing, and I must admit that I haven't found the time to have a single 
look at your stuff yet.
But ATM I don't think we should make a PPP API public, because I see 
little use in doing so.
And after having had a brief look at it, I have some short remarks:
PPPControl.h:
        PPPC_SET_MTU - I don't think that should be part of the PPP stuff,
                since that's a feature of all other interfaces as well
PPPDefs.h:
        I would have a look if it isn't possible to use standard posix/Be 
error codes
        (but if not, it's fine to introduce new ones).
        PPP_MODULES_PATH shouldn't be "network/ppp-modules", but only
        "network/ppp" - please don't introduce a new naming scheme and add
        redundant suffixes.

As a general note, I think enum names should be lowercase 
(PPP_ENCAPSULATION_LEVEL -> ppp_encapsulation_level, only the contents 
there should be uppercase).
And before introducing another copy of Locker.h, please use the one 
already in our repository, and before introducing something like 
LockerHelper, please use the class that's already there for you: 
BAutolock.
Maybe it's a good idea to make the userland API more flexible and just 
have a driver_settings interface, and no other control structures.
Also, I would try to make the whole thing as integrated with the core 
stack and its interfaces as possible.

> > Yes, sounds reasonable.
> > But in any way, I would wait for a word from our head chief.
> Yes, me, too. I just did not want to leave your mail unanswered.
> I hope Philippe will answer soon. ;;;)

Yeah, but give him some time :-)

Adios...
   Axel.

Other related posts: