[openbeosnetteam] Re: Status
- From: Oliver Tappe <openbeos@xxxxxxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Sun, 11 Jun 2006 20:48:49 +0200
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
Other related posts:
