FreeLists / openbeosnetteam / [openbeosnetteam] Re: Status

[Oliver Tappe <openbeos@xxxxxxxxxxxxxxx>]

Hi there,

On 2006-06-11 at 14:42:35 [+0200], Waldemar Kornewald <wkornew@xxxxxxx> 
wrote:
> So, what's the status? Andrew, did you start with porting/coding? Could you
> please send a little status report from time to time?
> What are you working on?
> How far did you get?
> Maybe: What will you work on, next?

I don't know about Andrew's status, but I'd like to give a status report for 
my own code reading adventures anyway:

Reading and trying to grok both our existing stack and the one from FreeBSD 
6.1, I have found the code to be rather big and complicated in subtle ways. 
In order to facilitate getting comfortable with the subtleties of such a 
large blob of foreign code, I suppose that it'd be very wise to try and 
import the new stack with as few changes as possible. We know that the code 
should be working, so if it doesn't after our integration, it's easier to 
find bugs if we haven't changed it in many different places.
Once we actually have a working stack, we can decide which way to go from 
there in order to improve the integration and whether or not it makes sense 
do so before R1.

With this in mind, I checked both stacks again, and a couple of separable 
tasks have emerged that need to be solved in order to "integrate" the stack 
into haiku:

1.) As pointed out before by Axel and Waldemar: haiku's ethernet interface 
kernel module (ethernet.c) needs to be preserved and connected to the new 
stack, as the freebsd-stack has a completely different interface to the NIC 
drivers. On FREEBSD, the mbufs are created and populated by the NIC-driver 
and passed in to the stack (directly into ether_input), while we need to 
stick with the current READ/WRITE interface (possibly moving on to make use 
of readv,writev at a later stage).
Our current stack bridges the mbuf gap in our interface by using two kernel 
threads per interface (rx- and tx-thread) in order to fetch/push data 
from/to the driver (these threads handle mbufs on the stack side and raw 
buffers on the driver side). I think this is ok and I'd like to preserve 
this approach and just clean up the code for our new stack.
What I don't like/understand about our current stack is that ether_input() 
runs in a thread of it's own, which I find a bit cumbersome, as this special 
thread represents a bottleneck (every ethernet frame passes through it, not 
matter which interface it came from) and it isn't even necessary (at least 
not with the current FreeBSD stack). I'd like to simply get rid of that 
ether_input thread and simply run ether_input within the rx-thread of every 
interface.

2.) FreeBSD uses software interrupts to dispatch protocol tasks to several 
special threads (netisrs). As haiku doesn't (seem to?) support softirqs and 
several problems related to their use within the FreeBSD stack have been 
mentioned, I would vote for replacing them with standard kernel threads. 
While our current stack has done the same, I'd like to do so more 
implicitly, by changing the netisr infrastructure to simply pass on the 
mbufs to the respective (protocol specific) kernel threads. This way, we 
wouldn't have to manually replace each and every occurrence of netisr with 
code tailored for haiku.

3.) Related to the netisr stuff, the new stack uses spl...() calls to lift 
the current thread to a specific softirq level and splx() do restore the 
level later. 
While at first I found it very tempting to simply ignore these calls and 
replace them by noops, I am not so sure any more. As far as I can see (and 
I'm afraid that isn't very far at all) these calls are used to serialize the 
access of several data structures. So we'd probably have to analyze each 
occurrence and protect these data structures by corresponding locks. Our 
current stack doesn't seem to bother with that, which might or might not 
contribute to its instability...

4.) The new stack refers to "Giant", aka the global kernel lock that is 
still required at some places, heritage from older days. Many parts of the 
new stack do not need Giant at all, but I haven't fully understood yet if 
code that we need does refer to Giant. If so, I suggest we simply give it 
what it wants: a global lock. As the FreeBSD developers are trying to 
dispose the references to Giant one place after the other, we could then 
simply follow by updating our code accordingly.

5.) Several people have expressed their dislike of sysctl() as means to 
control the net stack. Although the FreeBSD stack exports lots of different 
SYSCTL nodes and values, I suppose it shouldn't be too much work to avoid 
using sysctl, as only three tools are currently using it: arp, route and 
show (whatever the latter is). So in order to avoid using sysctl, we should 
discuss how to replace it (ioctl on /dev/net/stack perhaps?) and then patch 
these tools to use that new solution instead of sysctl.

Ah, and of course, before all that...

0.) We should import the FreeBSD stack. I'm not very familiar with svn, so I 
am not sure how to do this properly. What about doing this?
        - import the FreeBSD-6.1-release netstack into a vendor branch
        - create a new netstack branch of module haiku under team/network
        - copy files from the vendor branch into the netstack branch as
          seems appropriate/necessary
        - start work in the network branch, very likely dragging more files
          from the vendor branch along

Comments on these ideas are very welcome!

cheers,
        Oliver