[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1170717694.29759.941.camel@pmac.infradead.org>
Date: Mon, 05 Feb 2007 23:21:34 +0000
From: David Woodhouse <dwmw2@...radead.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Randy Dunlap <randy.dunlap@...cle.com>,
Ingo Molnar <mingo@...e.hu>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, 2007-02-05 at 15:09 -0800, Linus Torvalds wrote:
> I also feel that a lot of people are "advanced" in one area, but not
> necessarily in another. The Netfilter example I gave was one such personal
> gripe of mine. I just feel like I shouldn't need to care! Yeah, I have the
> knowledge, but I *still* want to be baby-fed with just a simple "anybody
> can understand it".
The netfilter example is totally irrelevant here, since 'select' is
neither necessary nor sufficient for that. Russell and I have both
pointed that out to you already.
> Why? You could *trivially* have a tool tell you. Make "xconfig" or
> something just pop up a window saying "sorry, you can't disable SCSI,
> because you've got ATA enabled, and ATA wants SCSI".
>
> What's the big deal, here?
Mostly that for the benefit of users who really don't actually configure
their own kernels at all, we're screwing over the people who _do_, and
who want this to work like it always did:
sed -i -e 's/CONFIG_I2C=.*/# CONFIG_I2C is not set/' .config
make oldconfig
Not only does that not work like it always did, but it's also _really_
hard to find out why, on occasion. You have to grep all over the tree to
find the offending 'select' statement.
The other reason that a bunch of us are objecting is because we seem to
be doing this for very little real benefit -- if we wanted to pander to
Aunt Tillie, we could have done it in the tools. As I said, that was
working ten years ago. Maybe not merged back into your tree but working
nonetheless. It's not rocket science.
But Alan makes a reasonable suggestion -- we could work around this in
the tools too. I think you're very misguided in optimising for the
people who aren't likely to be configuring their own kernels anyway, but
despite the fact that others seem to agree with me, I don't hold out
much hope of changing your mind. If we can hack up the kconfig library
to work around this bogosity by (optionally) treating all 'select' of
visible symbols as 'depends on' instead, then I think that should
actually work OK.
--
dwmw2
-
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