Similar to systemd's Plumber's wishlist, here's the desktop kernel wishlist. This was originally sent to the fedora-desktop list and more recently to the Linux kernel mailing-list.

Power management

• an hibernation implementation that doesn't use the swap space (interactivity sucking when there's a run-away process, or hibernation? choose...)

  • Running "swapon" before suspend is a possible race condition

  • One could use a modified µswsusp (will require systemd changes too)

• Native hybrid suspend support in the kernel ("Intel Fast Start" on some Intel machines)

  • It needs to be native to the kernel to avoid hacks in user-space

• Connected stand-by support
• Export of last trigger time for "wake reasons" (rtc alarm, lid open, Wake-On-LAN, Wireless network proximity, power button, etc.)
• Screen backlight guidelines: is 0 backlight "no backlight" (as happens with Apple laptops) or "the lowest level of possible backlight"

• better documentation for USB power (How can I keep a USB socket powered to charge a device, Remote Bluetooth wake-up, etc.)

VFS, filesystems

• Current problems
  • Using inotify on large directory structures uses a lot of resources
  • Use a way for the "time" changes to travel up the directory chain when something changes (eg. if something changes in /foo/bar/baz, a timestamp on /foo will be changed) is not possible because POSIX (breaks make for example).
  • File creation notification in inotify requires watching the whole directory and filtering (unnecessary wake-ups)

  • inotify sends IN_CREATE followed by IN_CLOSE_WRITE for creat() but for link() (or mkdir(), mknod(), etc.) only IN_CREATE is sent. We could use a new event type for one or both of those cases so that we always know if a IN_CLOSE_WRITE will be coming or not.

  • fanotify doesn't support rename/move
  • Crawling large directory structures (or monitoring them) is expensive for backup programs, "indexers" (Tracker, music and video programs with libraries...)
• Better file change notification API (for crawlers)
  • fanotify rename/move support could fix the above with user-space glue

  • and so could changelog streaming for all filesystems (already implemented in btrfs/XFS)

  • Ultimately, the user-space API would be similar to OS X's FSEvents, with coalescing of events, and delegating of the monitoring process (as with the timestamp change above, without the actual crawling, great for discrete changes).

• Allow renaming a pathless tmpfile (file created using O_TMPFILE) over an existing file, as a way to get atomic rewrites without littering the file system with tmpfiles. This would be useful for g_file_set_contents().

Others

• Better IIO user-space API. IIO is the sub-system used for sensors of all kind, including accelerometers, compasses, gyrometers, etc. It's used on tablets and laptops to detect screen rotation, on tablets and phones to determine orientation (pointing north in gnome-maps).
  • Current "API" is a bunch of files in sysfs

• User-space helper for the OOM killer (http://lwn.net/Articles/552789/)

  • This doesn't replace the kernel OOM killer, and is called much earlier as well
  • Used to avoid running out of physical RAM
  • Combined with information like whether an application is active, can be used to call for applications to shrink their memory usage (drop caches, do garbage collection, or save their state before being killed)

• memory compression enabled by default on certain classes of hardware (fast enough CPU), see zram, zcache, zswap

  • This needs to be tested and enabled at the distribution level
• childfd: polls as ready when any out of a set of processes is ready to be reaped
• variant of epoll_wait which takes an absolute monotonic time instead of timeout