2018-01-12 23:10 GMT-03:00 Laurent Bercot:
>
> There are modules for which a /sys/class entry, and an appropriate
> major/minor pair for mdevd to create the device node, only appear when
> the module is loaded, and there's no prior uevent file to trigger
> loading the module: the one I've tested it on is ppp_generic.
> /sys/class/ppp/ppp/uevent only appears once you modprobe ppp_generic, at
> the same time as /sys/dev/char/108:0. So even scanning /sys/class
> does not guarantee you'll get events for all the modules you need.
> It probably has to do with the fact that ppp_generic isn't tied to
> any hardware in particular; whereas in Olivier's instance, I suspect
> the hardware was already visible somewhere under /sys/bus.
I'm leaning towards the same explanation. I don't think the device
manager was ever expected to load *all* needed modules, only the
hardware related ones. After all, systemd also has modules-load.d to
explicitly request loading them:
*
https://www.freedesktop.org/software/systemd/man/modules-load.d.html
> The only explanation I see is that the canonical way of triggering
> uevents changed after landley stopped being involved in sysfs and mdev.
> I think this is likely, since his doc mentions the obsolete (but still
> present) /sys/block hierarchy.
As a side note, /sys/block is duplicated in /sys/class/block, and
caught by the /sys/class/*/* scan. On my computer, disks and disk
partitions, for example, are only found there. I also wondered why
'udevadm trigger' didn't access /sys/block.
> Anyway, I will change to what udev does; but this is annoying because
> it requires a rearchitecture, so it will take some time.
>
> With the mdev -s model, it was possible to just read from sysfs,
> synthesize events, and send the synthetic events to a dedicated mdevd
> instance. With the udevadm trigger model, this is not what happens:
> instead of reading from sysfs and synthesizing events, the coldplugger
> actually pokes the kernel, which creates real events; and the netlink
> listener must be up in order to receive and process them.
I'm not sure you'd need to modify this part. The uevent files can
still be read, systemd does try to read IFINDEX, MAJOR and MINOR from
them during enumerator_scan_dir_and_add_devices(), and from what I've
seen, the information you can read from them is pretty much the same
as what you get from events triggered by writing to them. I'll tell
you what, I'm going to try doing both things (using eudev's 'udevadm
monitor' to check the netlink part) and see if I get the same results.
G.
Received on Sat Jan 13 2018 - 15:40:29 UTC