Re: Seeking help addressing maintainer objections

Bjørn Mork <[email protected]>
Newsgroups org.kernelnewbies.kernelnewbies
Organization m
Message-ID <[email protected]>
Ian Pilcher <[email protected]> writes:

> 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.

Yes, I agree that things are much easier if those names can be fed
directly into the unlink attribute.  And even better if the names in the
linked_devices directory actually matched what you used to link them.

So why not go for "major:minor" everywhere?  I.e for link, unlink and
also for the symlinks in linked_devices.

>> 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.

I believe that's how most maintainers work unless the proposal was in
patch form :-)



Bjørn

_______________________________________________
Kernelnewbies mailing list
[email protected]
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.