lkml.org 
[lkml]   [2003]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subject[2.7 "thoughts"] V0.3
Date
2.7 "thoughts"
Thanks to Gabor, Stuart, Stephan and others
Don't hesitate to send me more or comment.

Regards,
Fabian

* slab allocation quota
* ntfs full support
* kernel web server (Interfaced to Roman config tool)
* ipc to sysfs
* complete user quota centralization
* Add _responsibilities_ for virtual process tree and possible
relation in oops cases
* Does the whole proc vm stuff root/box relevant ?I don't think
so....Hence, those proc entries deserve security relevant attributes
* Devices should be limited as well against bad usage(floppy defect),
viral activity(netcard rush)...
* Improve kobject model for security, quota rendering
* bind mount support for all general mount options (nodev,ro,noexec etc)
with SECURE implementation with any (maybe even future) filesystems?
* union mount (possible with option to declare on what fs a new file
should be created: on fixed ones, random algorithm, on fs with the
largest free space available etc ...)
* guaranteed i/o bandwidth allocation?
* netfilter's ability to do tricks which OpenBSD can do now with its
packet filter
* ENBD support in official kernel with enterprise-class 'through the
network' volume management
* Standard kernel output (Minimum, Full options ...)
* Virtual machine support
* /proc interface alternative to modutils/module-init-tools.
That is, to have a directory of virtual nodes in /proc
to provide the functionality of insmod, rmmod, lsmod &
modprobe would be great -- especially from the viewpoint
of recue disk images, etc.
* Software RAID 0+1 perhaps?
A lot of hardware RAID cards support it, why not the
kernel? By RAID 0+1 I mean mirror-RAIDing two (or more)
stripe-RAID arrays. (Or can this be done already?)
* Transparent Software-RAID for IDE RAID cards...
This could be done by using the Software RAID
functionality of the kernel, but making the RAID
interface transparent, so you only see a /dev/md?
device, rather than multiple /dev/?da* entries.
* hotplug RAM
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.096 / U:8.852 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site