lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 17 Feb 2017 09:15:06 -0800
From:   Christoph Hellwig <>
To:     Kishon Vijay Abraham I <>
Cc:     Bjorn Helgaas <>,
        Jingoo Han <>,
        Joao Pinto <>,,,,,,,
Subject: Re: [PATCH v2 04/22] Documentation: PCI: Guide to use pci endpoint

I'm commenting on the configfs layout here instead of the patch with the
code as the issues are easier to explain that way.  I think the layout
is a bit confusing and could be cleaner by making use of pre-created
entries and symlinks.  Here is my suggestion:

    .. test/					# a directory for each function driver
       ... user-specified-name1/
       ... user-specified-name2
    .. nvme/
       ... user-specified-name42/		

Each directory under /sys/kernel/config/pci_ep/functions/ is owned
by a function drivers.  Under that function driver's directory you
can create a directory for each instance of a function driver.  The
configfs layout is controlled by the function driver.  E.g. your current
EPF fields would move into the test function driver, while the nvme
function would expose totally different fields.

	... dwc-0/
	    ... function
	... dwc-1/
	    ... function
	... vhost-0/
	    ... function

	Here you have a directory for each controller that can be bound
	to a function.  The directories are pre-created for each
	controller port that is EP capable.
	Function is a symlink to the function instance above.
	Additional parameters might also be present depending on the
	EPC driver.

Powered by blists - more mailing lists