On Mon, 20 Sep 2021 07:43:52 +0100
Christoph Hellwig [off-list ref] wrote:

On Sat, Sep 18, 2021 at 09:07:54AM +0200, Greg KH wrote:

quoted

quoted

Honestly, I wasn't particularly enthusiastic about it in the first
place; it feels like something that should be done in user space.
 I wouldn't have included it if I didn't have to make a writable
copy of the buffer anyway, in order to trim a trailing newline.

I can certainly remove the re-check logic.  The end result will
be an API that is slightly less "user friendly" in return for
saving a bit of pointer arithmetic and a 5-byte memcpy().  

Just use the kernel block device name and that way you do not have
to parse anything as it is unique and no paths are having to be
followed.

That's the way that other LED apis are working, right?  

The "kernel block device name" is the a block device special path
that a normal VFS path lookup is done on.  This is the preferred block
device API used by everyone.  And yes, this includes resolving
symlinks. The only other API is by dev_t, but it is highly
discouraged and should really not grow any new users.

Christoph,

/sys/class/block lists block devices' kernel object names.
I don't understand why can't blk API provide a function returns a block
device given such name as seen in /sys/class/block directory.

Can you elaborate on this?

It seems really strange to me to not be able to do
  cd /sys/class/leds/<LED>
  echo blkdev >trigger
  echo sda1 >block_device
and instead having to do (as the last command)
  echo /dev/sda1 >block_device

And whas should we show when /dev/sda1 is paried to the trigger, and
userspace reads the block_device sysfs file? Should we show the full
path which was given when pairing, even if it may not be valid anymore?
(Such as when the device file is removed from /dev.)

Marek