linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@stusta.de>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Sam Ravnborg <sam@ravnborg.org>, Dave Jones <davej@redhat.com>,
	linux-ide@vger.kernel.org,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>
Subject: Re: tighten ATA kconfig dependancies
Date: Sun, 16 Jul 2006 11:13:33 +0200	[thread overview]
Message-ID: <20060716091332.GW3633@stusta.de> (raw)
In-Reply-To: <1152961003.3114.15.camel@laptopd505.fenrus.org>

On Sat, Jul 15, 2006 at 12:56:43PM +0200, Arjan van de Ven wrote:
> 
> > > the point is that it doesn't fall out naturally, and thus things get
> > > needlessly missed.
> > 
> > It seems the main question is:
> > Is the kernel configuration mainly designed for users or for developers?
> > 
> > For users, showing drivers for hardware that is not present on their 
> > platform only causes confusion.
> 
> well Aunt Tilly gets confused by all hardware that is not present on her
> machine; she has no idea what a platform is. By that reasoning, we
> should make kconfig hide all non-present hardware.
> 
> Also I think there is no difference in confusion between showing 10 or
> 15 IDE chipsets. Either the user knows what he has (and then it doesn't
> matter) or those 10 are too much already.

It's not about Aunt Tilly, it's about an average systems administrator 
compiling his own kernel.

And there are already too many options visible, and the result are real 
world problems - I've seen it too often that someone didn't compile the 
support for his IDE chipset into the kernel. And this specific patch is 
only a small part of the general issue.

The situation was different if only developers and distributions would 
compile kernels, but that's not what's happening in the real world. 
Kernel developers are only a tiny minority amongst the people 
configuring and compiling their own kernel.

And if the "compile coverage" point was meant seriously, we'd also need 
some dummy #define's for getting all currently BROKEN_ON_SMP options 
compiling with CONFIG_SMP=y since in my experience they are getting
nearly zero compile coverage since it seems the "compile coverage" crowd 
only blindly runs allmdconfig/allyesconfig.

I'm often reporting and sometimes fixing compile errors, but that's OK.
Compile errors are really obvious errors (compared to e.g. runtime 
corruptions), and therefore not a real problem.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


  reply	other threads:[~2006-07-16  9:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-15  5:34 tighten ATA kconfig dependancies Dave Jones
2006-07-15  5:49 ` Arjan van de Ven
2006-07-15  6:38   ` Sam Ravnborg
2006-07-15  6:45     ` Arjan van de Ven
2006-07-15 10:28       ` Adrian Bunk
2006-07-15 10:56         ` Arjan van de Ven
2006-07-16  9:13           ` Adrian Bunk [this message]
2006-07-24  3:05 ` Alan Cox
     [not found] <6yL2J-7rR-1@gated-at.bofh.it>
     [not found] ` <6yLco-7DB-1@gated-at.bofh.it>
2006-07-15 18:38   ` Bodo Eggert
2006-07-16  5:58     ` Sam Ravnborg
2006-07-16  6:04       ` Arjan van de Ven
2006-07-16  6:17         ` Sam Ravnborg
  -- strict thread matches above, loose matches on Subject: below --
2006-07-16 18:14 Randy Dunlap

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=20060716091332.GW3633@stusta.de \
    --to=bunk@stusta.de \
    --cc=akpm@osdl.org \
    --cc=arjan@infradead.org \
    --cc=davej@redhat.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sam@ravnborg.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).