FreeLists / openbeosnetteam / [openbeosnetteam] Re: Design mess

[Waldemar Kornewald <wkornew@xxxxxxx>]

Philippe Houdoin wrote:
> > > - run scripts/apps from kernel-land
> >
> > No, that's just bad design and opens up a way to large can-o-worms.
>
>
> Well, pretty much all standards apps after BeOS startup are launch by the kernel
> thru a script, I don't see how it's a bad design.
> Launching them from kernel doesn't mean they have kernel/root privileges nor
> they can do more than usual apps launched from userland!

Right.

> - a stack component launch (from kernelland, indeed) an app, giving him some
> arguments (like the current interface, the kind of event, etc)
> - the app do his task, like open a window

This is certainly much better because this is the most reliable 
communication mechanism. A daemon must register itself and if it crashes 
then the whole system suffers. Simple task-apps (ppp_up, or whatever) 
just do their job and exit (minimal resource usage and more reliable).
And they do not complicate the startup scripts. Often the kernel knows 
better when to run some task in userland.
Many services are needed at kernel-level (zeroconf, for example). If we 
had a Linux-like pppd other apps could not access the PPP stack as easily.

> > > Yes, of course. I don't like having dhcpd, inetd, pppd, etc. running in
> > > background, either, and I want the stack to be self-contained.
> >
> > What's the problem with delegating distinctly different tasks to different
> > programs?
>
>
> Nothing. In fact, I'm advocating exactly the same by suggesting to drop a sleepy
> server + add-ons in favor of several userland apps (eventually scripts) launched
> (fire & forget) by stack components when user interaction/notification is
> required.
>
> We had the same debate about the ScreenSavers server which since was dropped in
> favor of a simpler "screen_blanker" app fired by the input filter. No more
> server that should be *always* running.

Exactly (listen to Philippe ;). Please do a "ps ax" on your 
Linux/BSD/Unix system. Do you think that your system is minimalistic or 
a bloated, cluttered installation with too many services running in 
background? How can a system be simple if I have to study computer 
science in order to understand it? I only want the following background 
apps:
- app_server
- media_server
- Tracker
Plain simple!

> > One program, or code blob, that does everything is usually bad
> > design. It's not like the user has to be aware of them.
>
>
> Our issue here is that our stack is mostly a "code blob" adapted from BSD TCP/IP
> monolithic stack to a semi-modular design. We don't have many "distincly
> different tasks", even if we tried to apply a modular design to each protocols
> and interfaces.
>
> So, sadly, we already have to deal with a... not good enough design. We choose
> for R1 to postpone a potential refactoring of the stack design.

If you ask me, I would not be *that* unhappy with a near-monolithic 
netstack where only interfaces and extensions are modules, but the 
protocols and the stack itself live in one module. A desktop-OS only 
needs IPv4+6. The rest (WiFi, IPsec, PPP, (C)SLIP, etc.) should be 
implemented as an interface. I just want to make our work as simple as 
possible. If we had five full-time developers we could design a clean 
and nice netstack, but that's just not the case. With a more monolithic 
design we can let FreeBSD work for us at the kernel-level and improve on 
the user's side:
- im_kit
- zeroconf+API (imagine im_kit showing file services of your friends)
- LDAP Kit
- better Bluetooth+WiFi integration
- drivers
- synchronization services (LDAP with your cell phone or PDA)
The rest of our work could be keeping the sources up-to-date. And there 
is more than only "networking"...(Philippe already started OpenGL). We 
will always have enough to do, so let's not waste our time on a new 
netstack, but reuse what we have: excellent FreeBSD 5/6.x code.

Philippe, you seem to not agree here. Why?

> Please, BTW, notice that nobody released a better designed network stack in open
> source so far. I think that's because network stacks implementation details are
> often ugly, and it's hard to keep your design clean in such environment.
> And it's not like I don't care a lot about cleaness...

BTW, David Reid seems to have dropped his Marrow project. Yet another 
netstack project being abandoned.

Bye,
Waldemar