Re: Desktop Kernel Stuff

[Seth Nickell <snickell stanford edu>]

> So, let's build ourselves a list. :-) Which kernel issues are important to
> GNOME, at a technical level? Which kernel issues are important to GNOME
> users? I'll summarise, and take it to the streets.
These two would be nice for GnomeVFS....

   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.
   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.



The following would be nice for software / hardware integration so we 
can write nice control panel style things:

   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.
   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.
   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 
the computer can totally figure out (mouse, keyboard, known camera) it 
should Just Work (for some devices this of course requires notification, 
e.g. X would need to be told about the mouse and Nautilus might need to 
know about the camera). If it fails to just work, we need as much 
information as the kernel knows about the device and maybe stuff like 
"this driver looked like it should work but it failed to load". A 
message reporting insertion but failure could perhaps be part of the 
notification support, or maybe the central hardware info registry could 
give the current status of drivers (did they load ok / was one not found 
/ was one found but failed with message _____ / etc).
   4) What'd be *really* nice is to have kernel support for these 
things and a nice library accompanying it that prevents a sane API 
rather than having to track all the black magic and weird hacky kernel 
ways of communicating with userspace (see "dnotify"), but that's 
probably asking too much :-)


This is asking for the moon, is insanely hard to do at this point, 
causes major compatibility issues, and probably would incite major 
flamewars if anyone took it seriously, but what the hell, it would be 
really useful for desktop stuff so I'll mention it because I'm obviously 
not a kernel hacker and maybe its not as impossible as I think it is:

   1) A revised permissions system that allows processes to acquire 
multiple permission "tokens" ala the HURD..... so that they can run with 
multiple user's permissions. This would allow things like the mouse 
preference page to run as the normal user, but if you changed one of the 
settings that requires root, we could prompt you for the root password, 
pick up root permissions, do the work, then drop the token. Or, in 
Nautilus, if you try to copy a file you don't have permission for we 
could let you authenticate as root or the owner of the file, do the 
work, and then drop the permissions. I imagine the usefulness of this is 
not restricted to desktop apps but could be used so that, e.g., moddav 
could run as nobody, but when you log in to it, authenticate as you so 
that you can access your homedir through WebDAV (oops, guess that was 
another desktop application... :-)



I suppose this isn't really kernel's fault... probably more of a distro 
thing.... but since I'm thinking of it :-)....

   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 
they get turned on in the morning, which means that boot time matters. 
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.

-Seth