On 12/10/20 9:06 PM, Joel Wirāmu Pauling wrote: > > > On Fri, Dec 11, 2020 at 8:51 AM Geert Stappers <stapp...@stappers.nl > <mailto:stapp...@stappers.nl>> wrote: > > On Thu, Dec 10, 2020 at 05:16:28PM +0100, Marco d'Itri wrote: > > On Dec 10, Paul Wise <p...@debian.org <mailto:p...@debian.org>> wrote: > > > Both of these situations sound like things that should get solved by > > > rewriting the vendor/O-O-T code and including it in mainline > > > Linux/etc, is there any chance of that happening? Or alternatively, > > The Fibre Channel drivers ARE all upstreamed, it's just that the > inbox > > drivers (i.e. distributed with the OS, in vendors speak) are not > > qualified to receive support (and may be buggy, even in RHEL). > > Storage vendors provide a support matrix with supported releases > of the > > storage firmware, FC switches firmware, network adapter firmware, > OS and > > OS driver. Anything else may not receive support. > > > > > for significant future hardware acquisitions, require mainline > support > > > before purchase. > > Obviously, but I am not aware of any such FC/FCoE hardware (not > just the > > network adapters, but also the storages). > > Acknowledge on that problem. > Do know that it can and must be solved by wallet. > So do talk with your purchase department. > > > Being out of Kernel means it is out of support or an approved support > exception, one of the benefits of paid RHEL is hardware vendors both > reach out to us, and we reach out to them to ensure certification and > capability. Generally prior to something going to market. > > I hear your pain tho, I have a heap of Dell servers with deprecated HBA > controllers in RH8 that I need to schlep in elrepo modules for drives to > show up. That decision however was made because no-one in mainline is > able to solve vendor issues and the vendor has disappeared (related to a > PowerPC chip design flaws in a heap of Sandybridge era Raid > controllers). We went down the big red warnings route in RH7 and people > ignored them and had data lost and then blamed RH. Which is untenable ; > a lot of hardware specific support falls into this category; and 100% > this is something careful selection solves and is part of your Risk > assessment as an Org. It also puts a LTS CentOS at odds of being able to > track our source trees, one of the problems this is attempting to > ameloirate. > > So in all those situations given here, yes, CentOS drivers that exist > only in CentOS land really put the entire premise of a Stable Long Lived > and robust OS at odds with the reality yes, absolutely. > > The ability to compile modules against the RHEL sources is not going > away. So you can still run your junk with RHEL (out of support). The > streams kernel also likely will solve this issue.
Gosh... reading that, I'm really happy I'm not (and never was) a CentOS user. Seriously, this looks terrible! Cheers, Thomas Goirand (zigo)
