From: Bjorn Helgaas <bhelgaas@google.com>
To: Ulrich Drepper <drepper@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>,
jbarnes@virtuousgeek.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
lenb@kernel.org, x86@kernel.org, linux-pci@vger.kernel.org
Subject: Re: SNB PCI root information
Date: Wed, 20 Jun 2012 12:46:38 -0600 [thread overview]
Message-ID: <CAErSpo6JWKoFcbsLnyzPGXLKssobfudjcYMvYzfEpYZ-bzCHPg@mail.gmail.com> (raw)
In-Reply-To: <CAOPLpQchY4gMYaw-Ew5uujD9JCu==VLjQ7Z_OjrT6akTgX4+iA@mail.gmail.com>
On Wed, Jun 20, 2012 at 11:59 AM, Ulrich Drepper <drepper@gmail.com> wrote:
> On Wed, Jun 20, 2012 at 1:17 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
>> I don't understand this. Is there an *advantage* to silently throwing
>> away the information the user specified on the command line? If the
>> user goes to the trouble of discovering and using a command line
>> argument, I think that user-supplied information should override
>> anything the kernel can figure out on its own. Ulrich, do you have an
>> opinion either way?
>
> If the BIOS information we look for would be something generic then we
> might want to have something to overwrite. But in this case it's a
> very specific piece of information which only has one correct value
> and I'd hope the BIOS writers get it right.
>
> Assuming this there *might* be value in having it the way the patch
> does now. If the BIOS changes it could in theory also renumber the
> devices etc. In this case the kernel command line overwrite values
> might become wrong while a newly-added _PXM entry might be right.
> We've seen all kind of things happening on BIOS updates...
>
> On the other hand it's easy enough to then remove the kernel command
> line parameter. It's also probably more in line with other parameters
> which overwrite information the kernel determines otherwise
> automatically.
>
> I'd be willing to go with Yinghai's recommendation and give the BIOS
> writers the benefit of a doubt that they get things right. If they
> prove to be incapable again we can still change the option handling to
> overwrite the kernel setting regardless.
As far as I can tell, here's Yinghai's recommendation: the user
argument should not override BIOS _PXM because if the BIOS gets the
_PXM wrong, the user won't be able to work around it with the
argument, which will force the vendor to fix the BIOS.
I'm not buying it. The convention that user-supplied arguments always
take precedence is useful, easy to document, and matches user
expectations. It allows the user to work around both missing _PXM and
incorrect _PXM.
Bjorn
next prev parent reply other threads:[~2012-06-20 18:47 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAOPLpQfUm-2ENkbnYfXEn1nf9FHnaRk3aqQTSTBWb-CsfCUCFA@mail.gmail.com>
2012-06-16 3:03 ` SNB PCI root information Yinghai Lu
2012-06-16 8:52 ` Thomas Gleixner
2012-06-16 19:36 ` Yinghai Lu
2012-06-16 21:56 ` Bjorn Helgaas
2012-06-18 22:30 ` Ulrich Drepper
2012-06-18 23:40 ` Yinghai Lu
2012-06-19 12:36 ` Bjorn Helgaas
2012-06-19 18:20 ` Yinghai Lu
2012-06-20 17:11 ` Ulrich Drepper
2012-06-20 17:17 ` Bjorn Helgaas
2012-06-20 17:59 ` Ulrich Drepper
2012-06-20 18:37 ` Yinghai Lu
2012-06-20 18:46 ` Bjorn Helgaas [this message]
2012-06-20 19:28 ` Yinghai Lu
2012-06-20 19:34 ` Ingo Molnar
2012-06-20 20:04 ` Ulrich Drepper
2012-06-20 20:16 ` Bjorn Helgaas
2012-06-20 21:21 ` Ulrich Drepper
2012-06-20 23:58 ` Yinghai Lu
2012-06-21 2:37 ` Yinghai Lu
2012-06-21 3:50 ` Yinghai Lu
2012-06-21 12:17 ` Ulrich Drepper
2012-06-21 16:22 ` Ulrich Drepper
2012-06-21 18:11 ` Yinghai Lu
2012-06-25 17:54 ` Ulrich Drepper
2012-06-20 19:57 ` Brice Goglin
2012-06-21 2:43 ` Yinghai Lu
2012-06-21 5:56 ` Brice Goglin
2012-06-21 19:24 ` Yinghai Lu
2012-06-22 7:14 ` Brice Goglin
2012-06-22 17:28 ` Yinghai Lu
2012-06-22 20:38 ` Brice Goglin
2012-06-22 20:41 ` Yinghai Lu
2012-06-25 9:07 ` Brice Goglin
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=CAErSpo6JWKoFcbsLnyzPGXLKssobfudjcYMvYzfEpYZ-bzCHPg@mail.gmail.com \
--to=bhelgaas@google.com \
--cc=drepper@gmail.com \
--cc=jbarnes@virtuousgeek.org \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=x86@kernel.org \
--cc=yinghai@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).