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: <46E4E64F.3070005@s5r6.in-berlin.de>
Date:	Mon, 10 Sep 2007 08:38:07 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	James Bottomley <James.Bottomley@...elEye.com>
CC:	Andi Kleen <andi@...stfloor.org>, Jeff Garzik <jeff@...zik.org>,
	Folkert van Heusden <folkert@...heusden.com>,
	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org
Subject: Re: sata & scsi suggestion for make menuconfig

James Bottomley wrote:
> On Sun, 2007-09-09 at 23:22 +0200, Andi Kleen wrote:
>> When it costs 10000 people half an hour to learn and correct this it 
>> wasted 5000 hours of previous livetime.
>>
>> Besides there is no good reason to have ever learned this imho.
> 
> The process of becoming an expert in the kernel build system naturally
> involves making mistakes and learning from them, so this is probably
> time reasonably well spent.

Nevertheless we should try to arrange the menus in a way that makes
sense to as many people as possible.  The difficulty is, different
environments call for different menu layouts, as your previous example
of SATA DVD-only boxes demonstrates.

However, liberal usage of 'select' is not the ultimate solution to
create menus that work for more people.  Just one problem with select is
that it works behind the back of the people configuring kernels (unless
they use an UI with debug options turned on) --- they have less control,
they are less informed.  ATA already 'select's SCSI.  What do we gain
from hiding the fact that Linux' SCSI option is not just for those
50-wire ribbons (which people still think SCSI stands for) but is a very
central Linux subsystem for even more than what complies to the SCSI
family of standards?

'select' should really be limited to switch on small library-like code
without further dependencies or requirements.  SCSI, together with its
upper layer options, is not of this kind of library.

We should think about order and grouping of prompts and the labels of
prompts (there were already suggestions in this discussion) before we
resort to 'select' --- or even worse, select options unconditionally
which are not always necessary to be enabled.

A pro pos grouping of options --- consider how options for another
central subsystem are laid out:

	Networking
		Networking options
			...
			TCP/IP networking
			...
		...

	Device Drivers
		...
		Network device support
			...
			Ethernet (10 or 100MBit)
			...
		...

This also happens to reflect the layout of sources in directories, and
the current SCSI menu layout is close to source layout too --- but it
doesn't have to be that way.
-- 
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ