Thank you for the quick reply, Jonathan Cameron wrote on Wed, Feb 28, 2024 at 02:24:41PM +0000: > > > Maybe I don't get your point, but your email said "sysfs", so why do you > > > refer to /dev? > > > > I wrote /dev/rtc0, but it also sets the name in /sys, right? > > For example /sys/class/rtc/rtc0 > > > > As far as I'm aware iio also creates character devices in /dev with the > > same name (/dev/iio/iio:deviceX), but our application doesn't use these > > at all and has to? look in /sys directly, so normal udev SYMLINK+= > > unfortunately isn't applicable or I wouldn't be bothering with all > > this.. > > A given IIO device driver may create multiple sysfs directories (registers > device + one or more triggers), so I'm not sure how this would work. Thanks for pointing this out, the driver I'm using doesn't seem to create extra triggers (iio_trigger_alloc doesn't seem to be called), but the current patch would only affect iio_device_register, so presumably would have no impact for these extra directories. (There's also no impact without dt changes, it's only adding an extra way of fixing the X of iio:deviceX everywhere) > > Unfortunately for iio it looks like labels isn't ignored, but instead > > create a file in the sysfs directory of the device, e.g. I now have > > /sys/bus/iio/devices/iio:device1/label which contains the label string, > > so I'm not sure that can be changed easily as that'd be a change of API > > for existing users for labels in iio devices? > > Yes, don't touch that ABI. IIO software assumes naming of > iio\:deviceX etc. > > > (I checked briefly and didn't find any, but there seems to be an awful > > lot of code in the iio drivers tree about labels so I'm not really > > comfortable changing that without some more background on iio first... > > Jonathan perhaps has an opinion on this?) > > There are labels for channels as well as devices, but the short description > you have above is it. > > I don't see why that isn't sufficient for your use case though? I'll have a lot of trouble arguing that one out as I agree it's "not that hard" to check the names to get the correct IIO device, but it's still definitely more work than being able to use fixed names. For more background, we're selling a device+platform where our users can write code themselves to read the sensors, with a variable number of sensors (extension cards can be plugged in offline, reboot and you get one more). Adding an extra device currently comes in first and renames all pre-existing ones because that's apparently the order linux gets them from the dtb after adding overlays, and it'd "look better" if devices get added in fixed order so our users don't need to deal with the checking names/labels logic. toradex apparently has the same need because they provide a script that crates ugly links from /dev/xxx-adcY to /sys/.../in_voltageY_raw, so it's not like we're the first ones to want something like this; I think however that udev isn't appropriate to create links to /sys, so having some way of fixing names in dts sounds better to me. > What does a directory name matter when you can write a few lines of > code to retrieve the IIO device that you want. > > If this was day 0 maybe we could support renaming devices like this > but we have a long history of those names not being stable and label > + parentage of the IIO devices being used to establish stable identification. I'm sure we can make something work out while preserving compatibility, the patch I sent might not be great but it wouldn't bother anyone not using said aliases. aliases are apparently not appropriate for this (still not sure why?), but if for example labels are better we could keep the current iio:deviceX path (/sys/bus/iio/devices/iio:device0) with a label file in it as current software expect, but add a brand new directory with a link named as per the label itself (for example /sys/class/iio/<label>; my understanding is that /sys/class is meant for "easier" links and we don't have anything iio-related there yet) That wouldn't break users checking through the existing paths, and provide a new fixed path for anyone looking for it. > Anything beyond a trivial single use script is going to need to deal with > not having stable names (old kernel, dt without alias etc) so this doesn't > help in general. I'm sure any major software will have to deal with old kernels, but I disagree that it doesn't help: in our case described above our users are basically writing trivial scripts and won't ever be downgrading, we want to guarantee they can rely on fixed names for our hardware because I know for sure most won't be bothering to check. Even for major softwares, any feature written now will hopefully be considered generally available 20 years from now, we need to start somewhere. Thanks, -- Dominique
