Re: [PATCH] kconfig: untangle EXPERT and EMBEDDED

[David Rientjes <rientjes@google.com>]

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.