[PATCH] mdev: special rule to create iio devices

[Isaac Dunham]

On Tue, Oct 27, 2015 at 04:22:35PM +0100, Linus Walleij wrote:
> On Wed, Oct 21, 2015 at 4:42 PM, Greg Kroah-Hartman
> <gregkh at linuxfoundation.org> wrote:
> > On Wed, Oct 21, 2015 at 11:06:15AM +0200, Linus Walleij wrote:
> 
> >> IIO devices do not appear under sys/class and thus need
> >> a special hook to be created properly by mdev.
> >
> > Why?  Are they not "normal" device nodes and devices?
> 
> They don't have a class, that's all I know, and mdev require
> devices to have a class for coldplug :/

I thought all devices were supposed to have a class.

> >> Busybox mdev is traversing /sys/class looking for ".../dev"
> >> suffixes that are device nodes to create /dev device nodes,
> >> but the device core maintainer (Greg) disapproves the use
> >> of class devices, advocating busses.
> >
> > mdev shouldn't have to traverse anything, it should listen to uevent
> > messages and get the information there, no need to special-case any
> > sysfs path.

FYI: mdev uses the hotplug helper interface, not the netlink interface.

> I think what you say is true, for hotplug, once userspace is
> up and running. But these IIO devices are detected with a
> mdev-specific coldplug heuristic as described below...
> 
> > Why doesn't udev have this same issue?
> 
> udev will create devices after coldplug/boot with:
> 
> udevadm trigger --action add
> udevadm settle
> 
> Which makes all added device add actions be replayed as if
> they happened right now.
> 
> I looked briefly at udev and it seems it does this: call
> udev_enumerate_scan_subsystems() from libudev, which
> calls device_enumerator_scan_subsystems() from libsystemd
> which (surprise!) scans /sys/subsystem or /sys/bus depending
> on if the former exists, then (surprise!) traverse sysfs to find
> */uevent files and re-trigger device addition by writing
> "add" to these files.
> 
> So there is indeed some traversing sysfs going on in the
> udev case as well.
> 
> mdev instead has two ways of handling things: mdev -s at
> coldplug/boot and later being called as hotplug helper. The source
> code says this:
> 
> (...)
> /* "mdev -s" scans /sys/class/xxx, looking for directories which have dev
>  * file (it is of the form "M:m\n"). Example: /sys/class/tty/tty0/dev
>  * contains "4:0\n". Directory name is taken as device name, path component
>  * directly after /sys/class/ as subsystem. In this example, "tty0" and "tty".
>  * Then mdev creates the /dev/device_name node.
>  * If /sys/class/.../dev file does not exist, mdev still may act
>  * on this device: see "@|$|*command args..." parameter in config file.
>  *
>  * mdev w/o parameters is called as hotplug helper. It takes device
>  * and subsystem names from $DEVPATH and $SUBSYSTEM, extracts
>  * maj,min from "/sys/$DEVPATH/dev" and also examines
>  * $ACTION ("add"/"delete") and $FIRMWARE.
>  *
>  * If action is "add", mdev creates /dev/device_name similarly to mdev -s.
>  * (todo: explain "delete" and $FIRMWARE)
>  *
>  * If /etc/mdev.conf exists, it may modify /dev/device_name's properties.
> (...)
> 
> mdev -s does a bad job at what it does since it can only handle
> /sys/class devices and also put some requirements on how
> sysfs files are named. It results in missing iio devices as the
> patch illustrates.


This thread is the first I've heard of a device that doesn't have a
class, though that doesn't mean much.
But I can give you an overview of the logic behind some of the decisions
regarding mdev, having read explanations numerous times.

- mdev is initialized by scanning sysfs rather than simulating a series
of hotplug events because otherwise, you will end up essentially
forkbombing your computer at boot.
In theory, all the information is available in various files, and if you
can find the correct files you can avoid simulating a hotplug.

- to avoid spawning mdev for every hotplug event you need to listen to
netlink, which isn't very small in terms of binary size.
(There was work to solve this by making mdev read events from stdin,
a/k/a "mdev -i", and then have a separate netlink listener that
writes events to stdout. This work has bitrotted over the last 6 months,
though I could probably get it updated without *too* much work.
There are existing non-Busybox netlink listeners that can work with
the proposed design.)

- If I understood correctly, mdev -s scans /sys/class because at the time
that /sys/class was introduced, it was billed as the one place you could
find a nearly flat list of all devices, without duplication.
Using /sys/dev/{char,block}/ might actually provide that, though it will
take a big change in the code.

- mdev uses basename(devpath) as the default name because on older
kernels, that is the only way to find the name of a device from sysfs.


Thanks,
Isaac Dunham