From: Greg KH <greg@kroah.com>
To: Matthew Wilcox <matthew@wil.cx>
Cc: Alex Chiang <achiang@hp.com>,
gregkh@suse.de, kristen.c.accardi@intel.com, lenb@kernel.org,
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 10:51:22 -0800 [thread overview]
Message-ID: <20071113185122.GA22536@kroah.com> (raw)
In-Reply-To: <20071113183353.GE17785@parisc-linux.org>
On Tue, Nov 13, 2007 at 11:33:53AM -0700, Matthew Wilcox wrote:
> On Tue, Nov 13, 2007 at 09:01:29AM -0800, Greg KH wrote:
> > I'm still not sold on this idea at all. I'm really betting that there
> > is a lot of incorrect acpi slot information floating around in machines
> > and odd things will show up in these slot entries.
>
> Is that the end of the world? Instead of having no information, we'll
> end up with odd information. If people complain, we can always
> blacklist (indeed, won't the ACPI rolling blacklist catch the majority
> of these machines?)
I don't think the rolling blacklist will catch this, as the rest of the
ACPI code is "correct".
And yes, incorrect information exported by the kernel is not good at
all, especially if a user expects it to work properly :)
> > I say this because for a long time there was no "standard" acpi entries
> > for hotplug slots and different companies did different things. Hence
> > the "odd" IBM acpi hotplug implementation as one example. If this is
> > going to go anywhere, you need to get IBM to agree that it works
> > properly with all their machines...
>
> Not in terms of slot names. There were various things that ACPI didn't
> specify, like attention and latches, but the description of _SUN hasn't
> changed.
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".
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...)
> > 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?
>
> Do you have any examples of this?
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.
> We should, IMO, be improving the way we tell users which device has
> a problem. 'tulip7', 'eth4', 'pci 0000:04:1e.3' ... all the user wants
> to know is which damn card it is so they can replace it. And slot name
> tells them that.
Not if the slot information is incorrect :)
That's my main concern.
thanks,
greg k-h
next prev parent reply other threads:[~2007-11-13 18:52 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 [this message]
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
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=20071113185122.GA22536@kroah.com \
--to=greg@kroah.com \
--cc=achiang@hp.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