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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20071113201102.GK17785@parisc-linux.org>
Date:	Tue, 13 Nov 2007 13:11:02 -0700
From:	Matthew Wilcox <matthew@....cx>
To:	Greg KH <greg@...ah.com>
Cc:	Alex Chiang <achiang@...com>, gregkh@...e.de,
	kristen.c.accardi@...el.com, lenb@...nel.org,
	richard.jones2@...com, 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 10:51:22AM -0800, Greg KH wrote:
> Ok, again, I want to see the IBM people sign off on this, after testing
> on all of their machines, before I'll consider this, as I know the IBM
> acpi tables are "odd".

That seems a little higher standard than patches are normally held to.
How about the patches get sent to the appropriate people at IBM (who are
they?) and if we haven't heard a NAK from them after a month, then they
get applied?

> Also, how about Dell machines?  I know they are probably not expecting
> this information to show up and who knows if the numbering of their
> slots match up with their physical diagrams (I say this based on all of
> the eth0/eth1 "issues" with Dell machines over the years...)

I'm pretty sure that Windows uses the _SUN information, so I think this
is going to be well-tested.

> IBM sells a program that does this for server rooms.  It's probably part
> of some Tivoli package somewhere, sorry I don't remember the name.  I
> did see it working many years ago and it required no kernel changes at
> all to work properly.

Well, yes, it doesn't take kernel effort if you're willing to build
proprietary knowledge into a userspace program.  This seems similar
to the argument that filesystems don't need to be in the kernel since
they can be implemented in user space.  They work better in the kernel,
just like this does.

By the way, the end result of this should be a pci-hotplug system that has
much less code in the drivers, more uniformity between the presentation
to userspace, more functionality and is easier to understand.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
-
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/