From: Jakub Kicinski <kuba@kernel.org>
To: Til Kaiser <mail@tk154.de>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v2] net: sysfs: also pass network device driver to uevent
Date: Mon, 18 Nov 2024 17:55:43 -0800 [thread overview]
Message-ID: <20241118175543.1fbcab44@kernel.org> (raw)
In-Reply-To: <20241116163206.7585-2-mail@tk154.de>
On Sat, 16 Nov 2024 17:30:30 +0100 Til Kaiser wrote:
> Currently, for uevent, the interface name and
> index are passed via shell variables.
>
> This commit also passes the network device
> driver as a shell variable to uevent.
>
> One way to retrieve a network interface's driver
> name is to resolve its sysfs device/driver symlink
> and then substitute leading directory components.
>
> You could implement this yourself (e.g., like udev from
> systemd does) or with Linux tools by using a combination
> of readlink and shell substitution or basename.
>
> The advantages of passing the driver directly through uevent are:
> - Linux distributions don't need to implement additional code
> to retrieve the driver when, e.g., interface events happen.
> - There is no need to create additional process forks in shell
> scripts for readlink or basename.
> - If a user wants to check his network interface's driver on the
> command line, he can directly read it from the sysfs uevent file.
Thanks for the info, since you're working on an open source project
- I assume your exact use case is not secret, could you spell it
out directly? What device naming are you trying to achieve based on
what device drivers? In my naive view we have 200+ Ethernet drivers
so listing Ethernet is not scalable. I'm curious what you're matching,
how many drivers you need to list, and whether we could instead add a
more general attribute...
Those questions aside, I'd like to get an ack from core driver experts
like GregKH on this. IDK what (if any) rules there are on uevents.
The merge window has started so we are very unlikely to hear from them
now, all maintainers will be very busy. Please repost v3 in >=two weeks
and CC Greg (and whoever else is reviewing driver core and/or uevent
changes according to git logs).
--
pw-bot: defer
next prev parent reply other threads:[~2024-11-19 1:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-15 18:33 [PATCH net-next] net: uevent: also pass network device driver Til Kaiser
2024-11-15 22:06 ` Jakub Kicinski
2024-11-16 16:30 ` Til Kaiser
2024-11-16 16:30 ` [PATCH net-next v2] net: sysfs: also pass network device driver to uevent Til Kaiser
2024-11-19 1:55 ` Jakub Kicinski [this message]
2024-12-05 16:28 ` Til Kaiser
2024-12-06 7:13 ` Greg KH
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=20241118175543.1fbcab44@kernel.org \
--to=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mail@tk154.de \
--cc=netdev@vger.kernel.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 NNTP newsgroup(s).