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

[Greg KH <gregkh@linuxfoundation.org>]

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