public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ross Biro <ross.biro@gmail.com>
To: Andi Kleen <ak@muc.de>
Cc: Ross Biro <rossb@google.com>, linux-kernel@vger.kernel.org
Subject: Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode
Date: Wed, 13 Apr 2005 19:00:06 -0400	[thread overview]
Message-ID: <8783be66050413160033e6283d@mail.gmail.com> (raw)
In-Reply-To: <20050413183725.GG50241@muc.de>

On 13 Apr 2005 20:37:25 +0200, Andi Kleen <ak@muc.de> wrote:
> \>
> > You're argument that no one can make sense of such options is totally off
> > base. Once you are having a problem, it's pretty easy to see if it's related
> 
> I dont think it is in any way help to put suche highly obscure
> things into Config. Near nobody can make any sense of it.
> 
> If you take a look at quirks.c and DMI options you will see we have quite a lot
> of workarounds for various hardware bug. Just imagine there were
> CONFIG options for all of this. It would be a big mess!

 The config option is for distro maintainers to use to set a policy
for their particular distribution.  The boot line option is for end
users to adjust it.  Last I heard, most distro makers compile their
own kernels and select options appropriately.  I really don't think
it's too much to ask an end user to adjust their grub.conf or
lilo.conf file to work around a bug in their hardware, especially
since their is *no way* to work around the bug in all cases with out
user intervention.

As I said before, the quirks routines cannot handle it since there is
no way to know what the correct setting is unless you know what
application is going to be run and what the users tolerance to
particular problems is.  In a perfect world, master abort mode would
always be set to on, but that is not practical in the real world.  If
you are suggesting that something in the quirks file stop the boot and
ask the user some questions about how they intend to use the system
and what their tolerance for certain types of errors is, then I think
you are suggesting an even bigger mess.

Someone creating a dstro for enterprise use would most likely compile
the kernel with master abort mode enabled to prevent silent data loss.
 Someone building the system for desktop use would choose either
default or disabled, to prevent spurious error messages, or hardware
lock ups.  If users report problems that look like they are caused by
the master abort mode setting, a tech support person could easily ask
the end user to add a boot time command line option to see if the
problem goes away.  The end user would then have the *option* of
adjusting the config file, or just using the boot time option.

I would aggree with you if it were not for the fact that the correct
setting of this bit is really a judgement call, so it must be simple
for anyone who needs to make the call to be able to.  The people
building distors will need to be able change the default setting
easily at compile time and the end user needs to be able to change the
setting at boot time or run time.

Someone on the PCI mailing list has suggested that it is enough to let
the distro maintainer edit the header file and adjust the setting
there.  To do so would mean that many distro maintainers would have to
maintain an additional patch for very little reason.  Perhaps the
correct solution is to keep it as a config option and add a
CONFIG_OBSCURE so that most people don't ever see option, but the few
that need to can.

    Ross

  reply	other threads:[~2005-04-13 23:00 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-05 19:33 [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode Ross Biro
2005-04-05 20:53 ` Randy.Dunlap
2005-04-06 12:47   ` Ross Biro
2005-04-06 20:44 ` Daniel Egger
2005-04-10 13:29 ` Andi Kleen
     [not found]   ` <8783be66050412075218b2b0b0@mail.gmail.com>
2005-04-13 18:37     ` Andi Kleen
2005-04-13 23:00       ` Ross Biro [this message]
2005-04-13 23:28         ` Dave Jones
2005-04-14 17:25           ` Ross Biro
2005-04-14 17:34             ` Tim Hockin
2005-04-14 18:02               ` Andi Kleen
2005-04-14 18:33                 ` Dave Jones
2005-04-14 19:14             ` Daniel Egger

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=8783be66050413160033e6283d@mail.gmail.com \
    --to=ross.biro@gmail.com \
    --cc=ak@muc.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rossb@google.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