[U-Boot] [RFC] CONFIG naming convetion

[Robin Getz]

On Sat 18 Jul 2009 13:50, Wolfgang Denk pondered:
> Dear Robin Getz,
> 
> In message <200907181115.26404.rgetz at blackfin.uclinux.org> you wrote:
> >
> > It would be nice to come up with some list of namespaces, and what they
> > they should be used for...
> 
> Agreed.

Excellent - a common goal :)

> > For example, should it be:
> > CONFIG_DRIVER_OMAP24XX_I2C
> > or
> > CONFIG_SYS_I2C_DRIVER_OMAP24XX
> > or
> > CONFIG_DRIVER_I2C_OMAP24XX
> 
> Well, the difference between CONFIG_ and CONFIG_SYS_ is well-defined.
> 
> And the "DRIVER_" part makes not much sense to me in any of the
> examples above. 

It's a namespace - controls if a driver is compile in or not. 
Should only be used in .config files, and Makefiles.

Some (very few) already use it..

./drivers/serial/Makefile:COBJS-$(CONFIG_DRIVER_S3C4510_UART) += s3c4510b_uart.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_3C589) += 3c589.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_AX88180) += ax88180.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_CS8900) += cs8900.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_DM9000) += dm9000x.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_KS8695ETH) += ks8695eth.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_LAN91C96) += lan91c96.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_NE2000) += ne2000.o ne2000_base.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_AX88796L) += ax88796.o ne2000_base.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_NETARMETH) += netarm_eth.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_NS7520_ETHERNET) += ns7520_eth.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_NS9750_ETHERNET) += ns9750_eth.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_RTL8019) += rtl8019.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_S3C4510_ETH) += s3c4510b_eth.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_SMC91111) += smc91111.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_SMC911X) += smc911x.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_TI_EMAC) += davinci_emac.o
./drivers/i2c/Makefile:COBJS-$(CONFIG_DRIVER_DAVINCI_I2C) += davinci_i2c.o
./drivers/i2c/Makefile:COBJS-$(CONFIG_DRIVER_OMAP1510_I2C) += omap1510_i2c.o
./drivers/i2c/Makefile:COBJS-$(CONFIG_DRIVER_OMAP24XX_I2C) += omap24xx_i2c.o
./drivers/i2c/Makefile:COBJS-$(CONFIG_DRIVER_OMAP34XX_I2C) += omap24xx_i2c.o
./drivers/i2c/Makefile:COBJS-$(CONFIG_DRIVER_S3C24X0_I2C) += s3c24x0_i2c.o
./drivers/mtd/Makefile:COBJS-$(CONFIG_FLASH_CFI_DRIVER) += cfi_flash.o
./drivers/mtd/nand/Makefile:COBJS-$(CONFIG_DRIVER_NAND_BFIN) += bfin_nand.o
./board/micronas/vct/Makefile:COBJS-$(CONFIG_DRIVER_SMC911X) += ebi_smc911x.o smc_eeprom.o
./cpu/arm926ejs/davinci/Makefile:COBJS-$(CONFIG_DRIVER_TI_EMAC) += lxt972.o dp83848.o

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

> > Again - which is only used in one place:
> > drivers/i2c/Makefile:COBJS-$(CONFIG_DRIVER_OMAP24XX_I2C) += omap24xx_i2c.o
> > include/configs/omap2420h4.h:#define CONFIG_DRIVER_OMAP24XX_I2C
> > 
> > Which is fine - since it is a driver, which I'm sure that people out of tree use.
> 
> Well, if only out-of-tree ports use it, it probably should never have
> been added in the first place.

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

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

As you pointed out - this is what exists in the README today. (which
I have read, but gained no clarity from it)...

=======================
* Configuration _OPTIONS_:
  These are selectable by the user and have names beginning with
  "CONFIG_".

* Configuration _SETTINGS_:
  These depend on the hardware etc. and should not be meddled with if
  you don't know what you're doing; they have names beginning with
  "CONFIG_SYS_".
=======================

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

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

? 

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

-Robin