[openbeosnetteam] Re: moving ppp to other location

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

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

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?

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

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.

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

It only needs a driver_settings structure and sometimes a parent id (for
multilink interfaces).
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.

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

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.

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

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

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

Yes, me, too. I just did not want to leave your mail unanswered.
I hope Philippe will answer soon. ;;;)

Waldemar

Other related posts: