[openbeosnetteam] Re: moving ppp to other location
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Sat, 06 Sep 2003 18:19:05 +0200 CEST
"Waldemar Kornewald" <Waldemar.Kornewald@xxxxxx> wrote:
> > > src/libs/kernelppp
> > Nope, I wouldn't put it there. First of all, we don't have kernel
> > shared libs, second of all, we don't have a default location of
> > where
> > to put them, and finally, this is net stuff, and obviously a driver
> > /
> > module, so I would put it into:
> It is not a driver, but only a library that will be used by the
> driver&manager.
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).
> > /src/add-ons/kernel/network/ppp
> 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).
> > But I think that Philippe should have the final word there, anyway.
> There is no special PPP userland communication. PPP is a kernel
> module
> (unlike in Linux/BSD).
> The core stack loads the PPP manager (as it does with ethernet and
> loopback). The PPP manager exports an extended network interface
> structure
> (with additional special PPP features) for access by other modules/
> drivers.
> The pppcontrol driver allows to talk to the manager from userland.
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?
What makes the PPP stuff so special? I mean, what extra knowledge does
the ppp module need to establish a connection, apart from the driver,
login, and a password (and in some cases some modem settings as well)?
> etc.) are defined there. All PPP modules must link against this
> library, too
> (as they derive from those classes).
Yes, that was your decision :-)
A shared library in the kernel would be very similar to a module - it
would just enable direct C++ bindings which the module approach does
not. And since the kernel itself won't need any shared libraries ever
(why should it?), all of those libs will be on demand loaded modules -
or add-ons.
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?
> > 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.
If it's a public API, that is, it might be a good idea to make it
available to other 3rd party components, we should put it into headers/
os/drivers/, correct.
But I am hesitating of publishing new APIs with R1, because any new API
shouldn't be added without the input of several people.
That's why I would put it into private/net/ppp for now, unless you have
good reason to want to have it a public API. If a module would need to
link against libkernelppp.a I would be even more against making it
public right now, since I don't like propagating bad solutions, and C++
APIs tend to have severe legacy problems which should be thought of
before publishing them.
> > In this case, however, I would just put all PPP related user
> > headers in
> > headers/os/net/ppp, or even just one net/PPP.h file, dunno how
> > much you want to put in there.
> There are at least three headers at the moment. Milestone #2 will
> contain a
> userland C++ API, so os/net/ppp is probably the best place to put it
> into.
Yes, sounds reasonable.
But in any way, I would wait for a word from our head chief.
Adios...
Axel.
Other related posts:
