FreeLists / openbeosnetteam / [openbeosnetteam] Re: porting FreeBSD's new netstack

[Waldemar Kornewald <Waldemar.Kornewald@xxxxxx>]

Philippe Houdoin wrote:
> > Maybe NewStack is just to make us devs happy because we always wanted 
> > to 
> > write our own netstack? 
>
>
> That wasn't my feeling when I commit the src/tests/kits/net/new_stack 
> subtree.
> I guess new_stack started after some discussions here about more 
> modularity and 
> because of messness of current core and protocols code, PPP putted 
> aside ;-)

I am always open for suggestions, don't make PPP sound too nice. ;)

BTW, of course, I had a different feeling when I thought about new_stack 
the first time, too, but now it seems that it is better to do something 
that makes the user happier.

> I fear it'll be hard to work with the FreeBSD community not because of 
> human factor (I'm sure they're smart guys!) but because of technical 
> issues. AFAIK, their stack is a monolithic stack where pretty much is 
> builtin. This make thing easier for them than for us: we want a modular 
> stack. 
> Maybe we're wrong here, maybe we should have just a monolithic add-ons/
> kernel/network/stack kernel module instead, basicly a port of latest 
> BSD stack. That would make easy to hide the inter-depencies of 
> protocols and stack core.

This is one thing I thought about, too. When would a user want modules? 
If we just copy IPv4+IPv6 from FreeBSD into one module, what else would 
be needed? OTOH, *if* someone needs AppleTalk or IPX he would be left 
alone. I do *not* want the Linux/BSD way of compiling customized 
kernels/modules. We need a stack that fits our audience's needs.

Do we need to separate UDP, etc. from IP? One IPv4+6 module (if at all) 
could work much better and simplify our porting work.

And in cur_netstack we even have parts belonging to IPv4 in the core 
module. So, we do not really separate it.

----------------
My suggestion is: at first port BSDstack with IPv4+6 as a monolithic 
kernel module. This will help keeping our code synced with FreeBSD. If 
we find that sometimes there is a need for modularization of protocols 
we can still implement it.

IMHO, interface modules are useful because they are comparable to 
drivers (there will be more than only ethernet) and companies will 
probably not always need all drivers (esp. in embedded devices). AFAIK, 
it is rather easy to implement interface modules support, isn't it?

Anyway, our first aim should be a working, but totally (!) monolithic 
port of FreeBSD's netstack. After that we can consider modularizing 
parts of their netstack.
----------------

> I don't think it'll be easy to modularize their stack code without huge 
> code refactory. Maybe I'm wrong here too and the latest BSD stack is 
> already highly modular, feel free to correct me.

They said it will be rather difficult to make a modular port 
thread-safe. Their netstack is not module-safe, so to speak.

> Well, IPv6 is not mandatory for R1 at least, I prefer a stable IPv4 
> only stack than an unstable-too-quickly-ported IPv4 & v6 stack.
> In fact, I prefer a stable and well-known stack code but limited than 
> any other option!
> Hence the new_stack spin-off: try to understand, step by step. But time 
> vanished soon after I made the first steps :-(

IPv6 will be needed somewhere in-between R1 and R2, I think. This makes 
it rather important. But I agree with you.
A monolithic port would allow both: stable+features(IPv6)

> Sounds like after more than one year nobody (and that's include me 
> obvioulsy) have the will to continue with the current code.
> So, maybe it's a signal we should not ignore, meaning it's time to drop 
> the current stack code and start over.
>
> By "stack code", I mean all src/add-ons/kernel/network/core|protocols|
> interfaces/*.




> But first, we must choose what road we want to follow:
> - port as much and simply as possible the FreeBSD stack code

This should be done first. We *neeeeed* a stable netstack. This could 
attract new devs, too, and R5 people could have a finally working and 
stable net_server replacement.

> - or stay with the modular stack design, taking inspiration from 
> FreeBSD's stack to code modules

Nothing speaks against making it modular and implementing iovecs for R2, 
but for now I would say we need a working basis.

Bye,
Waldemar