[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071113201954.GA26547@suse.de>
Date: Tue, 13 Nov 2007 12:19:54 -0800
From: Greg KH <gregkh@...e.de>
To: Matthew Wilcox <matthew@....cx>
Cc: Greg KH <greg@...ah.com>, Alex Chiang <achiang@...com>,
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 01:11:02PM -0700, Matthew Wilcox wrote:
> 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?
When you are touching code that I know is going to have problems on a
whole range of different manufacturer's machines, do you expect me to
just ignore that and let you add a feature that is going to be
incorrect?
> > 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.
Again, based on the past history with such things as mis-labeled
ethernet ports, I have doubts. I can hope, but I need proof based on
the major problems we have had in the past.
It is better to not show information to users at all, then to give them
information that is incorrect, don't you think?
> > 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.
Don't mix up things like filesystems and exposing pci slots. That is
just foolish...
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/
Powered by blists - more mailing lists