On Mon, Nov 19, 2018 at 08:30:34AM -0500, Dennis Dalessandro wrote: > > > Now that being said I would imagine we could go with either approach and > > > leave it up to the administrator to create a udev rule or something and > > > make symlinks to keep existing tools compatible. So I don't think we need > > > to support both. The question is which is better #1 or #2? > > > > > > > Administrators don't care about debugfs entries and more on that any > > sane administrator will disable debugfs on production system. It is > > unlikely that such udevs are needed for them. > > Point is, without a good reason we can't break what already works. Saying > administrators that rely on debugfs are not "sane" is not sufficient. debugfs will have user breaking API changes to fix kernel issues. That is the agreed to nature of debugfs. Renaming directories to stable names so that IB device rename isn't buggy is sufficient justification alone to do it. > So if there is a way to employ a work around for admins to keep existing > tools working that makes such a change a much easier pill to swallow. Upgrade end-user software that uses debugfs and complain to their vendor that administrator used software should not be using unstable debugfs as a kernel API. Jason
