>
> 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.
I like the way AFS is supported by the kernel:
[arch/i386/entry.S]:
.long SYMBOL_NAME(sys_sysfs) /* 135 */
.long SYMBOL_NAME(sys_personality)
.long 0 /* for afs_syscall */
.long SYMBOL_NAME(sys_setfsuid)
.long SYMBOL_NAME(sys_setfsgid)
When the module is loaded it just puts its system call into this reserved
hole. Would this work for your STREAMS package too? You could send Linus
patches to reserve system call numbers for your needed calls. Then it would
be possible to build the streams modules independently from the kernel
and then just:
# /sbin/modprobe STREAMS
for people who want/need it.
This model seems to work nice for the iBCS package. iBCS is distributed
independently and works good. I really see no need to integrate STREAMS
into the standard source this way.
> 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?
[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.
-Andi