On Mon, 18 Mar 2024 12:29:53 +0000 Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> wrote: > On Mon, 18 Mar 2024 11:15:36 +0900 > Dominique Martinet <dominique.martinet@xxxxxxxxxxxxxxxxx> wrote: > > > David Lechner wrote on Fri, Mar 15, 2024 at 10:53:36AM -0500: > > > How about using udev rules to create symlinks for each device based on > > > the label attribute? No changes to the kernel are needed. > > > > Right, it's definitely possible to make symlinks for each "device" -- my > > patch comment links to such an udev script "solution": > > https://git.toradex.com/cgit/meta-toradex-bsp-common.git/tree/recipes-core/udev/files/verdin-imx8mm/toradex-adc.sh?h=kirkstone-6.x.y > > (the script is launched by udev here: > > https://git.toradex.com/cgit/meta-toradex-bsp-common.git/tree/recipes-core/udev/files/verdin-imx8mm/99-toradex.rules > > ) > > > > My conceptual problem with this is that this makes symlinks in /dev to > > files in /sys and it feels like we're crossing boundaries. > > As far as I can tell there is no way for userspace to create arbitrary > > symlinks in /sys, so I think we could have an interface more > > user-friendly by allowing paths to be static for users with multiple > > devices. > > (I guess that's a weak argument given e.g. disks etc will also have an > > unreliable name in /sys in the general case, but simple programs don't > > interact with them in /sys and can use stable links in /dev so my > > expectations here aren't quite the same) > > > > > > Ultimately, the problem might run deeper in that we're having userspace > > interact with the device through /sys and not the /dev char dev... As > > far as I could see /dev/iio:deviceX only allows reading buffered values > > and doesn't have any ioctl or other way of reading immediate values as > > is possible in /sys though, so that'd require quite a bit of work to > > duplicate the interface there... > > Don't. The sysfs interface as only control is entirely intentional and > we do not want IOCTL based duplication. > > Just addressing this bit as I'm still a bit snowed under to think about this > more generally. > Hi, got back to this finally... So the problems compared to other 'alias' users is that IIO is a bit more complex than for example LEDs. A single DT node/compatible (or equivalent) can result in a 1+ IIO devices and 1+ triggers. Triggers can also be instantiated via configfs (technically devices can as well but we can ignore that). Any alias scheme needs to work for all these options. To my mind that makes it a userspace problem, not something the kernel can deal with in generic enough way. I think that all IIO devices have ways to stability identify them (label, or parent devices) There is an approximate equivalent of DT alias entries in SMBIOS but I suspect not all ACPI platforms will provide that (it's typically used for stable disk / network device naming on complex servers). So I've messed around a bit and can think of various possible options to make this simpler. 1) Use a tmpfs mount and link from that. Now we 'could' put an alias directory somewhere under /sys/bus/iio/ that is a mount point created via sysfs_create_mount_point() - I abused the /sys/kernel/debug directory to test this (unmounted debugfs and mounted a tmpfs). That would provide somewhere in sysfs that allows suitable links. However, this is unusual so likely to be controversial. 2) Alternatively the relevant platform could create one of these somewhere outside of sysfs and use udev rules to create the links. 3) Stick to the oddity of doing it under /dev/ 4) Access the things in the first place via more stable paths? /sys/bus/i2c/devices/i2c-0/0-0008/iio\:device?/ etc Relying on the alias support for i2c bus numbering to make that stable should work and if you are sure there will only be one entry (most devices) that matches the wild card, should be easy enough to use in scripts. My personal preference is this last option. Basically if you want stable paths don't use /sys/bus/iio/devices/ to get them. Jonathan
