netdev - Re: [PATCH net-next] eth: remove neterion/vxge

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <Yr7z7HU2Z79pMrM0@eidolon.nox.tf>
Date:   Fri, 1 Jul 2022 15:17:32 +0200
From:   David Lamparter <equinox@...c24.net>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        corbet@....net, linux-doc@...r.kernel.org
Subject: Re: [PATCH net-next] eth: remove neterion/vxge

[culled Cc:]

On Fri, Jul 01, 2022 at 12:34:13PM +0200, Jiri Pirko wrote:
> Fri, Jul 01, 2022 at 06:42:34AM CEST, kuba@...nel.org wrote:
> >The last meaningful change to this driver was made by Jon in 2011.
> >As much as we'd like to believe that this is because the code is
> >perfect the chances are nobody is using this hardware.
> 
> Hmm, I can understand what for driver for HW that is no longer
> developed, the driver changes might be very minimal. The fact that the
> code does not change for years does not mean that there are users of
> this NIC which this patch would break :/

As a "reference datapoint", I'm a user that was affected by the removal
of the Mellanox SwitchX-2 driver about a year ago.  But that was a bit
different since the driver was apparently rather incomplete (I don't
know the details, was still messing around to even get things going.)

(FWIW my use case is in giving old hardware a second life, in this case
completely throwing away the PowerPC control board from Mellanox SX6000
series switches and replacing it with a new custom CPU board...  I might
well be the only person interested in that driver.

> Isn't there some obsoletion scheme globally applied to kernel device
> support? I would expect something like that.

I have the same question - didn't see any such policy but didn't look
particularly hard.  But would like to avoid putting time into making
something work just to have the kernel driver yanked shortly after :)

-David