linux-kernel - Re: tighten ATA kconfig dependancies

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: <20060716091332.GW3633@stusta.de>
Date:	Sun, 16 Jul 2006 11:13:33 +0200
From:	Adrian Bunk <bunk@...sta.de>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Sam Ravnborg <sam@...nborg.org>, Dave Jones <davej@...hat.com>,
	linux-ide@...r.kernel.org,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>
Subject: Re: tighten ATA kconfig dependancies

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

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