How Debian managed the systemd transition [LWN.net]

How Debian managed the systemd transition

Posted Oct 13, 2015 13:50 UTC (Tue) by nix (subscriber, #2304)
In reply to: How Debian managed the systemd transition by raven667
Parent article: How Debian managed the systemd transition

What? X ran undegraded without kernel support for literally a decade plus, until hardware 3D stuff started turning up. MIT-SHM provided everything needed.

to post comments

How Debian managed the systemd transition

Posted Oct 13, 2015 14:45 UTC (Tue) by nybble41 (subscriber, #55106) [Link] (2 responses)

> X ran undegraded without kernel support for literally a decade plus

I think one could argue that being given direct access to the graphics hardware, and thus effectively unlimited access to the entire system, should count as "kernel support". Sure, the driver code was inside the X server rather than compiled into the kernel or a loadable module, but it still required special interfaces used primarily by X, and it wasn't possible to run the X server as an ordinary, non-root user process.

How Debian managed the systemd transition

Posted Oct 13, 2015 15:09 UTC (Tue) by raven667 (subscriber, #5198) [Link] (1 responses)

That's a good point, but even if you don't consider allowing the userspace app to just bang away at /dev/mem "kernel support" because that really isn't a defined API, certainly we say that limiting to the performance and capabilities of the 1990's X stack would be considered "degraded" by modern standards and applications. Making this behave safely without degraded performance required the addition of dedicated APIs, to talk to the graphics co-processor, to share memory buffers, beyond the 1980's UNIX standard ones.

We've already gone down the route of adding dedicated IPC APIs for SysV, for Netlink, for X/Wayland and now for DBUS, which I see as following the evolution of OS design and the needs of the applications of the era when these interfaces were designed.

How Debian managed the systemd transition

Posted Oct 13, 2015 22:49 UTC (Tue) by nix (subscriber, #2304) [Link]

Oh, I agree it would be bad by modern standards -- however, it was quite clearly capable of scaling to the point of handling graphics data with no more kernel support than that. To get back to the original point: unless you think D-Bus is not just going to be asked to handle graphics data but the full graphics flow of a 3D game I think the volume of data involved in graphics should not serve as an argument for needing kernel support just to handle that.