linux-kernel - Re: [PATCH] BLOCK: Make it possible to disable the block layer

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 24 Aug 2006 18:16:03 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Adrian Bunk <bunk@...sta.de>
Cc:	Alexey Dobriyan <adobriyan@...il.com>,
	David Howells <dhowells@...hat.com>,
	Jens Axboe <axboe@...e.de>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

On Thu, 2006-08-24 at 19:07 +0200, Adrian Bunk wrote:
> Do a "make menuconfig" and look at the number of options.

Why would I do that? I haven't done that for _years_. I've just edited
the .config file, removed the line which turns some option on or off,
then run 'make oldconfig'. I get asked about the option in question, and
then if I've turned something on I get asked about other options which
depend on it and which are now possible but weren't before.

Increasingly, these days, that approach has been failing due to all this
Aunt Tillie crap. I tried turning off CONFIG_KALLSYMS the other day, but
it took me a while to work out how. And the increasing use of 'select'
is even worse.

> There's e.g. no reason to ask all users whether they want to compile all 
> I/O schedulers into their kernel.
> 
> To avoid misunderstandings:
> 
> I'm not talking about people subscribed to this list.
> 
> It's more about a system administrator who must for some reason (e.g. 
> hardware support or the requirement of some external patch) compile his 
> own kernel.

Why on earth would they create a config file from scratch instead of
using a defconfig or the config from their distribution and modifying it
so suit their needs?

For most things, they ought to be able to just build extra modules to
_match_ their distribution's kernel, without having to rebuild the
kernel itself. (Although people doing stupid things in the kernel like
#ifdef CONFIG_foo_MODULE tends to screw them sometimes -- I can't build
IPv6 for my Nokia 770 without replacing its kernel, for example).

People just don't have that much cause to create configs from scratch --
there's little benefit in pandering to those who are less able. Make the
_defaults_ sane, by all means -- but don't just start hiding options.

However you dress it up, it's still ESR's Aunt Tillie come to haunt us.
And it's a PITA.

-- 
dwmw2

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