Ian Pilcher <arequipeno@gmail.com> 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/driv... 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/dr...
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/driv... https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/dr... Bjørn