Re: Desktop Kernel Stuff

[Alan Cox <alan redhat com>]

>     1) Better file monitoring API....maybe even one that doesn't require 
> a file handle per monitor so we can monitor more than the number of 
> available file handles? Currently we run into trouble if we try to, say, 
> monitor all the music files. Alex may have more specific complaints and 
> stipulations.

This may happen in time. Its a close relative of C2 style auditing which
is mandatory for some deployments. They want to log everything you touch,
you want a central daemon to notify all file events, I want to know each
file close of a changed file so I can re-index it for a search engine...

All the same stuff to the kernel.

>     2) User Extensible Metadata in ext3!!! It seems like this is on the 
> verge of happening (maybe it already happened?), perhaps we could give 
> it an extra push.

Done for 2.5

>     1) Standardized central interface for getting information about all 
> hardware. /proc is currently a mess and you have to add support for 
> every new kind of bus / device type.

Userspace mostly.

>     2) Uniform notification system when hardware is added and removed 
> (distro specific shell scripts are nasty, we need something that we can 
> write once for and have it work on all distros), specifically for 
> firewire and USB but would be nice if it worked for things like hotplug 
> PCI too. Should be closely linked to the central hardware info so its 
> easy to pull up the hardware info for something when you find out it was 
> added.

Userspace issue. /sbin/hotplug provides the needed framework hooks. Its
all about policy so has to be user side.

>     3) User-space mediated autoloading of drivers and such.... Not sure 
> exactly how this should all work out, maybe need to do an interface 
> design for it. The sketch is that when you plug basic hardware in that 

/sbin/hotplug, the rest is up to you - dbus may be a big help here.

>     1) A revised permissions system that allows processes to acquire 
> multiple permission "tokens" ala the HURD..... so that they can run with 

Capability based systems really don't fit well with unix semantics but
you can do it (AFS is a fine example). Probably doable with 2.5 SELinux
stuff and some care. One of the big issues you need to resolve is how
you pass capabilities and if you do bounding on them. Also some minor patent
related issues (see EROS papers)

>     1) An init system that didn't suck and ran things in parallel where 
> possible. Because desktop machines get turned off at night, which means 

Someone wrote one - its generally a loser for performance.

> It would also be nice if X were loaded as soon as humanly possible and 
> the desktop was able to monitor the startup sequence and provide pretty 
> progress icons, but still allow people to log in even while the system 
> is loading.

User space issue, and quite doable.