[openbeosnetteam] Re: Some quick questions

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

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

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

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

> The first thing we had to do would be to make the userland test stack
> environment work again (under BONE only, to work around that select()
> problem).

I just tried to do that. It build again (well, at least under Linux, as I'm on
Linux at work), but currently you should collect all the userland version of
the add-ons (under
generated/objects/$TARGET/$ARCH/release/tests/add-ons/kernel/network) and copy
them into the corresponding layout near the stack tester binary:

net_stack_tester
add-ons\
  kernel\
    obos_network\
      core
      interfaces\
        ethernet
        loopback
        ppp
      protocols\
        icmp
        ipv4
        tcp
        udp
        raw
        route
      ppp\
        pap
        modem
        pppoe
        ipcp

We used to map this layout automacally before the new build system, but not
anymore (no distro tree). I've to investigate how to write a rule to do it
again from the new generated/... tree. Planned as step 2.
Step 3 is obviously using it to debug the stack.

> 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!
;-)

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

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?

- Philippe

Other related posts: