Subject: STREAMS (was Re: kernel help)
To: None <Brad.Walker@corp.sun.com, greg@krishna.mitre.org>
From: Captech) <greywolf@tomcat.VAS.viewlogic.com (James Graham>
List: port-sparc
Date: 09/01/1995 10:34:30
Unix Systems Catherd wrote:

#:  Brad,
#:   I want to echo what someone else said - you've got to be VERY VERY
#: careful to clear this with your Corporate folks before starting
#: work. Given Sun's public attitude about people producing competing
#: OSes to SunOS/Solaris in the past, you're going to find it tough
#: going. I know that I will have to fill out endless paperwork and
#: grovel a lot to get permission from my company to contribute any work
#: to NetBSD, and we don't do much OS work! I'm sure you'll have to be
#: careful about incorporating or using proprietary information from Sun,
#: AT&T (USL), or whoever in your work for NetBSD. If you can get
#: permission to do this work, I'll sure be glad to have you. Sbus
#: standards and device drivers expertise is greatly needed.
#:   As far as STREAMS and other SVisms go, you should try hard to make
#: sure that it's an option that can easily be configured out. Kernel
#: bloat is still one of the worst problems with all modern Unix-alikes,
#: and I don't want to add more memory usage to my kernels for features
#: that I frankly shudder at having to use. ;)
#: 	Greg
#: 

Two things:

1. Brad could *always* wait until his commission with Sun runs out.

2. The word "streams" means something much different when you have to shout it.
  Personally I'd like to see the bstreams in there if they're not already
  (it's been so long since I've seen mention of STREAMS/[b]streams that I
  don't know the status of that portion of 4.4(.[12]) anymore.  Was that
  Karels' project or McKusick's?).  I believe they have some significant im-
  provements over the STREAMS stuff (which is, of course, not in and of itself
  a mean feat).

2 (okay, so I can't count!).  I agree with the configurable options.  

Not being a huge fan of SysV, I _am_ somewhat impressed with the prospect of
a dynamically loadable kernel which has only the necessary items to run and
it then drags in the modules it needs as it goes.  For instance, you might
have the sd and tty drivers (well, more than that, but you get the basic idea)
when you first boot up, since it's about all you need.  If you hit a tape
device, it would go and load the necessary drivers to handle it; if you decide
to get the ethernet going, it would go and load the necessary drivers to handle
it, and the like.

If your system doesn't need a whole lot of stuff, it doesn't grab it, yet
if you decide to attach other things to your system, you don't need to
reconfig/recompile a kernel every time you add something new.  I know,
GENERIC is supposed to handle that, but this way you could actually have
a minimal kernel in core, with the rest of the stuff only dragged in as
necessary (wait, I said that already).  You'd almost never *need* anything
other than a GENERIC kernel.

Of course, having it all preconfigured seems to save a lot of time in the
long run as you don't take performance hits every time you hit a new device.

[Jeez, I hate software bloat and yet my proposition makes me as guilty of it
as anyone else.]


				--*greywolf;