Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
systemd 183 released
Posted Jun 10, 2012 13:12 UTC (Sun) by cortana (subscriber, #24596)
Posted Jun 10, 2012 18:31 UTC (Sun) by nlucas (subscriber, #33793)
And if they adopt the current debian way (which by the way could now be considered obsolete because udev already changed how things should be done), then you have different ways of doing things on different distros. So what are the wins of using a new udev?
Anyway, I'm not talking of Ubuntu per si to do this. I'm asking of a way for users to do this in a compatible way.
What assurance can anyone have of any way they choose udev will not change it's mind again, now expecting people to have this things on a xml file on /etc/udev/extra-devices.xml and automatically removing any device not listed there?
I'm not a big fan of the kernel internal unstable API, but I can understand it's good points and accept it as a choice made by them. This, on the other hand, is just gratuitous incompatible changes into the user-space API without any good points I can see (other than breaking because it's "prettier" this way).
This is hardly the way into unifying the plumbing on Linux systems...
Posted Jun 10, 2012 18:58 UTC (Sun) by rahulsundaram (subscriber, #21946)
This is a invalid assumption.
Posted Jun 11, 2012 14:08 UTC (Mon) by nlucas (subscriber, #33793)
Doesn't make much sense. What user will guess that it needs to install a package with a name of other that doesn't exist on his system to get utilities for a second package?
Posted Jun 11, 2012 14:18 UTC (Mon) by rahulsundaram (subscriber, #21946)
Posted Jun 11, 2012 17:15 UTC (Mon) by nlucas (subscriber, #33793)
Either way, a user-space udev API was broken. The solution pointed was to use a systemd API to solve the problem.
It's still a compatibility breakage, and if that solution is to be used across distributions it should be discussed outside systemd, not forced on all distributions. udev is a crucial Linux plumbing infrastructure. systemd isn't (at least not yet) so it can not force global policy and compatibility APIs.
The same applies for DBUS. It can eventually be considered an essential package on desktop Linux, but it's far from it on a global scale. So udev can make a DBUS API available, but never have an hard dependency on DBUS (or any DBUS utilities or API).
For example, there may be reasons for having udev on an Android system, but there are no strong reasons to have DBUS or systemd. The same for other specific-use or embedded Linux systems.
Posted Jun 11, 2012 17:38 UTC (Mon) by rahulsundaram (subscriber, #21946)
It is arguable that systemd isn't crucial infrastructure yet but I dont consider it valid to argue that dbus isn't for desktop linux. All major desktop environments and several critical desktop applications depend on it. Note that systemd depends on the dbus protocol and not the daemon. Android certainly doesn't count as evidence for that considering that it is a entirely separate ecosystem that shares pretty much nothing other than the kernel.
Posted Jun 11, 2012 17:57 UTC (Mon) by sfeam (subscriber, #2841)
Posted Jun 11, 2012 18:10 UTC (Mon) by rahulsundaram (subscriber, #21946)
Posted Jun 11, 2012 18:45 UTC (Mon) by sfeam (subscriber, #2841)
Posted Jun 11, 2012 18:52 UTC (Mon) by rahulsundaram (subscriber, #21946)
Posted Jun 11, 2012 18:35 UTC (Mon) by nlucas (subscriber, #33793)
I did say that dbus is an important desktop package, so we don't disagree there (we could disagree on if it should be or is desirable that it is, but that's irrelevant). I don't think it's an essential package, but it's certainly desirable for everything to work as expected from the user point of view. It certainly is possible to use a Linux system, even with X, without it.
My point was that dbus is not an essential package on every system (servers, for example, if you believe Android and the other billions of custom systems are irrelevant), so udev should never depend on it, in the same way that udev should never depend on systemd, because it's another non-essential package.
Note that I'm not saying udev should remove all DBUS interfaces it already implements. I'm just saying it should be possible to use it without dbus.
In the same way, there is no problem on udev implementing systemd hooks, as long as it doesn't force the use of systemd to udev users.
There is nothing strange here. The same can be said on any other non-essential package, like having udev depend on python, or java. But nothing forbids udev for having python or java interfaces on the systems where they are available.
Posted Jun 11, 2012 18:48 UTC (Mon) by rahulsundaram (subscriber, #21946)
Posted Jun 11, 2012 21:20 UTC (Mon) by nlucas (subscriber, #33793)
I don't agree with you on dbus, but that's irrelevant (just because dbus can be used on a server doesn't mean it's required or essential).
Posted Jun 12, 2012 10:31 UTC (Tue) by cortana (subscriber, #24596)
OTOH we could end up in the situation evoked by http://xkcd.com/927/. Maybe it's naive to be so optimistic, but a world where everything in http://www.freedesktop.org/wiki/Software/systemd/Interfac... is adopted by all distributions would be quite pleasant: a world where you could configure all this low-level stuff on any distribution without having to deal with all the pointless differences between them.
http://0pointer.de/blog/projects/the-new-configuration-fi... has more info about the rationale for all of this. Admittedly it's a long shot for the distributions that aren't adopting systemd as their primary init system.
Posted Jun 12, 2012 11:00 UTC (Tue) by nlucas (subscriber, #33793)
You may never heard of /lib/udev/devices but that just means you never needed it. It was added when /dev started being a tmpfs filesystem (and now devtmpfs), because devices were no longer preserved across reboots.
At the time was not an API break, because people could still use a static /dev, and so was backward compatible. In the meantime other breakages occurred.
Anyway, the problem here is not this specific feature: it's the fact that udev AGAIN broke an API. The problem is not systemd or any other software, it's the fact people working on the core Linux plumbing are constantly annoying it's users.
This would not be a problem if we had some user-space wrapper abstracting this lower level stuff. But we do not, so please don't regard low level APIs as things that can change any time just because they can. They are as much standard APIs as brk(), sbrk() or malloc(), and there are people using it.
Posted Jun 12, 2012 12:08 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
Udev's primary API is /dev filesystem structure - which is stable, btw.
Posted Jun 12, 2012 13:06 UTC (Tue) by nlucas (subscriber, #33793)
/dev is only one of the udev API's. libudev is another, as are the DBUS bindings.
The udev rules are another API (one that is constantly breaking too).
None of them should be considered second order APIs. If they exist they will be used by someone somewhere. If they break, someone will be annoyed. If they are constantly breaking more "someones" will be annoyed.
One thing that seems not everyone grasps is that Linux has probably more usage in customized systems than on desktops. udev was published as the rescue for this low-level plumbing, even on customized systems, because USB happened (needed to load modules on demand, creating/removing devices, etc). This systems could use other things (like mdev), but udev is the only one generic enough for most usages (mdev doesn't cover all modular cases).
Android decided to not use udev, but it will need to reinvent it (if it doesn't start using it) for the generic tablet cases (when tablets, maybe docked, replace laptops).
Posted Jun 12, 2012 13:09 UTC (Tue) by nlucas (subscriber, #33793)
The problem is the constant breakage, not one or other "flag day".
Posted Jun 13, 2012 16:24 UTC (Wed) by nix (subscriber, #2304)
(However, they *are* very good at telling you what the compatibility breaks will be, so you *can* adapt to them. But every upgrade feels like skydiving with a possibly-broken parachute, and it shouldn't.)
Posted Jun 11, 2012 22:07 UTC (Mon) by nix (subscriber, #2304)
Either way, a user-space udev API was broken.
I'm frankly sick of it, so I'm sticking with udev 175 until it breaks, and then backporting appropriate kernel changes to keep it working, or forking it with the intent of maximum compatibility with existing installations, whichever is easier.
Posted Jun 11, 2012 22:59 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)
Udev is a very low-level component. Why are you maintaining your own config instead of using distro-provided one (maybe with small customizations)?
Posted Jun 12, 2012 7:33 UTC (Tue) by nix (subscriber, #2304)
There are few distros optimized for stick-in-the-muds who also need to use and patch bleeding edge low-level software, and I can understand that. Nobody else is likely to want to use the same combinations of bleeding-edge stuff as I am, and handling all the possible combinations is a combinatorial explosion. Most people in this position use a distro, locally compile lots of stuff, and try to cope with the much-too-frequent disruptive UI changes. I'm not willing to do that. Sometimes this means I whine about people who assume that everyone uses a distro that someone else maintains (and that downgrades never happen) and that they can break low-level components' compatibility frequently without anyone at all caring. People like me do still exist. We may be a small constituency of control-freakish eccentrics but we are not nonexistent. :)
(As a side note, the reasonably high degree of low-level knowledge that doing this sort of thing requires *did* actually get me a pretty damn good job. So it wasn't a complete waste of time after all!)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds