Date:	Mon, 16 Jan 2012 15:37:01 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Jerome Marchand <jmarchan@...hat.com>
cc:	Andrew Jones <drjones@...hat.com>, 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 Mon, 16 Jan 2012, Jerome Marchand wrote:

> I don't see what your objections to this patch are. It actually does not
> change anything to CONFIG_EMBEDDED and 6a108a14fa35 didn't either.

Then you don't understand the context in which it was written.  
CONFIG_EMBEDDED was hijacked to allow certain options to be configurable 
that have nothing to do with embedded devices.  It was a dumping ground 
for any option that was non-standard.  So we decided that enough is enough 
and to actually give it a name that would imply you should know what 
you're turning on and off before you can configure it.

We also didn't want to break the millions of configs out in the wild that 
tune CONFIG_EMBEDDED, so we allowed it to select EXPERT in the meantime 
for backwards compatibility.  This allowed CONFIG_EMBEDDED to be extended 
in the future so that it could separate the options away from EXPERT that 
actually made sense for embedded devices to be aware of a configure.  At 
that point, it would be possible to remove the "select EXPERT" from 
CONFIG_EMBEDDED once all existing users become "depends on EXPERT || 
EMBEDDED", or possibly even just "depends on EMBEDDED" in rare cases where 
non-embedded users would never want to enable it.  (CONFIG_SLOB may be an 
example of the latter, but I'll leave that to the embedded world to 
decide.)

> For instance, Why would CONFIG_EXPERT disable by default some HID devices?
> I could understand why it is done for CONFIG_EMBEDDED, but certainly not
> for an general EXPERT option.
> 

Then this is a prime example that you've identified were it would make 
sense to have the default value be dependant on EMBEDDED rather than 
EXPERT.  Feel free to send a patch to the HID maintainers.

> >> 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".
> >>
> 
> If EMBEDDED was insane before 6a108a14fa35, then it still was after, since
> nothing changed. EMBEDDED was just renamed EXPERT, and the "new" EMBEDDED
> option just selects EXPERT.
> 

Except now it's possible to decouple from EXPERT.  That's the goal that 
Andrew doesn't understand and he's fine with breaking everybody's config 
because they aren't defconfigs and there's no way such a thing would be 
merged.
--
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