For example, part of the LiS patch now consists of new system calls and
a patch to the select function plus a few other small modifications to a
few other places in the kernel. These patches are harmless to
non-streams mechanisms and could be incorporated into the kernel. Doing
that would make it much easier to drop STREAMS into the kernel as a
"patch" since the patch would consist (almost?) entirely of new files.
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.
> If its a module that folks can ship and it is seperate from the kernel
> proper its something people can install, its something vendors can use but
> its not something we effectively get lumbered with.
>
> RPM makes this a non issue since any vendor can ship streams using code
> with an RPM dependancy on gcom-lis-2.0 or whatever and since it is free
> code they can even include the gcom-lis rpm in case the user didnt get it
> with their distribution.
>
> Alan
>
I'm really pretty easy about this. We here at Gcom can work with things
just the way they are, in which case we may have to narrow our focus a
bit and not always keep up with the latest kernels. Or, if the job gets
easier, we can more easily track new kernel versions. Our own business
purposes are well served by a narrow focus. We are offering to do a
better job with general availability if we get a little help from the
official kernel source itself.
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.
-- Dave