*BSD News Article 33460


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