On Wed, Feb 19, 2020 at 04:35:40PM +0200, Gal Pressman wrote: > On 19/02/2020 16:14, Dennis Dalessandro wrote: > > On 2/19/2020 2:11 AM, Leon Romanovsky wrote: > >> On Tue, Feb 18, 2020 at 12:11:47PM -0500, Dennis Dalessandro wrote: > >>> On 2/18/2020 9:04 AM, Leon Romanovsky wrote: > >>>> On Fri, Feb 14, 2020 at 01:13:53PM -0500, Dennis Dalessandro wrote: > >> ABI breakage is a strong word, luckily enough it is not defined at all. > >> We never considered dmesg prints, device names, device ordering as an > >> ABI. You can't rely on debug features too, they can disappear too. > > > > Agree, it is a strong word and we can call it what you want. The point is you > > should be able to rely on the node description not being changed out from under > > you unnecessarily though. We aren't talking about a debug feature here but a > > core feature to real world deployments. > > > > Could you envision a patch to a user space library that just changes a devices > > hostname to something that was HW specific because it makes scripting easier? I > > contend that in some cases the node description remaining constant is just as > > important. > > > >> So the bottom line, the expectation that distro should fix all broken > >> software before enabling device renaming and their bugs are not excuse > >> to declare ABI breakage. > > > > Again, call it what you want, but you can't deny this change to force the rename > > by default has not broken things. For the record I'm not even talking about PSM2 > > here. There are other, more far reaching implications. > > It's not just PSM2, it broke our libfabric provider and apparently MVAPICH as well: > http://mailman.cse.ohio-state.edu/pipermail/mvapich-discuss/2020-January/006960.html > > Regarding the issue you described, why not disable the rename on the upgrade > path and only enable it for fresh installations? Good suggestion, at least in theory, it can be done for the RPMs. Just need to be careful to distinguish upgrades from pre-v24 versions and post-v24 versions. Thanks
