Re: Seeking help addressing maintainer objections

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4/3/24 06:38, Bjørn Mork wrote:
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

Thanks! Will take a look at that.

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.

It's not absolutely needed, but it does make it easier to unlink an LED
from all devices by using the names of the symlinks in the LED's
linked_devices directory, which will be kernel names.

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

Personally, I don't think that using file paths is a problem, and it
can be useful.  ("/dev/vg_root/lv_root" is probably more useful than
"dm-0".)  OTOH, "sda" is slightly simpler than "/dev/sda", so I think
that the ideal situation would be to have both interfaces available.

I did propose using device numbers.  I never received a response from
the maintainer.

Thanks for taking the time to respond to this!

--
========================================================================
If your user interface is intuitive in retrospect ... it isn't intuitive
========================================================================


_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies




[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]

  Powered by Linux