Re: The Kernel

[Nick Mathewson <nickm@mit.edu>]

fluffy@dunadan.com wrote:
>On Tue, 20 Jan 1998, Erik Walthinsen wrote:
>
>> Personally, I think that as long as we can pass decent QA runs with the 
>> kernel we put together, we should be willing to incorporate new features.  
>
>I am FIRMLY opposed to such an action.

While I agree with your concerns, I must disagree with the categorical
nature of your opposition.  I personally feel that it would be an
act of great folly to include any nonstandard kernel in the Linux Core...
but in SEUL, I feel that it may indeed serve us well to include specific
non-standard kernel features.

The concept of the Linux Core, as I understand it, would not forbid
developers from including kernel patches, but only from including
kernel patches that would break the functionality of the Core.

IMO we should have no problem with including non-standard kernel _modules_
in SEUL, so long as they're stable.  If, for example, a stable Joilet FS
patch can be built into a module, I would see no trouble in including it.

Similarly, we may want to address a topic that was languishing on
linux-kernel a while ago, and provide the end-user with some sort
of bootup splash-screen in order to alleviate kernel-message anxiety. 

Finally, though I believe that we should wait for bugfixes to be accepted
into one of Linus's releases, I don't think there's anything wrong with
including patches that fix blatant, trivial errors without modifying the
behavior of any syscalls.

I do, however, agree that any patches that are included should fall within
a _very_ strict set of guidelines.  (My opinions only...) First, only patches which fix "blatant, trivial" bugs, or patches which add significant functionality should be considered.  Second, patches which add functionality
should be distributed in modules, not as a patched kernel core.  Third,
no 'performance-tweaking' patches, development patches, or patches which
provide functionality of highly esoteric appeal should be incorporated.
Fourth and finally, any patch which alters the behavior of the kernel
API in _any way_, (whether through modifying structs visible from userland, or by modifying the behavior of a syscall) should be kept at arm's length.

Assuming that all these conditions are met, and that all patches are heavily
tested, would there be any objection to including them in SEUL (_not_ the
Linux Core)?