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
next prev parent 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).