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] [thread-next>] [day] [month] [year] [list]
Message-ID: <56C6E7D1.4@suse.de>
Date:	Fri, 19 Feb 2016 11:00:49 +0100
From:	Hannes Reinecke <hare@...e.de>
To:	Jordan Hargrave <Jordan_Hargrave@...l.com>, bhelgaas@...gle.com
Cc:	alexander.duyck@...il.com, linux-pci@...r.kernel.org,
	babu.moger@...cle.com, linux-kernel@...r.kernel.org,
	jharg93@...il.com
Subject: Re: [PATCH] Create sysfs entries for PCI VPDI and VPDR tags

On 02/18/2016 09:04 PM, Jordan Hargrave wrote:
> The VPD-R is a readonly area of the PCI Vital Product Data region.
> There are some standard keywords for serial number, manufacturer,
> and vendor-specific values.  Dell Servers use a vendor-specific
> tag to store number of ports and port mapping of partitioned NICs.
> 
> info = VPD-Info string
> PN = Part Number
> SN = Serial Number
> MN = Manufacturer ID
> Vx = Vendor-specific (x=0..9 A..Z)
> 
> This creates a sysfs subdirectory in the pci device: vpdattr with
> 'info', 'EC', 'SN', 'V0', etc. files containing the tag values.
> 
> Signed-off-by: Jordan Hargrave <Jordan_Hargrave@...l.com>
Hmm. Can we first get an agreement on the PCI VPD parsing patches
I've posted earlier?
VPD parsing is really tricky, and we should aim on making the
read_vpd function robust enough before we begin putting things into
sysfs.

Also, I'm not utterly keen on this patchset.
The sysfs space is blown up with tiny pieces of information, which
can easily gotten via lspci, too.

Also, to my knowledge it's perfectly valid to _write_ to the VPD, in
which case the entire sysfs attribute setup would be invalided.
How do you propose to handle that?

Cheers,

Hannes

-- 
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare@...e.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ