lkml.org 
[lkml]   [2008]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PATCH] SCSI updates for 2.6.25

* James Bottomley <James.Bottomley@HansenPartnership.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


\
 
 \ /
  Last update: 2008-04-21 14:53    [W:0.072 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site