linux-kernel - Re: [PATCH 0/5][RFC] Physical PCI slot objects

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071113225605.GA2589@suse.de>
Date:	Tue, 13 Nov 2007 14:56:05 -0800
From:	Greg KH <gregkh@...e.de>
To:	Rick Jones <rick.jones2@...com>
Cc:	Greg KH <greg@...ah.com>, Alex Chiang <achiang@...com>,
	kristen.c.accardi@...el.com, lenb@...nel.org, matthew@....cx,
	linux-kernel@...r.kernel.org, linux-pci@...ey.karlin.mff.cuni.cz,
	pcihpd-discuss@...ts.sourceforge.net, linux-acpi@...r.kernel.org
Subject: Re: [PATCH 0/5][RFC] Physical PCI slot objects

On Tue, Nov 13, 2007 at 02:51:13PM -0800, Rick Jones wrote:
> Greg KH wrote:
>> Doesn't /sys/firmware/acpi give you raw access to the correct tables
>> already?
>> And isn't there some other tool that dumps the raw ACPI tables?  I
>> thought the acpi developers used it all the time when debugging things
>> with users.
>
> I'm neither an acpi developer (well I don't think that I am :) nor an
> end-user, but here are the two things for which I was going to use the
> information being presented by Alex's patch:
>
> 1) a not-yet, but on track to be released tool to be used by end-users
> to diagnose I/O bottlenecks - the information in
> /sys/bus/pci/slot/<foo>/address would be used to associated interfaces
> and/or pci busses etc with something the end user would grok - the
> number next to the slot.
>
> 2) I was also going to get the folks doing installers to make use of the
> "end-user" slot ID. Even without going to the extreme of the
> aforementioned 192 slot system, an 8 slot system with a bunch of
> dual-port NICs in it (for example) is going to present this huge list of
> otherwise identical entries. Even if the installers show the MAC for a
> NIC (or I guess a WWN for an HBA or whatnot) that still doesn't tell one
> without prior knowledge of what MACs were installed in which slot, which
> slot is associated with a given ethN. Having the end-user slot ID
> visible is then going to be a great help to that poor admin who is doing
> the install.

Why not just use the code in the linux firmware kit that does this
already today from userspace (thanks to Kristen for pointing this out to
me on irc.)?

No kernel changes needed, and you can get started on your userspace
application today, will work on all distros, no problems at all :)

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/