Re: [PATCH for-next] iw_cxgb3: remove iw_cxgb3 module from kernel.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/18/2019 04:51 PM, Doug Ledford wrote:
On Fri, 2019-10-18 at 17:46 -0300, Jason Gunthorpe wrote:
On Wed, Oct 16, 2019 at 01:47:29PM -0400, Don Dutile wrote:

Isn't there a better way to mark a driver deprecated?

This kind of removal makes long-term maintenance of such drivers
painful in downstream distros, as API changes that are rippled from
core through all the drivers, don't update these drivers, and when
backporting such API changes to downstream distros, we have to +1
removed drivers.

You still have cxg3 as an enabled & supported driver? In RH8? Why?
It's much easier if upstream continues to update the drivers for
such across-the-driver-patch-changes.  heck, add a separate patch
that punches out a printk stating DEPRECATED (dropping a patch to
backport is easy! :) ).

The whole point of doing this is to avoid this work!

People don't quit *using* hardware just because a company has quit
selling it.  When we can quit supporting it is more about whether
customers ask for support (or our records indicate lots of systems use
the hardware) than about whether the vendors still care.

That said, we probably could have dropped cxgb3 from 8.0, but I'm not
positive about that.  Just a guess.


cxgb3 is dropped from rhel-8;
yeah, we pruned the tree very closely on RHEL8, and many on this list know that all too well --
b/c ... oh yeah, the vendors EOL'd their devices ... but they are in labs' (well-established) OEM servers everywhere, and now they can't run RHEL8. :(

cxgb3 still quite alive in rhel-7 --> 10yr life cycle ! 7.0 shipped June 2014... so in 2024...
RHEL7 has exited Phase I, where we update the RDMA base to upstream en-masse every RHEL-X.Y release,
so the concern is less now, but some bug-fixes require a refactoring that breaks un-sourced drivers.

Hey, this nut case named Doug Ledford wanted me to keep mthca enabled in RHEL8 for his private lab!
hahahahahaha ....

On the flip-side, I wish we could EOL & remove a whole lot of other code in the kernel (/me looking at old x86 compat code as a prime example...).  other old hw on arch's ... would make a lot of mm cleanup possible without the long, protracted effort that Mike Rappaport goes through!

ok, I made my point.  Do as you wish.






[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux