Re: [PATCH rdma-next] RDMA/hfi1: Use PCI-ID as an identification in debugfs

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

 



On Tue, Dec 18, 2018 at 01:30:41PM +0000, Ruhl, Michael J wrote:
> >-----Original Message-----
> >From: Jason Gunthorpe [mailto:jgg@xxxxxxxxxxxx]
> >Sent: Monday, December 17, 2018 3:39 PM
> >To: Ruhl, Michael J <michael.j.ruhl@xxxxxxxxx>
> >Cc: Dalessandro, Dennis <dennis.dalessandro@xxxxxxxxx>; Leon Romanovsky
> ><leon@xxxxxxxxxx>; Yuval Shaia <yuval.shaia@xxxxxxxxxx>; Doug Ledford
> ><dledford@xxxxxxxxxx>; Marciniszyn, Mike <mike.marciniszyn@xxxxxxxxx>;
> >RDMA mailing list <linux-rdma@xxxxxxxxxxxxxxx>
> >Subject: Re: [PATCH rdma-next] RDMA/hfi1: Use PCI-ID as an identification in
> >debugfs
> >> >
> >> >On Wed, Dec 12, 2018 at 03:05:59PM -0500, Dennis Dalessandro wrote:
> >> >
> >> >> > Because it is not related to verbs at all, but general core
> >> >> > infrastructure change needed for all devices in RDMA subsystem,
> >> >> > which are using struct ib_device to hold data.
> >> >>
> >> >> Core, verbs, whatever. Point is that debugfs is still something different
> >> >> and doesn't have to be subject to the same naming scheme.
> >> >
> >> >You can use whatever names you like in debugfs, so long as they are
> >> >guaranteed to be globally unique.
> >>
> >> I am not really sure what this means.
> >
> >It means the names of debugfs files hvae to be derived so they are
> >globally unique. A driver can't create a debugfs file name used by
> >another driver.
>
> Hmm,  taking a little close look at the debugfs.c module for HFI I am wondering if
> there is some confusion WRT how the HFI driver uses debugfs.
>
> The init function (hfi1_dbg_ibdev_init() occurs after hfi1_ib_register(), with a
> comment of "create debugfs files after init and ib register".  This uses the
> hfi1_ibdev data structure as the "private data" for the debugfs information.
>
> However, the root debufs system is based off of "DRIVER_NAME"  (hfi1), and
> the actual filenames within that directory is based off of hfi1_class_name (hfi1)
> and the "port" value.
>
> So we get:
>
> /sys/kernel/debug/hfi/hfi1_<port>
>
> For each HFI we will increment port, so for two instance of the driver, there will
> always be a uniquely defined name.
>
> From that perspective, as far as I can tell, the HFI driver is meeting the
> "globally uniqueness" requirement.
>
> We do register with the IB driver using the hfi1_class_name/port, but that is a
> stored separately, and is completely unrelated to our debugfs usage.
>
> If the IB name is renamed, there is no effect on the HFI debugfs files.
>
> The data structure and function name are perhaps poorly named, but as far
> as I can tell are unique, and not in conflict with anything from the IB space.

ok, as you wish, let's disable device rename for hfi1. We can't allow
ambiguity for the users.

>
> Mike
>
> >> How do I guarantee global uniqueness?
> >
> >Use the PCI ID is what other drivers do.
> >
> >> >Since rename, using the IB device name is no longer globally unique so
> >> >it cannot be used as the name in debugfs. You have to fix this..
> >>
> >> Why and how does the name of the IB device name have any impact on a
> >> filename I have defined in debugfs?
> >
> >hfi1 is passing the IB device name in as the directory name for
> >debugfs. IB devices names are not globally unique, so they cannot be
> >used in this way.
> >
> >> If create new driver for card x and create a debugfs file my_file,
> >> and then someone renames an IB device to my_file, did I do something
> >> wrong?
> >
> >It has nothing to do with IB. You did something wrong by having the
> >driver using a non-unique name 'my_file'. Two instances of this driver
> >will create 'my_file' and one will fail.
> >
> >Jason

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