[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.1201131318340.24089@chino.kir.corp.google.com>
Date: Fri, 13 Jan 2012 13:27:35 -0800 (PST)
From: David Rientjes <rientjes@...gle.com>
To: Andrew Jones <drjones@...hat.com>
cc: Arnd Bergmann <arnd@...db.de>, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org, mingo@...e.hu,
david.woodhouse@...el.com, gregkh@...e.de, davem@...emloft.net,
axboe@...nel.dk, holt@....com, linux-arch@...r.kernel.org,
linux@....linux.org.uk, hskinnemoen@...il.com,
egtvedt@...fundet.no, msalter@...hat.com, a-jacquiot@...com,
starvik@...s.com, jesper.nilsson@...s.com, dhowells@...hat.com,
takata@...ux-m32r.org, geert@...ux-m68k.org,
yasutake.koichi@...panasonic.com, jonas@...thpole.se,
kyle@...artin.ca, deller@....de, jejb@...isc-linux.org,
chris@...kel.net, greg@...ah.com, davej@...hat.com,
airlied@...ux.ie, jkosina@...e.cz, mchehab@...radead.org,
johannes@...solutions.net, linville@...driver.com
Subject: Re: [PATCH] kconfig: untangle EXPERT and EMBEDDED
On Fri, 13 Jan 2012, Andrew Jones wrote:
> > What would be helpful is if CONFIG_EMBEDDED actually meant what it
> > implies, i.e. for config options that only make sense on embedded devices
> > (similar to CONFIG_SMALLMEM I mentioned earlier, but more focused).
>
> Agreed, but it's not the problem that this patch is attempting to solve.
> You and I are looking at this patch (and its predecessor 6a108a14fa35)
> from two different sides. I want CONFIG_EXPERT to work, and you want
> CONFIG_EMBEDDED to mean what it should. I'm saying that fixing EXPERT now,
> by reverting EMBEDDED back a bit, and then eventually fixing that later,
> is the better way to go. You're saying you don't want me to touch
> EMBEDDED, and thus far you've ignored the problem I'm attempting to solve.
>
CONFIG_EXPERT does work, there haven't been problems reported with it in
the year that it has been in the kernel, and CONFIG_EMBEDDED is available
to be extended to have its logical semantics. Right now, CONFIG_EMBEDDED
is pretty useless other than setting CONFIG_EXPERT but that could easily
be extended if someone wants to spend the time to separate options out
from CONFIG_EXPERT that don't make any sense for embedded devices. I'm
not from the embedded world, so I don't know the problems they face when
configuring the kernel.
> This patch is actually attempting to make progress in the separation of
> the semantics for EXPERT and the old, insane EMBEDDED, which had the very
> loose semantics. That's why it's called "untangle EXPERT and EMBEDDED".
>
You can't responsibly untangle EXPERT and EMBEDDED without making EMBEDDED
not select EXPERT and instead replace config options that should be
configurable only on embedded devices to do "depends on EXPERT ||
EMBEDDED". That's not what your patch does.
> > That's bogus, config EMBEDDED was used to select the new EXPERT so there
> > was no backwards compatibility issue. I'd agree with you that your patch
> > would be backwards compatible and doesn't suddenly, and silently, lose
> > config options that were previously enabled when running make oldconfig if
> > everybody in the world used defconfigs. That's not the case, which is why
> > this is a non-starter.
>
> The fact that this patch breaks backward compatibility is unfortunate, but
> the only way to fix the problem that it's attempting to fix, without that
> breakage, is to introduce yet another config option (EXPERT2 or
> REALLY_EXPERT?). If I'm not mistaken and config variable backward
> compliance isn't required, then I'd say breaking it makes much more sense
> then adding something like REALLY_EXPERT and all the mess that'll come
> with it.
>
Breaking backwards compatibility for users who aren't defconfigs is a
non-starter, as I've said. Admitting that your patch does it is almost
like nacking your own patch.
--
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