[openbeosnetteam] Re: Some quick questions

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

Other related posts: