Jonathan Cameron wrote on Sun, Mar 31, 2024 at 03:20:42PM +0100: > Hi, got back to this finally... Thank you for taking the time to express your thoughts! > 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. Right. I'm no longer really arguing for it at this point, but for comparison in the patch I sent, the alias sets the start of the idr for the device index, so if you have a driver that creates two IIO devices you could just "reserve" two for this DT node and assuming the order within this node is constant you'd still get constant numbering, so I think it still somewhat holds up here. For triggers though the numbers are separate and it wouldn't make sense to use the same alias, if we wanted a coherent design with this we'd need to add a second alias (such as iio_trigger = ..), but that makes much less sense to me given they're also likely to be dynamically instancied via configfs from what I've seen; I wouldn't want to do this kind of mapping, so I agree with you. > 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. Agreed that's probably not something we want to put our hands into. > 2) Alternatively the relevant platform could create one of these somewhere > outside of sysfs and use udev rules to create the links. I'm not sure I understood this one, something akin to the udev rules I've showed that made links to the /sys iio device in /dev? "relevant platform" here would be vendors? > 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. Hmm, I wouldn't call that path stable given the '?' portion can change, but at least that certainly is a single glob away so it's definitely simpler than checking every labels all the time. My second nitpick with this is that while these paths are stable for a given kernel version, but we've had some paths changes over many years (not sure if it was 3.14 or 4.9 but one of these perhaps didn't have /sys/devices/platform yet? and things got moved there at some point with some subtle name changes, breaking a couple of scripts). OTOH /sys/bus/iio/devices feels less likely to change, but I guess this is something that'd come up on tests when preparing a new kernel anyway, so this is probably acceptable; I'm just thinking out loud. With that said I can't think of anything that'd work everywhere either, so I guess we can stick to the status-quo and I'll rediscuss what we want to do with coworkers. Thanks, -- Dominique
