Ian Pilcher <arequipeno@xxxxxxxxx> writes: > The maintainer of the LEDs subsystem considers this interface to be > "crazy", but he has not suggested any alternative.[3] I read a strong suggestion that one of the unlink interfaces is dropped. You should probably read "crazy" as "unjustified". > (I have not been able to find any existing example of configuring > many-to-many relationships via sysfs.) There's at least one such example, hidden under drivers/usb: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/core/ledtrig-usbport.c See the initial commit for justification and some of the background for the choices made: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/core/ledtrig-usbport.c?id=0f247626cbbfa2010d2b86fdee652605e084e248 > The second problem is the use of device file paths (including symbolic > link resolution), rather than kernel names, when creating associations. > This limitation exists because the block subsystem does not provide an > API to open a block device by its kernel name; only device file paths > and device numbers (major & minor) are supported. So this explains why you can't have link_dev_by_path. It still does not explain why you need unlink_dev_by_name. And if file name with symlink resolution really is a problem, then why can't you use the major:minor for link/unlink? That's easy for userspace to look up whether the input is a device path or a sysfs path. And it avoids having to wait for an unrelated and unnecessary device path creation. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/core/ledtrig-usbport.c https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/core/ledtrig-usbport.c?id=0f247626cbbfa2010d2b86fdee652605e084e248 Bjørn _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
