Re: [PATCH] kconfig: untangle EXPERT and EMBEDDED

[Andrew Jones]

On Mon, Jan 16, 2012 at 06:34:44PM +0100, Geert Uytterhoeven wrote:
> On Mon, Jan 16, 2012 at 16:50, Andrew Jones <drjones@xxxxxxxxxx> wrote:
> > On Mon, Jan 16, 2012 at 04:40:47PM +0100, Jerome Marchand wrote:
> >> > @@ -1259,8 +1259,7 @@ config SLUB
> >> >        a slab allocator.
> >> >
> >> >  config SLOB
> >> > -   depends on EXPERT
> >> > -   bool "SLOB (Simple Allocator)"
> >> > +   bool "SLOB (Simple Allocator)" if EXPERT
> >> >     help
> >> >        SLOB replaces the stock allocator with a drastically simpler
> >> >        allocator. SLOB is generally more space efficient but
> >>
> >> Am I missing something or this particular chunk does not actually change
> >> anything?
> >
> > No, you're correct. There's no actual change, so the hunk could be dubbed
> > as an unnecessary cleanup. I made the change in order to give it the same
> > general format as the rest of the expert options in that file.
> 
> There _is_ a difference:
>   - "depends on EXPERT" means the option cannot be enabled by the user.
>     "select SLOB" will still override that, but kconf will print a warning.
>   - "bool ... if EXPERT" means the question will only be asked if EXPERT.
>     Other Kconfig logic can still "select SLOB" if it wants to.
>

No, they are equivalent. It says in the documentation
(Documentation/kbuild/kconfig-language.txt)

    - dependencies: "depends on" <expr>
      This defines a dependency for this menu entry. If multiple
      dependencies are defined, they are connected with '&&'. Dependencies
      are applied to all other options within this menu entry (which also
      accept an "if" expression), so these two examples are equivalent:

            bool "foo" if BAR
            default y if BAR
      and
            depends on BAR
            bool "foo"
            default y

SLOB doesn't have a default option in its entry (it actually can't, since
it's a choice value), or any other option type besides help, so the change
in the patch above is precisely equivalent.

If you got a warning with one style, but not the other, then that would be
a bug with kconf. However, I just tried to generate a warning with both
styles and couldn't.

Drew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/