[openbeosnetteam] Re: porting FreeBSD's new netstack
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Wed, 22 Sep 2004 04:49:21 +0200 CEST
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:
