On Mon, Nov 19, 2018 at 08:30:34AM -0500, Dennis Dalessandro wrote: > On 11/19/2018 12:10 AM, Leon Romanovsky wrote: > > On Sun, Nov 18, 2018 at 10:56:15PM -0500, Dennis Dalessandro wrote: > > > On 11/18/2018 9:29 AM, Leon Romanovsky wrote: > > > > Hi, > > > > > > > > I want to clarify why IB device rename functionality didn't change > > > > debugfs and would like to ask what to do next. > > > > > > > > In drivers/infiniband/hw/*, we have 6 devices which are calling > > > > to debugfs_create_dir() in order to create debugfs root. > > > > > > > > The output is located in /sys/kernel/debug/. > > > > > > > > Such folders are created during driver module load and some of the drivers > > > > creates subfolders for every device initialized, during device probe. > > > > > > > > 1. PCI-based connection > > > > MLX5 and cxgb4 drivers separate the different device by their PCIs. > > > > [leonro@server ~]$ sudo ls /sys/kernel/debug/mlx5/ > > > > 0000:00:0c.0 > > > > > > > > 2. Based on IB device name > > > > HFI1, ocrdma and qib create subfolders with device index embedded in it, > > > > like hfi1_0,...,hfi1_N > > > > > > > > 3. No-separation between devices > > > > USNIC like this. > > > > > > > > So device rename works seamlessly for type #1 and #3. Wile for type #2, > > > > the debugfs entries don't change. > > > > > > > > Right now, I see three options: > > > > 1. Do nothing. > > > > 2. Convert type #2 drivers to be type #1. > > > > 3. Add callback/extra implementation in IB/core to support one live > > > > driver (hfi1) and two frozen ones. > > > > > > It's certainly not accurate to call qib frozen. We may not plan on any > > > new features but we do intend to keep it live and provide fixes should > > > the need arise. > > > > It is semantic, the idea is the same: no new feature are planned for it. > > There is a very big difference. qib is still in a keep it working state > as opposed to ipath when we deprecated it's use which was in a keep it > compiling state. > > > > > > > I think the type #2 is much more user friendly than putting in the PCI-ID > > > so why not convert type #1 to be type #2? > > > > As Parav explained, type #1 is coming from netdev side and from my > > small research, debugfs entries based on PCI are standard in netdev, > > including Intel drivers (i40e). > > See my reply to Parav. > > > So no, we can't rename whole netdev just for three IB drivers. > > It doesn't matter how many of what driver does what. I'm concerned with > what is the correct approach. > > > > 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. > > 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. I don't know how you came to conclusion that I want to break, but first option was "do nothing". Thanks > > -Denny > > > >
Attachment:
signature.asc
Description: PGP signature
