linux-kernel - Re: [GIT PATCH] SCSI updates for 2.6.25

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]

Date:	Mon, 21 Apr 2008 14:51:07 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Adrian Bunk <bunk@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-scsi <linux-scsi@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Greg KH <greg@...ah.com>
Subject: Re: [GIT PATCH] SCSI updates for 2.6.25

* James Bottomley <James.Bottomley@...senPartnership.com> wrote:

> On Sat, 2008-04-19 at 13:14 -0700, Linus Torvalds wrote:
> > On Sat, 19 Apr 2008, James Bottomley wrote:
> > > 
> > > Well, we already had this argument on linux-scsi when the interface was
> > > first proposed:  Apart from select being very nasty and should only be
> > > sparingly used
> > 
> > I'm still not understanding people who say that.
> 
> Well, I can ... even though SCSI is one of the major users of select 
> in the tree.

you are handling it well then :) I tend to be amongst the first ones to 
notice select trouble (randconfig is quite sensitive to it) and by far 
the leading area of failure "in practice" is video drivers and sound 
modules. Networking is an occasional blip on the radar (but that's 
really just due to its sheer natural size and complexity) and i dont 
remember any deep SCSI trouble there ever.

pie-in-the-sky: a fundamentally simpler Kconfig space would be nice, 
with strict hierarchies and where enabling a lower component 
automatically selects all the upper components as well. The Kconfig 
language should detect loops in hierarchies. (it already does so in a 
number of situations)

i.e. we should only describe what depends on what - and the rest would 
be figured out automatically. In that sense "select" should be a _user 
action_ that would never pop up in the language at all - and the 
"selection" would all trickle through automatically via the 'depends on' 
links without having to mention it in the Kconfig language.

whenever due to a selection that a user made something becomes 
unavailable, the kconfig tool/GUI should warn about that with an extra 
confirmation step. I.e. it should all really be analogous to normal 
user-space package management which has its own dependency resolution 
process.

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