Miklos Szeredi: where should the border between userspace and kernel be?

August 4, 2013

Participants: Miklos Szeredi, Linus Walleij, H. Peter Anvin, Ben Hutchings, Jan Kara, James Bottomley, Steven Rostedt, Li Zefan, KOSAKI Motohiro, Dan Carpenter, Greg KH.

People tagged: (none)

Miklos Szeredi argued for a re-thinking of the border between kernel and userspace, and also guidelines for what should be inside and outside of the kernel. He gave mobile broadband as a problematic example, citing issues surrounding bluetooth, SMS interaction with TCP/IP networking, and incompatibility of NetworkManager and the corresponding CLI tools. Linus Walleij noted that similar problems surround media players and Android's use of the MTP protocol. (FTP over USB? Hmmmm...)

H. Peter Anvin noted that there are some exceptions to the “don't break userspace” directive:

  1. Scripts designed to set up boot loaders that grope in the kernel and base boot-loader configuration on what they find. (Based on a recent example involving grub2.)
  2. The kernel contains a number of workarounds for broken bootloaders. [ Ed. Why is this an exception? Perhaps in the sense that the kernel should be userspace with respect to a bootloader? ]
  3. Userspace applications that build kernel modules and insert them are permitted to be broken by new kernel versions.
  4. Userspace applications using extremely low-level APIs can also be broken.
  5. Malware that exploits a kernel bug may be broken, in fact, such breakage is encouraged, even if it also breaks some esoteric application.

Ben Hutchings noted that the broken-bootloader case is important for distributions that provide automatic upgrades. Jan Kara would like to add tracepoints to the list of permitted breakage, noting that Al Viro refuses to add tracepoints to VFS in order to avoid any requirement to maintain compatibility. Li Zefan called out cgroups interfaces as an example where change would be good, but where a number of applications rely on the old interfaces. KOSAKI Motohiro called out a tradeoff between perfect backwards compatibility and maintainability: If perfect backwards compatibility is required, then any change requires maintaining both the old and the new interfaces. [ Ed. Or you can convince all the old applications to convert to the new interface. And maybe you aren't responsible for the closed-source applications in all cases? ] Dan Carpenter noted that Linux-kernel changes have deliberately broken closed-source firmware debugging tools several times, and pointed to a recent example. However, Greg KH pointed out that in that case, the driver was in staging, and furthermore had not yet hit mainline. In addition, the developer of the proprietary software agreed to the change.