lists.openwall.net   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  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Sun, 24 Nov 2019 18:02:07 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Bjorn Helgaas <helgaas@...nel.org>
Cc:     Rajat Jain <rajatja@...gle.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Frederick Lawler <fred@...dlawl.com>,
        linux-pci <linux-pci@...r.kernel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Keith Busch <keith.busch@...el.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v7 4/5] PCI/ASPM: Add sysfs attributes for controlling
 ASPM link states

On Thu, Nov 21, 2019 at 05:04:11PM -0600, Bjorn Helgaas wrote:
> What sort of tools would this break?  There are no AER tools since the
> AER stats sysfs files don't exist yet, so I assume there are some
> generic sysfs tools or libraries.

Any normal tool that looks at sysfs attributes, like udev and friends.
They will "miss" the uevent for the subdirs and not know how to
associate anything with the "parent" struct device.

> Incidentally,
> https://www.kernel.org/doc/html/latest/admin-guide/sysfs-rules.html
> suggests that maybe we should be documenting these files with
> /sys/devices paths instead of the symlinks in /sys/bus/pci/devices/,
> e.g.,
> 
>   diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
>   -What:		/sys/bus/pci/devices/.../msi_bus
>   -What:		/sys/bus/pci/devices/.../msi_irqs/
>   -What:		/sys/bus/pci/devices/.../msi_irqs/<N>
>   +What:		/sys/devices/pci*/.../msi_bus
>   +What:		/sys/devices/pci*/.../msi_irqs/
>   +What:		/sys/devices/pci*/.../msi_irqs/<N>

Either is fine, but yes, the second one is nicer.

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ