From: "Bjørn Mork" <bjorn@mork.no>
To: Ian Pilcher <arequipeno@gmail.com>
Cc: kernelnewbies@kernelnewbies.org
Subject: Re: Seeking help addressing maintainer objections
Date: Wed, 03 Apr 2024 16:05:25 +0200 [thread overview]
Message-ID: <8734s2v8wq.fsf@miraculix.mork.no> (raw)
In-Reply-To: <c2ce2e5d-144d-4a7a-9db7-0b67afd8878a@gmail.com> (Ian Pilcher's message of "Wed, 3 Apr 2024 08:00:28 -0500")
Ian Pilcher <arequipeno@gmail.com> 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
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
prev parent reply other threads:[~2024-04-03 14:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-02 15:59 Seeking help addressing maintainer objections Ian Pilcher
2024-04-03 11:38 ` Bjørn Mork
2024-04-03 13:00 ` Ian Pilcher
2024-04-03 14:05 ` Bjørn Mork [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8734s2v8wq.fsf@miraculix.mork.no \
--to=bjorn@mork.no \
--cc=arequipeno@gmail.com \
--cc=kernelnewbies@kernelnewbies.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).