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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZumwjxMVpoJ+cqvH@shell.armlinux.org.uk>
Date: Tue, 17 Sep 2024 17:38:39 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Maxime Chevallier <maxime.chevallier@...tlin.com>
Cc: Andrew Lunn <andrew@...n.ch>, Daniel Golle <daniel@...rotopia.org>,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	Heiner Kallweit <hkallweit1@...il.com>,
	Kory Maincent <kory.maincent@...tlin.com>,
	Edward Cree <ecree.xilinx@...il.com>,
	Paolo Abeni <pabeni@...hat.com>, Jakub Kicinski <kuba@...nel.org>,
	Eric Dumazet <edumazet@...gle.com>,
	"David S. Miller" <davem@...emloft.net>,
	John Crispin <john@...ozen.org>
Subject: Re: ethtool settings and SFP modules with PHYs

On Tue, Sep 17, 2024 at 05:53:47PM +0200, Maxime Chevallier wrote:
> For the SFP case, the notification would trigger indeed at the
> module_start/module_remove step.

This (the confusion of module_remove being the opposite of
module_start)...

> 
> All of that is still WIP, but I think it would reply to that exact need
> of "notifying users when something happens to the ports", including SFP
> module insertion.

and talking here about module insertion here, leads me to believe that
you haven't grasped the problem with SFPs, where we don't know what
the module supports at _insertion_ time.

If we're after giving userspace a notification so it can make decisions
about what to do after examining capabilities, then insertion time is
too early.

If we're after giving userspace a notification e.g. that a SFP was
inserted, so please bring up the network interface, then that may be
useful, but userspace needs to understand that SFPs are special and
they can't go configuring the link at this point if it's a SFP.

Honestly, I do not want to expose to userspace this kind of complexity
that's specific to SFPs. It _will_ get it wrong. I also think that it
will tie our hands when working around module problems if we have to
change the way module capabilities are handled - and I don't wish to
be tied by "but that change you made to make module XYZ work breaks
my userspace!" because someone's using these events to do some weirdo
configuration.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ