From: Ingo Rohloff <ingo.rohloff@lauterbach.com>
To: linux-hotplug@vger.kernel.org
Subject: driver core: Do uevents have a semantic problem ?
Date: Mon, 02 Dec 2019 14:28:57 +0000 [thread overview]
Message-ID: <20191202152850.23a0f621@ingpc3.intern.lauterbach.com> (raw)
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≠d
BUSNUM\04
DEVNAME=/dev/bus/usb/004/003
DEVNUM\03
DEVPATH=/devices/pci.../usb4/4-2
DEVTYPE=usb_device
MAJOR\x189
MINOR86
PRODUCTêc/1000/1100
SEQNUMh96
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\04
DEVNAME=/dev/bus/usb/004/003
DEVNUM\03
DEVPATH=/devices/pci.../usb4/4-2
DEVTYPE=usb_device
DRIVER=usb
MAJOR\x189
MINOR86
PRODUCTêc/1000/1100
SEQNUMi01
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≠d
DEVNAME=/dev/sda1
DEVPATH=/devices/pci.../block/sda/sda1
DEVTYPE=partition
MAJOR=8
MINOR=1
PARTN=1
SEQNUMi11
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
next reply other threads:[~2019-12-02 14:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-02 14:28 Ingo Rohloff [this message]
2019-12-02 15:02 ` driver core: Do uevents have a semantic problem ? Greg KH
2019-12-02 18:43 ` Ingo Rohloff
2019-12-06 16:18 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191202152850.23a0f621@ingpc3.intern.lauterbach.com \
--to=ingo.rohloff@lauterbach.com \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).