linux-kernel - Re: [PATCH net-next v2] net: sysfs: also pass network device driver to uevent

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2024120613-unicycle-abruptly-02d1@gregkh>
Date: Fri, 6 Dec 2024 08:13:30 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Til Kaiser <mail@...54.de>
Cc: Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, idosch@...dia.com, petrm@...dia.com
Subject: Re: [PATCH net-next v2] net: sysfs: also pass network device driver
 to uevent

On Thu, Dec 05, 2024 at 05:28:47PM +0100, Til Kaiser wrote:
> On 19.11.24 02:55, Jakub Kicinski wrote:
> > 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.

Why does the driver name matter for something like a network device?
I.e. why are network devices "special" here and unlike all other class
devices in the kernel like keyboards, mice, serial ports, etc.?

> > >   - There is no need to create additional process forks in shell
> > >     scripts for readlink or basename.

"Do it in the kernel and have someone else maintain it for me to make my
life easier in userspace" isn't always the best reason to do something.
Generally if "you can do this in userspace" means "you SHOULD do this in
userspace", it's not a good reason to add it to the kernel.

And note, driver names change!  How are you going to handle that?

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

The symlink in sysfs shows this already, no need to
open/read/parse/close the uevent file.

Also, where did you now document this new user/kernel API that we have
to maintain for 40+ years?  And what userspace tool is going to use it?

But really, again, why are network devices so special that they need
this but no other type of device in the kernel does?  And what changed
to require this suddenly?

thanks,

greg k-h