Re: [PATCH v11 1/2] docs: Add block device (blkdev) LED trigger documentation

[Ian Pilcher <arequipeno@gmail.com>]

On 9/21/22 06:05, Pavel Machek wrote:
>> +What:		/sys/class/leds/<led>/check_interval
>> +Date:		September 2022
>> +Contact:	Ian Pilcher <arequipeno@gmail.com>
>> +Description:
>> +		Frequency (in milliseconds) with which block devices linked to
>> +		this LED will be checked for activity and the LED will
>> +		(potentially) be blinked.
> 
> Frequency -> interval.

Will do.

>> +What:		/sys/class/leds/<led>/link_dev_by_path
>> +Date:		September 2022
>> +Contact:	Ian Pilcher <arequipeno@gmail.com>
>> +Description:
>> +		Associate a block device with this LED by writing the path to
>> +		the device special file (e.g. /dev/sda) to this attribute.
>> +		Symbolic links are followed.
> 
> Following symbolic links to paths written to file is "interesting".

This is the behavior of blkdev_get_by_path(), and I haven't been able to
find any other way to "resolve" a block device (struct block_device *)
from a name (and I have asked for suggestions multiple times).

>> +What:		/sys/class/leds/<led>/linked_devices
>> +Date:		September 2022
>> +Contact:	Ian Pilcher <arequipeno@gmail.com>
>> +Description:
>> +		Directory containing links to all block devices that are
>> +		associated with this LED.  (Note that the names of the
>> +		symbolic links in this directory are *kernel* names, which
>> +		may not match the device special file paths written to
>> +		link_device and unlink_device.)
> 
> As is mismatch between kernel names here and what names the other file
> expects.
> 
> Can we get something more reasonable?

The real problem is that there is no way to use a kernel name in the
first place.  I did think about using the last element of the path that
was used to create the link, but it doesn't really solve the problem
(because you still need to pass the whole path when you unlink the
device) and it introduces the possibility of duplicate names.

The cover letter for these patches say this:

> (I hope that if this module is accepted, it might provide a case for
> adding a "by name" API to the block subsystem.  link_dev_by_name and
> unlink_dev_by_name could then be added to this trigger.)

The one thing that I can think of is to go ahead and add an 
unlink_dev_by_name attribute, so the kernel names in an LED's
linked_devices directory could be use to unlink them.  (Once a device
is "linked", I can access its name.)

So there would be both _by_path and _by_name variants for unlinking
block devices from LEDs, but linking would would still require using a
path.

How does that sound?

-- 
========================================================================
Google                                      Where SkyNet meets Idiocracy
========================================================================