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
I guess 1) is needed to load modules on demand (if possible),
loading a module will kick 2) I guess.
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 ?
I read
http://www.linuxfromscratch.org/lfs/view/development/chapter07/udev.html
but it seems that these two types of events are not distinguished ?
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.
Sometimes you get an "ADD" uevent when a driver binds,
sometimes you get an "ADD" uevent when a physical device is
detected and later you get a "BIND" event when a driver is bound.
Further more it seems udev code and rules assume that "ADD" events in
principle mean a device driver is now available ?
Even if this is not really the case ?
so long
Ingo
