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: <46E53C00.6060107@gmail.com>
Date:	Mon, 10 Sep 2007 14:43:44 +0200
From:	Rene Herman <rene.herman@...il.com>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
CC:	James Bottomley <James.Bottomley@...elEye.com>,
	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

On 09/10/2007 08:38 AM, Stefan Richter wrote:

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

If someone's keen on really restructuring these things -- in this analogy:

Storage
	Storage Options
		...
		Disk
		Optical
		...
	...

Device Drivers
	...
	Storage Support
		...
		IDE
		PATA
		SATA
		SCSI
		USB
		FW
		...
	...

(sound is an example where both in the menus and the tree everything is kept 
under one top-level sound/ directory, not sound/ and drivers/sound/ as for 
networking -- opinions may vary which one's better I guess).

This is just config menus -- on a source code level, it would also make 
sense at least at some point to introduce "storage/" alongside net/ and 
sound/ and move things around I guess.

Rene.

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