[openbeosnetteam] Design mess

Hi guys,

Waldemar said:
> > Which 'net_server' are you talking about?
>
> The one in src/servers/net (the old testing one). DHCP could use it,
> too. It should become a general place for userland networking add-ons.

After Axel's previous suggestion that we should have a net_server app hosting
inetd features plus DHCP as an add-on, I start to worry about the bluring
design we wanted to introduce recently.

We choose long ago to put the system part of our network stack into kernelland.

To be accessible from userland, we have wrote:
1) libnet.so/libsocket.so/lib[b]netapi.so libraries, which all interface with
the stack thru a gateway pseudo-device, /dev/net/stack, providing sockets =
file descriptors at same time.
2) ifconfig & pppconfig command line tools which thru special ioctl opcodes
access this same and single /dev/net/stack pseudo-device to query and modify
the way the net stack behave.

And now we're considering to add a "server" app to listen PPP (dis)connections,
DHCP packets, act as a inetd super daemon and what more in the future.

A kernel net stack, userlands libraries, some command tool using them (all fine
and usual) and now a net_server-like app??? Sounds like a mess of mixed kernel
stuffs *and* userland stuffs to make a network environment.

Aka the *worst case*.

I think it's getting even more complex that it was due to BSD code heritage, and
start to looks a little bloated too.

Maybe putting the network stack into kernel was wrong and we should just keep
the /dev/net/stack in kernelland for sockets = file descriptors and move all the
rest to userland in a net_server + add-ons design.

Or maybe we should stay the course and turn what belongs to a network stack
internals into a kernel module and expand our userland libs
and tools to support features like queries & notifications (PPP Up&Down,
configuration changes, etc...), even if sometimes it means launching a script
from kernelland to run an external program for graphical PPP connection
(remember Waldemar, this trick actually works...)

Anyway, I feel that we should try to keep this unfortunate kit from becoming a
mess of kernel pseudo driver & adapters drivers, kernel modules + userland
libraries, command tools, scripts, server & add-ons.
It's starting to look like Unix ;-)

I would want us to take some time to consider what design we should chose and/or
stick to:

a) put all what's needed for a working stack into kernelland, without user
assistance, for the sake of performance and self-dependency. Put all the rest
in userland libs and regular apps. I included inetd daemon as a regular app.

b) put less as possible (nothing being the best) into kernelland, and make the
network kit looking more like the R5 one, based on a net_server app + its
add-ons + some libs and command line tools.

What do you think?
Does I overly react?
Do you share my worries?
What's your preferred design?
Someone have a c) design to propose?

- Philippe

Other related posts: