On Sun, 7 May 2000, Ron Van Dam wrote:
>
> From my understanding the main reason why the production releases of new
> kernels is always delayed is because of the "just one more feature" problem.
> What about creating two new development kernels (2.5 and 2.7) at the same
> time and set fixed development goals of the 2.5 kernel before beginning
> work. Anything outside of the 2.5 goals must go into 2.7.
I'm completely again this. The main target is a stable kernel, and not to
make some release date. If that is the target, things are going the WRONG
way.
> For instance is someone wishes to begin support for a new processor which
> will most likely take a long time to complete, they can work on the 2.7
> kernel. Some one that wants to simply add new driver support for a standard
> device (such as a new sound card, Ethernet Card, etc) can include their work
> in the 2.5 kernel.
You normale test agains a stable release to be somehow sure that there is
not a undiscovered bug biting you.
>
> Obviously some effort would be duplicated, but perhaps some sort of process
> or tools can be implemented to simplify management of two development
> kernels. Maybe this idea is silly, but I though I would post it anyway
> My 2.5/2.7 Kernel Wishlist:
> Built in support for Journaling file system(s)
ext3, ReiserFS, To come XFS from SGI.
> ACL's for file systems .
No idea..
> Support data encryption for file systems with third-party loadable kernel
> modules.
> (make it real easy to Include the support for encryption without
> including actual encyrption algorithms).
> Sharing devices over a network (not justs Disks with NBD, serial ports,
> sound cards, USB devices, etc)
> (Why buy multiple devices when I can share!)
> TCP intercept -- verifies TCP connections before passing on the
> connection to userland. To prevent DoS and Spoofed attacks.
> Security integrity checking ( log if the system was booted with a
> different kernel, log when kernel modules are loaded)
> Enable Kernel Module signatures so any foriegn kernel modules will be
> refused. (to avoid Kernel Module hacking).
If you're that parainoid disable them.
>
>
>
> Ron
Igmar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:21 EST