On Mon, Dec 02, 2019 at 03:28:57PM +0100, Ingo Rohloff wrote:
> Hello,
>
> I recently had some problems with "bind"/"unbind" uevents, created
> when a user space program grabs an USB interface via
>
> ioctl(usb_fd, USBDEVFS_CLAIMINTERFACE, &usb_intf_nr);
>
> TL;DR
> I wonder if there isn't a semantic issue what the
> "bind"/"unbind" and "add"/"remove" uevents mean.
>
>
> I mainly refer to commit 1455cf8dbfd0 ("driver core: emit
> uevents when device is bound to a driver")
>
> I certainly do not know enough about the kernel; so at least I want
> to put my questions here, in the hope that somebody who has a better
> understanding of the Linux kernel reads it.
>
> Maybe this is just me misunderstanding how uevents work.
>
> I read the log message of commit 1455cf8dbfd0 ("driver core: emit
> uevents when device is bound to a driver")
>
> In particular this sentence:
> These udev actions can not use ADD events, as those
> happen too early, so we are introducing BIND and UNBIND
> events that are emitted at the right moment.
>
> So as far as I understand the issue is that ADD events happen too
> soon.
>
> I am wondering if the core of the problem is the meaning of the
> word "device" under Unix in general. As far as I can tell, the
> word "device" under Unix is very often used synonymous with
> "device driver".
>
> Example: "Block and Character devices" it seems you are talking
> about the device drivers here, not about the physical devices.
>
> For the rest I will try to be specific using the terms
> "device driver" and "physical device" to differentiate.
>
> I think for "add"/"remove" uevents it is not clear what exactly
> these events refer to (do they refer to the availability of a
> device driver or to the detection of a physical device).
>
>
> Example: I plug a USB pendrive into my PC and monitor the kernel
> uevents via "udevadm montior -k -p".
>
> The first uevent I get is:
> KERNEL[30080.233898] add /devices/pci.../usb4/4-2 (usb)
> ACTION=add
> BUSNUM=004
> DEVNAME=/dev/bus/usb/004/003
> DEVNUM=003
> DEVPATH=/devices/pci.../usb4/4-2
> DEVTYPE=usb_device
> MAJOR=189
> MINOR=386
> PRODUCT=90c/1000/1100
> SEQNUM=6896
> SUBSYSTEM=usb
> TYPE=0/0/0
>
> I think this particular event refers to a physical device ?
>
> I have not traced back the source of this event, but maybe
> it's some USB HUB, which detects that a new physical device was
> plugged (or maybe not; I really have no clue).
>
> Interestingly there already is a "MAJOR/MINOR" number and a path
> into /dev/...
> I am wondering: If at that moment (directly after the ADD uevent)
> I would try to open /dev/bus/usb/004/003 would that work ?
> The origin of the question:
> Would there be a device driver to which user space might talk ?
>
> Later I get this uevent:
> KERNEL[30080.242045] bind /devices/pci.../usb4/4-2 (usb)
> ACTION=bind
> BUSNUM=004
> DEVNAME=/dev/bus/usb/004/003
> DEVNUM=003
> DEVPATH=/devices/pci.../usb4/4-2
> DEVTYPE=usb_device
> DRIVER=usb
> MAJOR=189
> MINOR=386
> PRODUCT=90c/1000/1100
> SEQNUM=6901
> SUBSYSTEM=usb
> TYPE=0/0/0
>
> I think this means if I would NOW open
> /dev/bus/usb/004/003 I would talk to the device driver "usb" ?
>
>
> The reason why I am wondering about semantics: Later I get
> KERNEL[30081.480770] add /devices/pci.../block/sda/sda1 (block)
> ACTION=add
> DEVNAME=/dev/sda1
> DEVPATH=/devices/pci.../block/sda/sda1
> DEVTYPE=partition
> MAJOR=8
> MINOR=1
> PARTN=1
> SEQNUM=6911
> SUBSYSTEM=block
>
> Now this uevent seems to refer to a device driver and not to a
> physical device ?
> This uevent is not followed up by a "bind" event, so I guess this
> has already happened (so a device driver is already bound to the
> partition).
>
> I guess udev needs both types of events:
>
> 1) physical device was detected
> 2) device driver was bound
It needs more than just that:
3) when a "struct device" is created within the kernel
Actually, udev doesn't need any of this as it doesn't do a ton of stuff
anymore now that devtmpfs is the primary handler for all device nodes.
not to say that udev doesn't still do a lot, but don't think of udev as
the thing that manages the creation of /dev nodes, as it hasn't done
that for a very long time now.
> I guess 1) is needed to load modules on demand (if possible),
Yes.
> loading a module will kick 2) I guess.
Yes.
> I guess 2) is needed to create device nodes under /dev/* and to run
> arbitrary actions (like mounting, loading firmware etc) once a
> device driver is bound to a physical device. I guess it does not
> make sense to create device nodes or run actions before a device
> driver is bound ?
It's physically impossible to create a /dev node before a driver binds
to a device.
> I read
> http://www.linuxfromscratch.org/lfs/view/development/chapter07/udev.html
> but it seems that these two types of events are not distinguished ?
Yes, they are very different, look at all of the information in the
different uevent, they should not be the same at all.
> It seems to me that the origin of commit 1455cf8dbfd0
> ("driver core: emit uevents when device is bound to a driver")
> is that there is no clear distinction between these two
> types of event.
No, that commit was added because userspace did not know when a driver
was bound to a device and so it did not know when it was "ok" to look at
all of the attributes of the device (as doing the binding usually
creates a bunch of new attributes.) Now that this new uevent happens,
userspace "knows" it is safe to scan the attributes, otherwise it never
really knew the device had a change of "state" from bound to unbound and
knew to look for new attributes, or attributes that might have gone
away.
> Sometimes you get an "ADD" uevent when a driver binds,
No, you get an ADD event when a new "struct device" is registered with
the driver core.
> sometimes you get an "ADD" uevent when a physical device is
> detected and later you get a "BIND" event when a driver is bound.
"struct device" does not always correlate with physical devices, there
are loads of "fake" devices in the system that you interact with all the
time (/dev/null is one fun example.)
> Further more it seems udev code and rules assume that "ADD" events in
> principle mean a device driver is now available ?
No, drivers are totally separate here. They do not cause uevents to
happen, except by virtue of code in them that happens to allow a driver
to be bound to a device that is already created.
Did that help?
You might want to read the driver model chapter in the book, "Linux
Device Drivers, 3rd edition" for more details. It's free online, and a
bit old but the basic concepts should be the same.
thanks,
greg k-h
