Messages in this thread | | | Date | Mon, 24 Dec 2018 19:13:24 +0100 | From | Christian Brauner <> | Subject | Re: FYI: Userland breakage caused by udev bind commit |
| |
On Mon, Dec 24, 2018 at 10:06:54AM -0800, Linus Torvalds wrote: > On Mon, Dec 24, 2018 at 9:34 AM Dmitry Torokhov > <dmitry.torokhov@gmail.com> wrote: > > > > Well, it appears that we can no longer extend uevent interface with new > > types of uevents, at least not until we go and fix up all > > udev-derivatives and give some time for things to settle. > > How about having the users "opt in" for new events some way? > > Do all the legacy events by default, but then if some user wants a > "bind" event (or some other new event) add a model for the uevent > interface to actually enable it.
So one possibility is to add a socket option for lib/kobject_uevent.c that can be set via setsockopt. We did something like this in netlink for strict property and header checking without breaking backwards compatibility. That might be an option:
commit cd7f7df6ca3366be4ac79e824fdaa8d482270015 Merge: 272a66173bbc 8c6e137fbc7f Author: David S. Miller <davem@davemloft.net> Date: Mon Oct 8 10:39:06 2018 -0700
Merge branch 'rtnetlink-Add-support-for-rigid-checking-of-data-in-dump-request'
David Ahern says:
==================== rtnetlink: Add support for rigid checking of data in dump request
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=cd7f7df6ca3366be4ac79e824fdaa8d482270015
or adding a new flag that can be passed when opening a NETLINK_KOBJECT_UEVENT socket.
Christian
> > Not using kernel versioning (nothing should *ever* look at the kernel > version, since that makes things like backports a huge and > insurmountable pain), but simply using some specific control channel. > > > I guess reverting is the right solution here. I wish folks would yell > > earlier though... > > So nobody is actually using the new "bind" event, I take it? It's > about a year and a half, and it's in 4.14 which is widely used, so > reverting it has a risk too. > > Which is why I too would hope people would be much more vocal about > "that broke my setup". > > But reverting does sound like the right thing to do if nobody is using > it. It sounds like systemd udev does not, and if eudev is actively > broken by this then how many other cases might there be? > > I assume any locally modified udev rules would still be ok with the > revert (since presumably any udev rule modification people did was to > just ignore the bind/unbind events that no longer would be sent). > > Linus
| |