driver core: Do uevents have a semantic problem ?

driver core: Do uevents have a semantic problem ?

[Ingo Rohloff]

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

Re: driver core: Do uevents have a semantic problem ?

[Greg KH]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1252", Size: 7016 bytes --]

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­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


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

Re: driver core: Do uevents have a semantic problem ?

[Ingo Rohloff]

Hello,

I guess this is still me not understanding the Linux Device Model.

> > 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 didn't know the right terminology, after reading up on it,
("Linux Device Drivers, 3rd edition")
here is hopefully a better try.


I guess udev needs both types of events:

1) "struct device" was allocated
2) "struct device_driver" was bound to "struct device"
   (I think "matched" and then bound in kernel terminology ?)

Let me be concrete:
As far as I can tell udev handles file permissions and group ownership
for a lot of "/dev/*" nodes (and it creates appropriate symlinks).

My question is:
Should "udev" set file permissions and group ownership on
1) or 2) or both ?
(It also seems 2) very often is not communicated via a uevent,
so a "bind" event is not emitted.)

My thinking was it should only do that on 2).
Rationale:
My understanding is, that all the file operations for a /dev/* node
are implemented in code which implements a "struct device_driver".
Am I just wrong here and the file operations are actually done 
per "struct device" and not per "struct device_driver" or per both ?

So before I have bound a "struct device_driver" to a "struct device" 
it doesn't even make sense to try to do anything with a /dev/* node; 
or is this a mis-understanding ?

I guess you might set file permission, group ownership and create a 
symlink  once the /dev/* node exists 
(I don't know if this happens at 1) or 2)).

But my assumption is you might only run actions 
(like opening the /dev/* node and doing some ioctl) once a 
"struct device_driver" is bound to "struct device".

Probably I simply don't get it:
Maybe both "struct device" and "struct device_driver" might expose 
/dev/* node entries, with accompanying "struct file_operations" ?

with best regards
  Ingo

Re: driver core: Do uevents have a semantic problem ?

[Greg KH]

On Mon, Dec 02, 2019 at 07:43:49PM +0100, Ingo Rohloff wrote:
> Hello,
> 
> I guess this is still me not understanding the Linux Device Model.
> 
> > > 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 didn't know the right terminology, after reading up on it,
> ("Linux Device Drivers, 3rd edition")
> here is hopefully a better try.
> 
> 
> I guess udev needs both types of events:
> 
> 1) "struct device" was allocated
> 2) "struct device_driver" was bound to "struct device"
>    (I think "matched" and then bound in kernel terminology ?)

This last event is "new" with the commit you referenced before.  For the
previous 15+ years, we did not have that event.

> Let me be concrete:
> As far as I can tell udev handles file permissions and group ownership
> for a lot of "/dev/*" nodes (and it creates appropriate symlinks).

Yes, for most.

> My question is:
> Should "udev" set file permissions and group ownership on
> 1) or 2) or both ?
> (It also seems 2) very often is not communicated via a uevent,
> so a "bind" event is not emitted.)

I think you are missing the connection between /dev/ nodes and other
parts of the kernel.  /dev/ nodes are not always associated with most
"struct device" structures in the kernel.  They are only a much smaller
number that actually are relevant.

Also note that a /dev/ node only shows up _after_ a driver binds to a
device, and when that happens, a "class device" is created that
represents how userspace can talk to a specific class of hardware.

So in your list above, 1) is when udev handles /dev/ node stuff, but
that's only a much more infrequent event overall (look at everything in
/sys/devices/ for proof of that.)

> My thinking was it should only do that on 2).

Nope.

> Rationale:
> My understanding is, that all the file operations for a /dev/* node
> are implemented in code which implements a "struct device_driver".
> Am I just wrong here and the file operations are actually done 
> per "struct device" and not per "struct device_driver" or per both ?

Only on a small number of "struct device"s that are created.

> So before I have bound a "struct device_driver" to a "struct device" 
> it doesn't even make sense to try to do anything with a /dev/* node; 
> or is this a mis-understanding ?

You can't even get to a /dev/ node then.

> I guess you might set file permission, group ownership and create a 
> symlink  once the /dev/* node exists 
> (I don't know if this happens at 1) or 2)).
> 
> But my assumption is you might only run actions 
> (like opening the /dev/* node and doing some ioctl) once a 
> "struct device_driver" is bound to "struct device".
> 
> Probably I simply don't get it:
> Maybe both "struct device" and "struct device_driver" might expose 
> /dev/* node entries, with accompanying "struct file_operations" ?

I would recommend stepping through the basic driver examples in the LDD3
book for an understanding of what is going on here.  THere's a lot more
steps happening :)

hope this helps,

greg k-h