FreeLists / openbeosnetteam / [openbeosnetteam] Re: Some quick questions

[Waldemar Kornewald <wkornew@xxxxxxx>]

Philippe Houdoin wrote:
> > > At BeGeistert we talked about the networking
> > > stack as well, and we kind of agreed (in absence of any member of the
> > > networking team, though)
>
> Hey, ones have to choose between going to a dev convention and wallpapering 
> his
> Really Soon Now (tm) daughter room!
> That was a sad choice, believe me...
> ;-)

Heh. :)

> > ... that it would probably be the best to keep the
> > current design of the netstack as a base, and try to fix/port/rewrite
> > it module-wise.
>
> Oh, then my opinion was actually expressed too at BeGeister: I'm 100% for 
> such
> pragmatic path.

I don't quite understand what this fix/port/rewrite it *module-wise* 
means. The module design is highly flawed because it has to export 
constants (e.g.: ip routing, interface+protocol header size...), but the 
current design does not take this into account (it assumes that global 
constants in one module are available in other modules, too ;).

Also, I don't (anymore) think that we gain very much from this modular 
design. The only modularity that might be needed is at the interface 
level (IPsec, VPN, SLIP, WiFi, Bluetooth, ...). Though, I would not 
shout if we made everything monolithic.

So, my question, again: what does module-wise mean, here? Do you want it 
to be monolithic or modular?

> > It would also be nice to port the BSD WiFi generic
> > layer and get all those drivers, but I personally wouldn't mind having
> > a deeper look at what happens in Linux at that front right now.
>
> Yep, it seems at last Linux is moving to an multi-interface 80211 layer vs 
> the
> today mono-interface 80211 layers builtin in each wifi driver.

But it's a lot more work to get ported because of the license. This is 
better kept for R2.

> We should also try to ask Patrick Lafarguette if he want to join us and
> contribute his own ieee80211 layer as a new network module. After all, he's the
> most concerned about an adaption of his wifi drivers set to Haiku...

I'm not against using his code, but does it support all important 
encryption methods (WPA and *WPA2*)?

> > Then identify the problems there are and how we get around to
> > fix it. Oliver Tappe seemed to be masochist enough to actually take
> > those initial steps - I hope he won't regret it too soon :-)
>
> He survived building and fixing GCC suite, so I've no doubt he's the man!
> ;-)

Hurray! Oops, too early... ;)

> > Marcus Overhagen, Michael Lotz, and I all expressed their interest to
> > work on this in the upcoming weeks.
> >
> > But does the existing but busy networking team think of this idea?
>
> That it's a good idea but keep in mind that the userland test stack 
> environment
> is not complete as it should, mostly due to the currently unsupported
> NET_STACK_CONTROL_MODULE message at work in the PPP substack. And possibly some
> others I forgot about...

PPP won't work without hard-coding everything into the test stack driver 
or better: switch to a message-based (ports? BMessage?) communication 
scheme. It's passing around data structures and pointers to other 
structures (e.g.: when retrieving the list of interfaces from userland)...

> One fix/rewrite track I envision is to simplify stack components communications
> (userland <-> stack driver, userland <-> stack modules, stack modules <-> stack
> modules) by using one single message mechanism for all of them.
> Do we've BMessage compatible support from kernelland? Node monitoring use it,
> right?

BMessages would simplify the communication process and for almost all 
commands we don't need a lot of speed, anyway (but read()/write() must 
of course stay as they are, maybe also the speed-critical socket 
creation code).
This way, the netstack driver's ioctl handling code could be entirely 
moved into the netstack module (unifying and simplifying the current 
two-drivers-mess). Even PPP event notification would be much simpler 
(and could be generalized for all interfaces). I like this suggestion a 
lot. Thumbs up.

Bye,
Waldemar