[U-Boot] [RFC] CONFIG naming convetion

[Wolfgang Denk]

Dear Robin Getz,

In message <200907181713.25601.rgetz at blackfin.uclinux.org> you wrote:
>
> It's a namespace - controls if a driver is compile in or not. 
> Should only be used in .config files, and Makefiles.

What's the difference between adding a driver and any other feature?

> Some (very few) already use it..

These can easily be fixed :-)

> > My personal way of thinking about such options is usually  CPU/archi-
> > tecture  first,  so I would probably chose CONFIG_OMAP24XX_I2C to en-
> > able/disable the I2C driver on a OMAP24XX based board, but  I  under-
> > stand  that there are reasons to prefer CONFIG_I2C_OMAP24XX as well -
> > let's see if there is a clear majority of opiniions...
> 
> If we are thinking of a "tree" type structure - it might make sense to
> start at the top? I guess the question is -- is it an I2C driver for 
> the OMAP24xx or a OMAP24xx driver for I2C?
> 
> Since the API is a I2C API - my thought it is an I2C driver, which happens
> to run on a specific SoC. The actual SoC doesn't really matter (and
> should be last) - so it is similar to the directory structure we have today.

That's why I said that I understand that there are reasons for such a
name.

> Then I can start sending patches for unused CONFIG_ from random config files,
> and no one will start complaining?

Probably.

> From what I can quickly tell - there seems to be about 472 different CONFIG_ 
> options in ./include/config that are not actually used anywhere in the master
> tree.

I guess lots of these is indeed garbage that can be removed without
anybody noticing it.

> > > I would think should be CONFIG_DRIVERS_PATA_BFIN
> > 
> > I dosagree, the "DRIVERS" part is just added line noise.
> 
> It's a name space - making sure it is differentiated from an option.

Yeah, and we end up with variable names that cannot be used any more
because they exceed the maximum line length.

> I think there needs to be more words - do you mean:
>   - hardware, CPU level? or
>   - hardware, SoC level? or 
>   - hardware, board level?

Hm... I don't see any real need for adding additional  characters  to
the  CONFIG_(SYS_)*  names  -  I  am  not  aware that we ever had any
problems because of name collisions.

> Personally - I don't think board level things should be CONFIG_SYS_, as
> these need to be switched around by board porters.
> 
> I guess we could back up a step and look at the users, and defined things
> as things that should be changed by:
>  - arch maintainers (Core/CPU specific)
>  - SoC maintainer (SoC specific)
>  - Board maintainer (PCB specific)
>  - End user of the above (changes options, but nothing from the above list?)

Frankly, this makes no sense to me. I have yet to see any such clear
split of roles and functions. When you bring up a new board, you
usually have to check everything.

The only split that made, and still makes, kind of sense to me is the
split into normal users (CONFIG_) versus "root" (CONFIG_SYS_) groups.

> I'm happy to write a patch - but I have a feeling what I think isn't what
> everyone else's opinion is...

It seems there are at least two sets, one containing you,  the  other
one  containing  me.  I  have no information about the cardinality of
each, though ;-)

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Software suppliers are trying to make their  software  packages  more
``user-friendly''.  .  .  .  Their best approach, so far, has been to
take all the old brochures, and stamp the words, ``user-friendly'' on
the cover.                                               - Bill Gates