Return to BSD News archive
Xref: sserve comp.os.386bsd.questions:12282 comp.os.386bsd.misc:3159
Newsgroups: comp.os.386bsd.questions,comp.os.386bsd.misc
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!agate!trib.apple.com!amd!netcomsv!calcite!vjs
From: vjs@calcite.rhyolite.com (Vernon Schryver)
Subject: Re: Whats wrong with Linux networking ???
Message-ID: <CuDvpC.Irz@calcite.rhyolite.com>
Organization: Rhyolite Software
Date: Thu, 11 Aug 1994 18:36:48 GMT
References: <RSANDERS.94Aug9003813@hrothgar.mindspring.com> <CuA6w1.5tF@calcite.rhyolite.com> <32cs6g$l9t@klaava.Helsinki.FI>
Lines: 81
In article <32cs6g$l9t@klaava.Helsinki.FI> torvalds@cc.Helsinki.FI (Linus Torvalds) writes:
>In article <CuA6w1.5tF@calcite.rhyolite.com>,
>Vernon Schryver <vjs@calcite.rhyolite.com> wrote:
>>
>>There was an excuse for inception of Linux. Big-bad-nasty-mean-USL/AT&T
>>is obviously a sufficent reason for most of the kernel. Who says
>>otherwise?
>
>Actually, USL/AT&T had little to do with the inception of linux at all,
>other than being the original home of unix.. The discussion seems to
>think that linux is "new" on the unix market, but linux has actually
>been out there longer than the free 386bsd variants, and the major
>reason I started on linux in the first place was that there was nothing
>else available to me.
Except for USL/AT&T, wouldn't a complete 4.*BSD have existed many years
sooner? Would you have started linux from scratch instead of as
a rewrite of existing code except for the USL/AT&T license problem?
If you could have bought a CDROM of 4.*BSD-Lite, would you have even
bothered to start?
> ... Another
>argument was that the BSD mbufs don't make any sense these days where
>memory is cheap (and caches makes pointer jumping look bad), and using
>them would just be shooting oneself in the foot in the long run.
It's hard to say much good about mbufs. STREAMS buffers are some better
than mbufs and could have been much better. That STREAMS implementations
are slow is not due to the buffer mechanisms. Its a fact of commercial
UNIX life that regardless of the wonders of your native scheme, you must
offer an interface based on either mbufs or STREAMS buffers to third
party hardware/device driver vendors, and that unless you offer both,
you'll get a lot of complaints.
>>That fitting BSD code into a Linux might be hard is a crazy excuse. It
>>makes just much sense as refusing to have an open() system call. Of
>>course a non-BSD kernel has different internal mechanisms, but one
>>expects a good clone (i.e. something strictly and unabigiously better
>>than the original) to have compatibility glue.
>
>Don't be silly. It's a clone on the *user* level, not internally.
>Internally, it looks a *lot* different: mostly just because it has a
>different history, partly because I think some "real Unix" ideas are
>braindead ("spl-level" - ugh. Inherently stupid, and probably only done
>because the original machines had priority-coded interrupts. Similarly
>for disklabels.). And then we stole a lot of ideas from others too :-)
What you say bad about "real Unix" is arguably true, but beside my point.
My point is that the user-kernel interface is only one of the interfaces
to a system. Much as I detest DLPI and DKI as typical consortium
committee work, the idea of standard interfaces to kernel facilities
for portable, low to medium performance devices, file systems, and other
gadgets is very important. It could be argued that the most important
value of MACH was in its avowed effort to separate the interfaces of
the parts of the kernel, so that you can replace or add your own or 3rd
party code. Regardless of how different Linux is internally from "real
Unix", to survive as other than a teaching aid like Minux (which is an
entirely respectable goal) it will have to converge to
NetBSD/FreeBSD/4.4BSD-Lite and/or maybe System V on kernel interfaces
so that people can fit kernel code into Linux as easily as the others.
That Linux is very different implies no more than that one would need
thicker glue to convert to and from mbufs. For example, converting
between STREAMS buffers and mbufs is old hat for people in my vicinity.
Think how DOS had to accomodate TSRs, interrupt chaining, and the rest
of the kludges. Think how much better DOS would have been if interfaces
to internal services had been chosen instead of kludged or forced by
3rd party software and hardware vendors
Why stick with read() and write()? Those are terrible formulations of
the ancient system calls, except for the simplest, lowest performance
applications. Kludges like page-flipping (that can be good for 100%
performance improvements) are useful only because read() and write()
are so simplistic. However, even if you have something better than
read() and write(), you must also have read() and write() compatibility.
The same applies to internal kernel interfaces.
Vernon Schryver vjs@rhyolite.com