Dear Robin Getz, In message <200907181713.25601.rg...@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: w...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
