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