Re: Seeking help addressing maintainer objections

Ian Pilcher <[email protected]> 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
[email protected]
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies