linux-kernel - Re: sata & scsi suggestion for make menuconfig

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: <46EABBBB.7060201@s5r6.in-berlin.de>
Date:	Fri, 14 Sep 2007 18:50:03 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Adrian Bunk <bunk@...nel.org>
CC:	Jeff Garzik <jeff@...zik.org>, Andi Kleen <andi@...stfloor.org>,
	James Bottomley <James.Bottomley@...elEye.com>,
	Folkert van Heusden <folkert@...heusden.com>,
	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org
Subject: Re: sata & scsi suggestion for make menuconfig

Adrian Bunk wrote:
> On Fri, Sep 14, 2007 at 05:37:37PM +0200, Stefan Richter wrote:
>> In
>> practice, this takes too much time, hence you take an existing .config
>> (yours or somebody else's) and go from there.
> 
> Kconfig let's you start with the defconfig when doing "make menuconfig" 
> without any .config present,
[...]

This is one of those "somebody else's .config".

>> Whenever one enables an option for the first time, it would IMO be
>> foolish to ignore its help text.
> 
> Then the number of non-foolish users is quite near to 0...

Perhaps.  Although I meant only options which one enables oneself, not
options which are taken over from somebody else's .config.

> If you expect people to read several hundreds or thousands of help texts 
> only for configuring a kernel then you are expecting something that is 
> simply not realistic.
> 
> It is intuitive for a user to enable the "Serial ATA" menu and he might 
> not expect to have to read the help text when he has SATA drivers, while 
> having to enable anything in the "SCSI device support" menu is highly 
> unintuitively when the user does not have SCSI hardware.

It surely is unintuitive, and it is one of the worse cases where the
current menu layout is unintuitive.  We have to improve that, even
though it is ultimately impossible to serve everyone's needs equally
well or, generally, make kernel configuration a piece of cake.

Note though, some suggestions which came up here don't actually make the
menus more intuitive.  Notably the patch "Select BLK_DEV_SD for all
SCSI/libata drivers" is counterintuitive in a different color:  It
follows the philosophy of "I know what's good for you and I act on your
behalf behind your back --- trust me, it's for your best".

I too am guilty of proposing the usage of 'select'
(http://lkml.org/lkml/2007/9/8/9) but I suggested a variant which lets
the user stay informed and in control (as far as this is possible with
'select' which always increases complexity, never reduces it).

But rather than adding multiple menu items which enable the same option,
a reorganization of the menus which better reflect the role of SCSI core
and SCSI highlevel might be more effective --- similar to "Networking"
which is separate from "Network device support"
(http://lkml.org/lkml/2007/9/10/5, http://lkml.org/lkml/2007/9/10/115).
-- 
Stefan Richter
-=====-=-=== =--= -===-
http://arcgraph.de/sr/
-
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/