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
