On Tue, 2018-12-18 at 13:30 +0000, Ruhl, Michael J wrote:
> 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.
You are correct. This satisfies the needs for device rename and can be
left just as it is.
The original problem stemmed from drivers using their ib device name
(such as mlx4_0), which presents a problem on rename in that when the
first mlx4 device is registered it would be mlx4_0, then udev renames
the device to <whatever> but the debugfs files are still in a directory
named mlx4_0, and then you register another mlx4 device, and because
there is no mlx4_0 any more, the new device gets the name mlx4_0 again,
and now the creation of the debugfs files for the second mlx4 device
fail because the name mlx4_0 is already in use. Your naming scheme
avoids that problem, and so it is fine just as it is and there is no
need to break any existing user space or switch to PCI address naming
schemes.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
Attachment:
signature.asc
Description: This is a digitally signed message part
