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: <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

Powered by Openwall GNU/*/Linux Powered by OpenVZ