Message-ID: <20120113122202.GB2452@turtle.usersys.redhat.com>
Date:	Fri, 13 Jan 2012 13:22:03 +0100
From:	Andrew Jones <drjones@...hat.com>
To:	David Rientjes <rientjes@...gle.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, Jan 13, 2012 at 02:53:27AM -0800, David Rientjes 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.

> why it currently selects EXPERT, but we'd like to be able to separate 
> those out so they can make more sane decisions and introduce things like 
> "depends on EXPERT || EMBEDDED".

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".

> Don't think of 6a108a14fa35 as renaming CONFIG_EMBEDDED to CONFIG_EXPERT, 
> think of it as adding CONFIG_EXPERT which is what it really does and frees 

I do think of 6a108a14fa35 as adding CONFIG_EXPERT, and I like
CONFIG_EXPERT, but I also think of it as adding CONFIG_EXPERT incorrectly.

> 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.

It's not clear to me, that it's clear to everyone else, what this patch is
really trying to fix. Below is a fun way to try and express it. It's done
in dialog form. Hopefully it'll be entertaining as well as get the point
across.

Developers Alice and Bob work on subcomponent XYZ and are chatting

Alice> hey Bob, I think we need a new symbol to compile out some
code that not all of our customers want
Bob> really? Ugh, The XYZ config menu already has tons of options,
and most have defaults that should really never be touched anyway.
I sure hate adding yet another...
Alice> hmm... Oh, I remember there's this nifty CONFIG_EXPERT that
some options use in order to hide from the standard configmenu.
The options are only available to experts that turn on EXPERT
Bob> oh, that sounds cool. We can clean up our whole menu by adding
that to the options nobody should be touching. Then for those
special customers we can turn CONFIG_EXPERT on and override the
default of that new option to off
Alice> OK, Kconfigs updated, new config with CONFIG_EXPERT=y and
CONFIG_XYZ_SPECIAL=n created, load, cock, fire, release the code
to QA!

...some time later...

QA person> HEY! Why is the kernel missing important features from
other subcomponents?
Alice+Bob> err.. We don't know. Last update we did was only to
XYZ's Kconfig files. Oh, and we turned on that nifty CONFIG_EXPERT,
but that shouldn't do anything...

...Alice and Bob take a closer look...

Alice> CRAP! CONFIG_EXPERT doesn't just expose config options, it
actually turns stuff off too!!
Bob> Ugh, CONFIG_EXPERT is junk

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