Re: Rename of debugfs entries

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

 



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.

>
> 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).

So no, we can't rename whole netdev just for three IB drivers.

>
> 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.

Thanks

> -Denny
>

Attachment: signature.asc
Description: PGP signature


[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