[openbeosnetteam] Re: porting FreeBSD's new netstack

  • From: Waldemar Kornewald <Waldemar.Kornewald@xxxxxx>
  • To: openbeosnetteam@xxxxxxxxxxxxx
  • Date: Tue, 21 Sep 2004 19:00:58 +0200

Axel Dörfler wrote:

Why writing our own then? Why not just moving the ported stack over to exactly match our needs? And I don't mean a nice C++ API here, because that thing just sits in the kernel anyway :)

That is a nice question. :)
The real question was: should we take our current port and fix it or should we make a new port which does not need fixing? But we have plans for a new netstack...
Personally, I could live with a port, but I would also like to have a netstack that is readable (source) and uses some cool new technologies (general layer interface, attributes, no-locking concept? [as far as possible]). Maybe we can reduce the code size and make it significantly more readable. We already agreed on C (I do not always need C++ ;) and you can find the code in our src/tests/kits/net/newstack folder.

FreeBSD's stack already has most features we need, except for mDNS&DHCP kernel modules (maybe). Hey, their stack even has an NDIS wrapper!

Our netstack could be more integrated, but maybe we would not even notice the difference. And I doubt that the stack will actually be fast enough to compete with BSD's one. The attribute system means some (not much) lookup overhead, but it makes the source clearer and it can sometimes remove the code for distinguishing between different protocol types (TCP over IPv4&6, anything over ethernet&802.2/3, etc.) because the layout of the packet is translated to attributes.

What do you think? How much work would a new port (we can reuse existing code and experience) and fixing/extending the current port mean?

Dunno - that depends on how far you left David's work on making our stack thread-safe behind. Because that was pretty unusable.

I saw nearly no locking at all in the ported stuff. Maybe TCP is safe, but it will be very complicated to find all the places in our core module where locking is needed and we will have to take care of dead-locks. This will be a major undertaking.


Other related posts: