|
|
Log in / Subscribe / Register

How Debian managed the systemd transition

How Debian managed the systemd transition

Posted Oct 13, 2015 15:09 UTC (Tue) by raven667 (subscriber, #5198)
In reply to: How Debian managed the systemd transition by nybble41
Parent article: How Debian managed the systemd transition

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.


to post comments

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.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds