From: linas@austin.ibm.com (Linas Vepstas)
To: Greg KH <greg@kroah.com>
Cc: Alex Chiang <achiang@hp.com>,
gregkh@suse.de, kristen.c.accardi@intel.com, lenb@kernel.org,
matthew@wil.cx, richard.jones2@hp.com,
linux-kernel@vger.kernel.org, linux-pci@atrey.karlin.mff.cuni.cz,
pcihpd-discuss@lists.sourceforge.net, linux-acpi@vger.kernel.org
Subject: Re: [PATCH 0/5][RFC] Physical PCI slot objects
Date: Tue, 13 Nov 2007 14:24:24 -0600 [thread overview]
Message-ID: <20071113202424.GE8421@austin.ibm.com> (raw)
In-Reply-To: <20071113170129.GA20185@kroah.com>
On Tue, Nov 13, 2007 at 09:01:29AM -0800, Greg KH wrote:
>
> Also, some companies already provide userspace tools to get all of this
> information about the different slots in a system and what is where,
> from userspace, no kernel changes are needed. So, why add all this
> extra complexity to the kernel if it is not needed?
Second that motion.... I don't get it. What are the goals of this
patch, really? Just to get a "slot geographical location" from the
kernel? I'm balancing the intellectual appeal of having a kernel
struct for representing physical objects, against the headache of
reading (debugging, modifying) code that has yet another struct
doing yet another thing. So far, the dread of future headaches
is winning.
On pseries systems, I deal with something called the "partitionable
endpoint", which I think probably usually corresponds to physical
slots, but I don't really know. The hardware guys pitch changeups
all the time. Some of these are soldered onto the planar,
so the are not physical slots. But they are, um, "hotpluggable"
in that you can dynamically add & remove them from the system
(even though you cannot physically unplug the ones that are
soldered on -- you can only assign them to other hardware partitions
(think hardware VM or hardware Xen)). So, naively, the physical
slot concept doesn't really map to what I have to work with;
it just adds one more appendix to it all, one more thing to
get confused about.
To be clear: above remarks are for the PowerPC boxes. I have
no clue about how things work on the IBM Intel-based boxes.
And Greg's original "get IBM to agree" remark is about the
Intel-based boxes.
--linas
next prev parent reply other threads:[~2007-11-13 20:24 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-13 0:08 [PATCH 0/5][RFC] Physical PCI slot objects Alex Chiang
2007-11-13 0:12 ` [PATCH 1/5] Remove path attribute from sgi_hotplug Alex Chiang
2007-11-13 0:13 ` [PATCH 2/5] Construct one fakephp slot per pci slot Alex Chiang
2007-11-13 19:48 ` Linas Vepstas
2007-11-13 19:52 ` Matthew Wilcox
2007-11-14 12:39 ` [Pcihpd-discuss] " Rolf Eike Beer
2007-11-14 14:17 ` Alex Chiang
2007-11-14 14:49 ` Rolf Eike Beer
2007-11-14 15:01 ` Alex Chiang
2007-11-13 0:14 ` [PATCH 3/5, RFC] Introduce pci_slot Alex Chiang
2007-11-13 19:56 ` Linas Vepstas
2007-11-13 20:03 ` Matthew Wilcox
2007-11-13 0:17 ` [PATCH 4/5, RFC] ACPI PCI slot detection driver Alex Chiang
2007-11-13 0:18 ` [PATCH 5/5] Add pci_slot_add_hotplug() interface Alex Chiang
2007-11-13 17:01 ` [PATCH 0/5][RFC] Physical PCI slot objects Greg KH
2007-11-13 18:33 ` Matthew Wilcox
2007-11-13 18:51 ` Greg KH
2007-11-13 20:11 ` Matthew Wilcox
2007-11-13 20:19 ` Greg KH
2007-11-13 23:08 ` Gary Hade
2007-11-14 1:37 ` Alex Chiang
2007-11-15 0:40 ` Gary Hade
2007-11-15 17:36 ` Alex Chiang
2007-11-15 23:38 ` Gary Hade
2007-11-14 14:42 ` Alex Chiang
2007-11-14 18:13 ` Gary Hade
2007-11-14 18:36 ` Alex Chiang
2007-11-13 20:36 ` Alex Chiang
2007-11-13 21:30 ` Greg KH
2007-11-13 22:01 ` Bjorn Helgaas
2007-11-13 22:16 ` Greg KH
2007-11-13 21:15 ` Matt Domsch
2007-11-13 21:31 ` Alex Chiang
2007-11-13 21:36 ` Greg KH
2007-11-13 23:14 ` Alex Chiang
2007-11-13 21:32 ` Greg KH
2007-11-13 20:21 ` Alex Chiang
2007-11-13 20:26 ` Greg KH
2007-11-13 22:51 ` Rick Jones
2007-11-13 22:56 ` Greg KH
2007-11-13 23:04 ` Matthew Wilcox
2007-11-13 23:07 ` Greg KH
2007-11-14 6:00 ` Scott Murray
2007-11-13 23:33 ` Kristen Carlson Accardi
2007-11-14 0:10 ` Matthew Wilcox
2007-11-14 9:55 ` Kenji Kaneshige
2007-11-14 18:38 ` Kristen Carlson Accardi
2007-11-13 22:59 ` Kristen Carlson Accardi
2007-11-14 17:37 ` Bjorn Helgaas
2007-11-14 17:53 ` Greg KH
2007-11-14 19:53 ` Alex Chiang
2007-11-14 21:24 ` Alex Chiang
2007-11-14 21:42 ` Alex Chiang
2007-11-14 22:00 ` Greg KH
2007-11-15 20:20 ` Alex Chiang
2007-11-14 17:44 ` Matthew Garrett
2007-11-14 17:51 ` Greg KH
2007-11-14 18:03 ` Matthew Garrett
2007-11-13 20:24 ` Linas Vepstas [this message]
2007-11-13 20:59 ` Alex Chiang
2007-11-13 21:41 ` Linas Vepstas
2007-11-13 21:58 ` Matthew Wilcox
2007-11-14 1:07 ` Andi Kleen
2007-11-14 14:17 ` Matthew Wilcox
2007-11-14 14:35 ` Andi Kleen
2007-11-14 15:00 ` Matthew Wilcox
2007-11-14 15:08 ` Andi Kleen
2007-11-14 15:12 ` Matthew Wilcox
2007-11-14 15:20 ` Alex Chiang
2007-11-14 11:43 ` Kenji Kaneshige
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071113202424.GE8421@austin.ibm.com \
--to=linas@austin.ibm.com \
--cc=achiang@hp.com \
--cc=greg@kroah.com \
--cc=gregkh@suse.de \
--cc=kristen.c.accardi@intel.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=matthew@wil.cx \
--cc=pcihpd-discuss@lists.sourceforge.net \
--cc=richard.jones2@hp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox