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: <20220701091559.0d6e1081@kernel.org>
Date:   Fri, 1 Jul 2022 09:15:59 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     David Lamparter <equinox@...c24.net>
Cc:     Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org,
        corbet@....net, linux-doc@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH net-next] eth: remove neterion/vxge

On Fri, 1 Jul 2022 15:17:32 +0200 David Lamparter wrote:
> > 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 :/  

Nah, bugs will be discovered. Look at mlx4 or ixgbe, those are
similarly old yet we still occasionally get a fix for a 10 year old
bug. The only bug report I could find for vxge is RH bugzilla filed
likely by RH QA themselves, 11 years ago.

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

I don't know of any one that works, that's the problem. I think
previous discussions were about more serious stuff like uAPI.

I don't really care about vxge in particular, I was already looking for
something to delete and the bad patch I mention in the commit msg came
up. What I'm mostly interested in is getting some experience to inform
a deletion policy. We can't come up with one by just talking. I'm
hoping to make this a topic for the maintainer's summit as well.

We are pretty open to taking in new drivers, (necessarily) even without
users, I think the flip side of that coin has to be that we delete unused
stuff. We're not a code storage service.

Here are some facts:
 - driver is not actively maintained (Jon did not nack the bad patch)
 - driver has no known users (it's unlikely they exist)
 - driver is not of great quality (constant stream of bot fixes)
 - driver is of significant complexity and needs to be adjusted each
   time we change core APIs

It's been over a decade of no development, let's delete this code.

If someone complains we can quickly revert the deletion in stable
(CCing Greg to keep me honest, I haven't actually talked to him).
I'm obviously responsible for the deletion so I'll prepare the revert.