[openbeosnetteam] Re: porting FreeBSD's new netstack

Waldemar Kornewald <Waldemar.Kornewald@xxxxxx> wrote:
> 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.

While I am certainly a friend of clean designs, I think that it's 
crucial for a service like this to perform as efficient as possible.
If the design already imposes (obviously unnecessary) restrictions on 
the efficiency, I would not consider it appropriate for this task.
So if the BSD stack is not just a big and unmaintainable mess that 
happens to work almost perfectly, I would consider keeping it. And 
then, I would not persue any efforts to put layers between the kernel 
and the stack to keep it unchanged - I would port it as natively as 
possible (because if you don't you would render it's biggest advantage 
senseless).

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

You make it sound like porting the new FreeBSD stack is the only option 
:-)

Bye,
   Axel.

Other related posts: