lkml.org 
[lkml]   [2007]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [patch] MTD: fix DOC2000/2001/2001PLUS build error
    From
    Date
    On Mon, 2007-02-05 at 08:32 -0800, Linus Torvalds wrote:
    >
    > On Mon, 5 Feb 2007, David Woodhouse wrote:
    > >
    > > Secondly, please don't _ever_ use 'select'.
    >
    > No, David.
    >
    > I don't know why you keep repeating this mantra, when it's WRONG.

    It may not shock you to find that I repeat it because I disagree.

    > Using "select" is a lot more sane and intelligent than assuming that users
    > know what dependencies they want.
    >
    > The Kconfig files should ask about *end-user* visible features. They
    > should say "do you want to support X".

    For the benefit of some, that's useful. Others still want to be able to
    turn off entire subsystems when they don't compile or when they want to
    quickly build a minimal kernel. It's become very hard to do that though.

    > If "X" then needs Y, Z and something else to actually compile, then that
    > Kconfig file should DAMN WELL use "select". Stop claiming anything else!

    I agree that the tools should let them do that easily. It doesn't
    necessarily follow that we should use 'select' for that purpose.

    > The user shouldn't know that they should say that they need some library Y
    > in order to even see the question for "X". It's not a sane thing to ask
    > them to know and care about. They care about the devices or capabilities
    > they want to support, not about the fact that a USB storage device needs
    > the SCSI core layer, for example.

    This I agree with. And it's something which the _tools_ have been
    capable of for a long time. You don't need 'select'.

    The problem is that the widespread and inconsistent use of 'select' for
    Aunt Tillie's benefit causes problems for a _different_ set of people.
    To use Ingo's example -- if I want to turn off CONFIG_I2C because it
    doesn't build or I want it modular to hack on it, I want to be able to
    just _do_ that.

    I don't want to find that it's forced to 'Y' because I also happen to be
    building support for some esoteric peripheral that I've never heard of.
    I want that that peripheral to be turned _off_ when I turn I2C off. I
    don't want to have to spend hours grepping _all_ over the tree to find
    out what's forcing I2C on again. When it was just dependencies, it was
    easy enough to find -- it was right there in the Kconfig file in one
    place. Now it's a lot harder.

    And I'm sure you aren't seriously suggesting that we should take it all
    the way and that, for example, all SCSI host drivers should 'select
    SCSI' rather than merely depending on SCSI? If I configure a kernel I
    don't _want_ to be asked individually about every leaf option -- I want
    to be able to turn stuff off in an orderly fashion; in a tree as Ingo
    suggests.

    --
    dwmw2

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-02-05 17:55    [W:4.664 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site