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.
