On Tue, 4 Mar 2008 11:30:36 -0800 Greg KH <gregkh@xxxxxxx> wrote: > On Tue, Mar 04, 2008 at 10:18:28AM -0800, Jesse Barnes wrote: > > On Monday, March 03, 2008 9:49 pm Greg KH wrote: > > > On Sat, Mar 01, 2008 at 07:43:07AM -0700, Matthew Wilcox wrote: > > > > On Fri, Feb 29, 2008 at 09:25:42PM -0800, Greg KH wrote: > > > > > What is the guarantee that the names of these slots are > > > > > correct and do not happen to be the same as the hotpluggable > > > > > ones? > > > > > > > > That would be a bug -- and yes, bugs happen, and we have to > > > > deal with them. > > > > > > My main concern is that BIOS vendors will not fix these bugs, as > > > no other OS cares/does this kind of thing today. The ammount of > > > bad information out there might be quite large, and I think this > > > was confirmed by some initial testing of IBM systems, right? > > > > Yeah, but there's a flip side to this too: if no one uses the > > data, no one will complain when it's wrong. If Linux starts making > > it easy to see this stuff, there's a chance system vendors will > > start taking an extra 5 min. before shipment to make sure that the > > BIOS info is up to date... > > > > OTOH, I'm not sure which is worse, bad data or no data. > > bad data is worse. > > And then there's the machines with duplicate slot names, how does this > code handle PCI slots with that? I think some of the IBM machines had > non-hotplug slots named the same as the hotplug slots, right? > > This stuff needs a _lot_ of testing on a lot of different machines, > and a sane way to fall-back if there are errors to ensure that working > machines don't break. > > And then there's the issue with userspace programs only expecting > hotplugable slots in the slots/ directory... > > thanks, > > greg k-h > I too worry about interaction with other vendor's machines, so maybe we should make it easier to test by putting this series into linux-next? -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
