Return to BSD News archive
Xref: sserve comp.os.386bsd.misc:2904 comp.os.linux.misc:20567 Newsgroups: comp.os.386bsd.misc,comp.os.linux.misc Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.cs.su.oz.au!metro!dmssyd.syd.dms.CSIRO.AU!megadata!andrew From: andrew@megadata.mega.com.au (Andrew McRae) Subject: Re: source of TCP/IP (was I hope this wont ignite a major flame ...) Message-ID: <1994Jul29.023923.6333@mega.com.au> Sender: andrew@mega.com.au (Andrew McRae) Organization: MITS Real Time Ltd, North Ryde, Sydney, Aust. References: <CtMp4G.7Ap@calcite.rhyolite.com> Date: Fri, 29 Jul 1994 02:39:23 GMT Lines: 73 From article <CtMp4G.7Ap@calcite.rhyolite.com>, by vjs@calcite.rhyolite.com (Vernon Schryver): > The single consistent, non-trival, bad thing I've heard about Linux is > that it's network code is, to put it politely, not as good as it will > be someday. Given the fact that BSD network code has always been > absolutely free for the taking (requiring only those pesky copyright > notices that AT&T/USL removed from the SVR3 and SVR4 network code), I've > never understood why Linux does not use the best available network code, > BSD's. > Vernon Schryver vjs@rhyolite.com Without being dragged into the *BSD vs Linux debate (we have run both, and think any free s/w is a Good Thing), I will give a concrete example of a problem we found on Linux, and why running the *BSD networking code would have not caused this problem. I am not 100% sure of the version of Linux that this was on, but we ftp'ed it a couple of months ago, so it isn't ancient, but for all I know, this bug may have been fixed already. Essentially the problem was that UDP broadcasts were not being heard by the sending host; we had some software that relied on this, and so I dug into the Linux code to figure out if I could simply add this. I have worked on both 4.3 BSD (a lot) and 4.4 (a bit), so I knew generally what needed to be done. The 4.3 code does this in the network driver, since the driver knows whether the broadcast will be heard by the h/w or not. All the driver did was check for the ethernet broadcast MAC address and copied the packet to the loopback interface. The nice layering of the BSD code makes this easy, but it means each driver must do this. 4.4 fixed this by refining the layering even more, to place a LLC layer into the protocol stack, so that now the IP layer calls the generic ethernet LLC code, which checks for an IFF_SIMPLEX flag (along with the packet header flag indicating it is a broadcast) to find out if the h/w is not duplex (ie. will not hear its own transmissions), and if so, copies the packet to the loopback driver. The driver doesn't have to sort out MAC broadcast addresses or know about loopback drivers. I dived into the Linux code, and after rooting around a bit, discovered that it wasn't such a trivial exercise after all. It was easier to fix the application code :-( My quick look showed me that the network code is mixing up a lot of the protocol layers, and placing protocol dependancies in the drivers, and the protocol code knows about the MAC layers etc. I guess my point is that the BSD code is the result of several generations of refinement, testing and experience, and the result is something which (even though people may complain about its size or complexity sometimes) is modular in nature, and has distinct separation of protocol stacks, interfaces, drivers and API. Witness this by the fact that several different protocol stacks co-exist in the networking code. I found this clear modularity helped greatly when porting the code to an embedded system, allowing drivers to be easily attached for other MAC layers (like 802.4 Token Bus). It is suprising that Linux hasn't taken advantage of this (and yes, I know this is political), but it may just take quite a long time before the Linux re-implementation of the network code is portable enough to implement the ISO protocols (what a nasty thought!) within its framework. I am not even sure how Linux handles multiple interfaces and different MAC drivers. It would be easy to say, `since you found a bug in Linux, can't you fix it so everybody could benefit'. I could, but my fix would be to port the BSD code into Linux :-) Cheers, Andrew McRae inet: andrew@mega.com.au MITS Real Time Ltd, uucp: ..!uunet!mega.com.au!andrew North Ryde 2113 Phone: +61 2 805 0899 NSW AUSTRALIA Fax: +61 2 887 4847