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

[Jakub Kicinski <kuba@kernel.org>]

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.