On Sat 18 Jul 2009 13:50, Wolfgang Denk pondered:
Dear Robin Getz,
In message 200907181115.26404.rgetz@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