[openbeosnetteam] Re: FreeBSD vs. our stack

On 2006-06-02 at 18:59:04 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> 
wrote:
> Hi there,
> 
> Waldemar and I talked a bit and here is what we came up with:
> 
> According to Waldemar, our current networking stack is still very close
> to a BSD stack which could ease the effort of porting FreeBSD modules
> into it. Also according to Waldemar, he has little hope that we could
> or should use any of the code in our repository right now. While my
> impression of the code was similar, it has been some years since I
> looked at it (during David's active time).
> 
> In any way, what needs to be done first is that someone starts at the
> very ground (ie. packet and memory management, a.k.a. mbufs and their
> handling) of our current stack and works his way up in layers and
> modules. Step by step the existing code can either be replaced with
> FreeBSD code or fixed so that it becomes usable. Everything above the
> current working set doesn't even need to be built.

Ok, this step-by-step approach sounds very reasonable to me.

> The only things that we definitely need to keep are the
> net_stack_driver, the ethernet legacy code, and the userland testing
> stuff (BONE only). The ethernet code probably needs most of the work
> and should be better separated from the rest.

Hm, I'm a bit confused... what exactly is the "ethernet legacy code"?

Talking about legacy, when trying to grasp the differences between the 
legacy/network headers and the corresponding posix versions, I found that 
there is only *one* difference (the legacy version of sys/select.h doesn't 
provide pselect on non-haiku targets). So what is the reasoning behind 
having these legacy headers?

I searched the archives, but didn't find anything useful...

> We also agreed that it makes sense to liften up the current module
> structure a bit at first, and, if needed, put more stuff into the stack
> directly (though as modularized as possible). Only the interface layer
> must be true modules for VPN and the like. That would be a good
> compromise for R1 if it allows us to reach a stable and robust stack
> earlier.

Ok, I can't yet imagine why support for VPNs would require the interface 
layer to be modules, but I'm sure I'll be enlightened on the way >;o)

[ 8< ]
> For a start, we identified the following separate tasks:
> * separate the ethernet legacy code from the network core, and move it
> into the ethernet interface, so that it can later be used with no or
> only little changes
> * make yourself familiar with the FreeBSD networking stack (in
> comparison with what we have in our tree)
> * port demons and other needed networking tools to our stack
> 
> Any takers?

Hey, I'm so set for throwing myself into this that I'd even have a go at 
moving the ethernet legacy code into the ethernet module (once I know what 
the legacy code actually is >;o)

> Accessing networking interfaces (via ifconfig, for example) should go
> over the path of the device (if any), or the name of the interface
> module. I like how BONE does it. And I don't like what our current
> stack does (ipro10000, sis9000, etc.).

Yes, I found that pretty awkward, too. 

On 2006-06-03 at 11:09:53 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> 
wrote:
> Oliver, I won't have much time until monday evening (holidays and all),
> but if possible I'd like to start working on this on tuesday. What's
> your opinion on all of this?

I'm already familiarizing with freebsd's stack and continue doing so by 
reading 'TCP VOL 2' and 'Design and Impl. of FreeBSD'. So there goes my 
weekend... >;o)
Let's start on Tuesday!

cheers,
        Oliver

Other related posts: