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  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:	Tue, 30 Dec 2014 10:20:21 +0100
From:	Andreas Mohr <>
To:	Ethan Zhao <>
	Ethan Zhao <>,
	Greg Kroah-Hartman <>
Subject: Re: [PATCH] PCI: export pci device assignment info as read only via


Ethan Zhao wrote:
> This patch exports assignment flag of PCI device via sysfs, so user
> space application could know if PCI device was assigned to guest OS
> or not via interface as following from viewpoint of host device
> management:
>  PCI device was assigned to guest OS
>  $cat /sys/devices/pci0000:00/0000:00:1f.3/assigned
>  1
>  PCI device isn't assigned to guest OS
>  $cat /sys/devices/pci0000:00/0000:00:1f.3/assigned
>  0

For such a sysfs API (and similar cases in general!),
do we actually want this relatively simple interface of
"assigned" false/true?
Or should it rather be something like an "ownership" attribute
which could then indicate interface-fixed(!) string values
such as "system"/"vm_guest"/FUTURE_EXTENSION_POSSIBILITY?

IOW, "assigned" is quite a bit less flexible (and quite possibly even less
usability-suitable from a naming POV - "assigned"...??)
but of course simpler (which may or may not pose an advantage from an
interface versioning/evolution POV).

To further clarify things, this "assigned" interface as-is
can merely tell apart
the "device is occupied" vs. "device is not occupied" cases
yet it could easily provide exact ownership details instead.
And I'm also wondering whether or not it's good
to have it directly/symmetrically named "assigned"
due to it currently(!!) being based internally
on an equally-named pci_is_dev_assigned() API.

I should probably read up on sysfs item design hints/guidelines
which I'd trust to be accurately explained in a Documentation/ file ;)
Hmm, seems Documentation/sysfs-rules.txt has only one closing remark
which seems relevant:
  Userspace applications can, however, expect the format and contents of
  the attribute files to remain consistent in the absence of a version
  attribute change in the context of a given attribute.
This would be fulfilled by both the current and my suggested variant
of this interface, AFAICS.


Andreas Mohr
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists