Dear Robin Getz,
In message 200907181713.25601.rgetz@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