Re: What do you think of STREAMS?

David Grothe (dave@gcom.com)
Fri, 30 May 1997 17:36:02 -0500

Andi Kleen wrote:
>
> David Grothe <dave@gcom.com> writes:
>
>
> > One step further would be a Lisa option to control a config variable to
> > enable STREAMS the same way that a specific file system (for instance)
> > is enabled. Then STREAMS itself just becomes a big hunk of code that
> > drops into the kernel tree without landing on anything that is already
> > there.
>
> Why kernel tree? What advantages does STREAMS have from sitting in
> /usr/src/linux?
>
I have given some thought to your question. There is an attractiveness
to making STREAMS a loadable module. However, there are some STREAMS
functions and styles of usage that tend to push STREAMS in the direction
of being linked in with the kernel. Here are the ones that I can think
of at this time. Some of this stuff comes from trying to approximate an
SVR4 style for STREAMS and STREAMS drivers.

1) One of the services that STREAMS provides for its drivers is the
ability (optionally) to call an init routine in the driver at boot
time. The SVR4 semantics of this call is that it occurs early enough in
the boot sequence that interrupts have not been enabled yet. That would
be too early for a loadable module to be loaded.

2) STREAMS is not stand-alone. What I mean by that is that a set of
STREAMS drivers are linked in with the STREAMS executive and that whole
libary is then linked into the kernel. There is a subsidiary build
procedure that involves interpreting a STREAMS-specific configuration
file that enumerates the STREAMS drivers and a number of attributes of
each driver. Each driver has its own Space.c file which must be
compiled in the presence of a STREAMS configuration generated config.h
so that the drivers can turn config info into C language table entries.
I suppose that this _could_ all lead to a master link of STREAMS and all
of its drivers as a loadable module, but, perhaps because of my UNIX
background, it feels more like a kernel link to me.

3) The SVR4 model for individual STREAMS drivers is that they come in
binary (not source) packages. Each driver contibutes some information
to the STREAMS configuration file and each gets its Space.c file
compiled with defines generated from the config file available to it.
In SVR4 all of these pieces get linked into the kernel. I have tried to
model that style.

4) SVR4.2 and Solaris do have a scheme for making individual STREAMS
drivers loadable modules, but I have not attempted to implement that
feature. In those cases the STREAMS executive itself is still linked
directly into the kernel (though I may be speaking out of turn for
Solaris).

I think all that really matters is to get some little stubs into the
kernel so that a STREAMS user can RPM the STREAMS code into their kernel
without having to patch any kernel source to do it. That way STREAMS
users are insulated from kernel source updates. With RPM one would not
need to know much to install STREAMS in the kernel.

> [to Alan Cox:]
> > If you would like, I could provide you with a small-ish patch file that
> > I think would cover the places in the kernel that I would like to see
> > changes in to lay the foundation for the easy addition of STREAMS.
>
> I think that's a good idea.
>
I have sent the "stubs" patch off to Alan Cox.

> -Andi