Who knows anything about the future of the Linux Kernel, like plans for 3.0? Any rumors? Any suggestions?
Linus' view on Kernel development has never been for the long term, he has always taken the approach of dealing with things as they happen, adding things when a need is come upon.
- How about support for 64 processor computers? (We have this in 2.6, i.e. SGI's Altix)
- no big kernel locks
- good virtual memory system
- Full ntfs support. (go help out at [http://linux-ntfs.sourceforge.net/])
also writing small files (the ones that fit into the Master File Table itself? [http://www.ntfs.com/ntfs-mft.htm small files])
- Expanding and shrinking partitions (see [http://www.gnu.org/software/parted/ parted])
- Detection of ill-behaving drivers and shutting them down but prevent kernel oops
- looping of drivers
- changes to tables of the kernel that are not claimed beforehand
- changes to the kernel's own code
I know this is very hard to do (probably impossible without in-kernel threads...) "More to the point, near-impossible without in-kernel memory protection. i.e. microkernelisation of linux. A worthy goal... (dons asbestos suit, ducks and covers)"
- to concentrate ATA, SATA, SCSI and SAS in the same subsystem - Kernel cluster friendly ( see [http://perso.wanadoo.es/xose/linux/linux_ports.html Clustering and HA section])
- Capability of changing the kernel without rebooting the machine.
- Defragmentation API
- Live fsck
- Mobile IP
- Enterprise features, (all what enterprises want are here [http://www.hp.com/products1/unix/operating/infolibrary/reports/2002Unix_report.pdf 2002 UNIX function review report])
- Expanding and shrinking _file systems_ on-line, like VxVM.
- Cluster filesystem, to allow to share same fs between several systems.
- Full support of hot-swap components(processors, memory, I/O interfaces, system boards,...) with automated dynamic reconfiguration.
- Dynamic reconfiguration API, to allow applications automatically adjust to systems resources changes.
- Dynamic system domains.
- Multiple OS on a single server, LPAR (traditional way)
- Able to recovery the system from hardware failures.
- to complete