[U-Boot] [RFC] CONFIG naming convetion
Hi all,
Currently we have a mess in the drivers CONFIG naming convention as example on I2C we have CONFIG_I2C_XXXXX CONFIG_DRIVER_XXX_I2C CONFIG_XXXX_I2C CONFIG_SYS_I2C_XXXX
I think it will good to have common and clean naming convention so I'll propose we use this one CONFIG_namespace_XXXXX and CONFIG_SYS_namespace_XXXXX
so it will resutly for I2C to this
CONFIG_I2C_XXXXX CONFIG_SYS_I2C_XXXX
and the Makefile and KConfig it will be easier to sort and read
Best Regards, J.
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090718110338.GA30699@game.jcrosoft.org you wrote:
I think it will good to have common and clean naming convention so I'll propose we use this one
Funny. You first post a patch, then only then bother to discuss the topic.
Best regards,
Wolfgang Denk
Hello Wolfgang, Jean-Christophe,
Wolfgang Denk wrote:
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090718110338.GA30699@game.jcrosoft.org you wrote:
I think it will good to have common and clean naming convention so I'll propose we use this one
Funny. You first post a patch, then only then bother to discuss the topic.
Yep, thats what I thought too ;-)
Nevertheless, I am fine with using the proposed names for i2c
CONFIG_I2C_XXXXX CONFIG_SYS_I2C_XXXX
bye Heiko
On 14:50 Sat 18 Jul , Wolfgang Denk wrote:
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090718110338.GA30699@game.jcrosoft.org you wrote:
I think it will good to have common and clean naming convention so I'll propose we use this one
Funny. You first post a patch, then only then bother to discuss the topic.
the patch was send after :)
Best Regards, J.
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090718144826.GC30699@game.jcrosoft.org you wrote:
Funny. You first post a patch, then only then bother to discuss the topic.
the patch was send after :)
Well, hard facts tell a different story:
Patch: ... Received: from ns32433.ovh.net (HELO localhost) (plagnioj%jcrosoft.com@213.251.161.87) by ns0.ovh.net with SMTP; 18 Jul 2009 10:58:33 -0000 Message-id: 1247914560-30501-1-git-send-email-plagnioj@jcrosoft.com
Note that "1247914560" = Sat Jul 18 12:56:00 2009
... Subject: [U-Boot] [PATCH] i2c: use for CONFIGs a common naming convention CONFIG_I2C From: Jean-Christophe PLAGNIOL-VILLARD plagnioj@jcrosoft.com Date: Sat, 18 Jul 2009 12:56:00 +0200 To: u-boot@lists.denx.de
Proposal: ... Received: from ns32433.ovh.net (HELO localhost) (plagnioj%jcrosoft.com@213.251.161.87) by ns0.ovh.net with SMTP; 18 Jul 2009 11:06:09 -0000 Message-id: 20090718110338.GA30699@game.jcrosoft.org ... Subject: [RFC] CONFI# G naming convetion From: Jean-Christophe PLAGNIOL-VILLARD plagnioj@jcrosoft.com Date: Sat, 18 Jul 2009 13:03:38 +0200 To: U-Boot u-boot@lists.denx.de
The Date: header and internal timestamps (Messag-ID) clearly show that the patch was sent 5 minutes before the proposal.
Best regards,
Wolfgang Denk
On Sat 18 Jul 2009 07:03, Jean-Christophe PLAGNIOL-VILLARD pondered:
Hi all,
Currently we have a mess in the drivers CONFIG naming convention as example on I2C we have CONFIG_I2C_XXXXX CONFIG_DRIVER_XXX_I2C CONFIG_XXXX_I2C CONFIG_SYS_I2C_XXXX
I think it will good to have common and clean naming convention so I'll propose we use this one CONFIG_namespace_XXXXX and CONFIG_SYS_namespace_XXXXX
so it will resutly for I2C to this
CONFIG_I2C_XXXXX CONFIG_SYS_I2C_XXXX
and the Makefile and KConfig it will be easier to sort and read
I think this goes way beyond I2C....
There are ~4866 unique options in ./include/configs/*
Most of which have no name spaces at all, some are not even used in any source files (that are in mainline anyway).
We have 2815, which already start with CONFIG_SYS_xxx, like CONFIG_SYS_16M_MBMR Which is used in a single board:
board/snmc/qs860t/qs860t.c: memctl->memc_mbmr = CONFIG_SYS_16M_MBMR; board/snmc/qs860t/qs860t.c: size = dram_size (CONFIG_SYS_16M_MBMR, (long *)SDRAM_BASE, SDRAM_16M_MAX_SIZE); include/configs/QS860T.h:#define CONFIG_SYS_16M_MBMR 0x18802114 /* Mem Periodic Timer Prescaler */
It doesn't appear very "system" oriented to me...
It would be nice to come up with some list of namespaces, and what they they should be used for...
For example, should it be: CONFIG_DRIVER_OMAP24XX_I2C or CONFIG_SYS_I2C_DRIVER_OMAP24XX or CONFIG_DRIVER_I2C_OMAP24XX
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.
we assumed that it was: CONFIG_DRIVER_NAND_BFIN
but it depends on who added it... CONFIG_PATA_BFIN
drivers/block/Makefile:COBJS-$(CONFIG_PATA_BFIN) += pata_bfin.o include/configs/bf548-ezkit.h:#define CONFIG_PATA_BFIN
I would think should be CONFIG_DRIVERS_PATA_BFIN
?
On 11:15 Sat 18 Jul , Robin Getz wrote:
On Sat 18 Jul 2009 07:03, Jean-Christophe PLAGNIOL-VILLARD pondered:
Hi all,
Currently we have a mess in the drivers CONFIG naming convention as example on I2C we have CONFIG_I2C_XXXXX CONFIG_DRIVER_XXX_I2C CONFIG_XXXX_I2C CONFIG_SYS_I2C_XXXX
I think it will good to have common and clean naming convention so I'll propose we use this one CONFIG_namespace_XXXXX and CONFIG_SYS_namespace_XXXXX
so it will resutly for I2C to this
CONFIG_I2C_XXXXX CONFIG_SYS_I2C_XXXX
and the Makefile and KConfig it will be easier to sort and read
I think this goes way beyond I2C....
There are ~4866 unique options in ./include/configs/*
Most of which have no name spaces at all, some are not even used in any source files (that are in mainline anyway).
We have 2815, which already start with CONFIG_SYS_xxx, like CONFIG_SYS_16M_MBMR Which is used in a single board:
CONFIG_SYS_ is already well defined README extract * 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_".
so we do not need to touch non subsystem thinks on contrary of i2c, pci, nand etc...
It doesn't appear very "system" oriented to me...
it's as we had reorganise the drivers file place as example or the common Makefile and continue to do it eveyday (take a look on Peter e-mail about arch dir)
It would be nice to come up with some list of namespaces, and what they they should be used for...
For example, should it be: CONFIG_DRIVER_OMAP24XX_I2C or CONFIG_SYS_I2C_DRIVER_OMAP24XX or CONFIG_DRIVER_I2C_OMAP24XX
DRIVER is really un-nessary IMHO
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.
brake out of tree thinks is really not a problem I'll never consider out of tree thinks to be an obstacle to move on
we assumed that it was: CONFIG_DRIVER_NAND_BFIN
but it depends on who added it... CONFIG_PATA_BFIN
when you'll write Kconfig you will have something like this
config PATA_BFIN bool "Blackfing Pata driver" depend on BLACKFIN
drivers/block/Makefile:COBJS-$(CONFIG_PATA_BFIN) += pata_bfin.o include/configs/bf548-ezkit.h:#define CONFIG_PATA_BFIN
I would think should be CONFIG_DRIVERS_PATA_BFIN
too long at the end
Best Regards, J.
On Sat 18 Jul 2009 11:52, Jean-Christophe PLAGNIOL-VILLARD pondered:
On 11:15 Sat 18 Jul , Robin Getz wrote:
It doesn't appear very "system" oriented to me...
it's as we had reorganise the drivers file place as example or the common Makefile and continue to do it eveyday (take a look on Peter e-mail about arch dir)
It would be nice to come up with some list of namespaces, and what they they should be used for...
For example, should it be: CONFIG_DRIVER_OMAP24XX_I2C or CONFIG_SYS_I2C_DRIVER_OMAP24XX or CONFIG_DRIVER_I2C_OMAP24XX
DRIVER is really un-nessary IMHO
It doesn't cost extra $ to keep 6 letters - and makes it alot more clear about what it does.
I understand the point about having really _long_ names, and personally think things like "ThisVariableIsATemporaryCounter" are brain dead, but I don't think we have hit that yet with CONFIG_ yet.
We already have lots (419) that are over 30 chars, and some over 40!
40 CONFIG_SYS_TFTP_BLINK_STATUS_ON_DATA_IN 41 CONFIG_SYS_MONAHANS_TURBO_RUN_MODE_RATIO 41 CONFIG_SYS_MPC8220_SYSPLL_VCO_MULTIPLIER 42 CONFIG_SYS_PCI_SUBSYS_DEVICEID_NONMONARCH
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.
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.
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...
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.
I would think should be CONFIG_DRIVERS_PATA_BFIN
I dosagree, the "DRIVERS" part is just added line noise.
Best regards,
Wolfgang Denk
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
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
On Sat 18 Jul 2009 18:25, Wolfgang Denk pondered:
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 guess I still don't understand how you are making the distinction between "normal users" and "root" - I think there are more categories of users between those two...
People responsible for the archicture/CPU core may set things up, and not want anyone to change things - on any SoC or Board.
People responsible for SoC developments should be able to take what the arch provider delivers, write a few device drivers, make some specific choices that anyone who implements that SoC is going to have to live with.
People responsible for Board porting, should be able to take what the SoC provider delivers, customise things for their platform, and move on.
Then there are end users - which must live with the choices that all three have made, until they get their own hardware back, or in the case where the hardware is a module - just change some non-hardware related options.
So maybe it is core, chip, PCB, and user.
In some cases - all 4 categories are the same person - in many cases they are not.
Dear Robin Getz,
In message 200907192355.41601.rgetz@blackfin.uclinux.org you wrote:
People responsible for the archicture/CPU core may set things up, and not want anyone to change things - on any SoC or Board.
People responsible for SoC developments should be able to take what the arch provider delivers, write a few device drivers, make some specific choices that anyone who implements that SoC is going to have to live with.
People responsible for Board porting, should be able to take what the SoC provider delivers, customise things for their platform, and move on.
Then there are end users - which must live with the choices that all three have made, until they get their own hardware back, or in the case where the hardware is a module - just change some non-hardware related options.
So maybe it is core, chip, PCB, and user.
In some cases - all 4 categories are the same person - in many cases they are not.
You seem to live on a different planet than me.
Best regards,
Wolfgang Denk
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.
What about "DRV" or even "D" if you insist? CONFIG_D_I2C_SOFT ?
I personally find the config files pretty unreadable. Options that enable a driver should be different from those that select a behaviour, in my opinion.
While people responsible for their board know all the stuff they wrote, but when someone undergoes a more general code change several or all config files must be checked. A driver namespace would help, in my opionion.
/alessandro
Dear Alessandro Rubini,
In message 20090720080226.GA2463@mail.gnudd.com you wrote:
What about "DRV" or even "D" if you insist? CONFIG_D_I2C_SOFT ?
That's longer than needed, and nobody will understand what the "D_" stands for.
I personally find the config files pretty unreadable. Options that enable a driver should be different from those that select a behaviour, in my opinion.
So what do you think when you read "CONFIG_I2C_SOFT" ?
So many people here seem to take Linux as reference - why not here?
Does Linux use "CONFIG_DRIVER_E1000", "CONFIG_DRIVER_I2C", "CONFIG_DRIVER_IDE", "CONFIG_DRIVER_SCSI" or "CONFIG_DRIVER_SPI"?
No! Linux uses "CONFIG_E1000", "CONFIG_I2C", "CONFIG_IDE", "CONFIG_SCSI" and "CONFIG_SPI".
While people responsible for their board know all the stuff they wrote, but when someone undergoes a more general code change several or all config files must be checked. A driver namespace would help, in my opionion.
Linux has an order of magnitude more drivers than U-Boot, and they do well without this. We don't need this either.
Best regards,
Wolfgang Denk
Hello Wolfgang,
Wolfgang Denk wrote:
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.
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.
Agreed.
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...
I vote for CONFIG_I2C_xxx because we collect all i2c drivers in drivers/i2c without considering the plattform, so I think CONFIG_I2C_ represents better the code structure.
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.
I would think should be CONFIG_DRIVERS_PATA_BFIN
I dosagree, the "DRIVERS" part is just added line noise.
Yep.
bye Heiko
On Saturday 18 July 2009 07:03:38 Jean-Christophe PLAGNIOL-VILLARD wrote:
Hi all,
Currently we have a mess in the drivers CONFIG naming convention as example on I2C we have CONFIG_I2C_XXXXX CONFIG_DRIVER_XXX_I2C CONFIG_XXXX_I2C CONFIG_SYS_I2C_XXXX
I think it will good to have common and clean naming convention so I'll propose we use this one CONFIG_namespace_XXXXX and CONFIG_SYS_namespace_XXXXX
so it will resutly for I2C to this
CONFIG_I2C_XXXXX CONFIG_SYS_I2C_XXXX
and the Makefile and KConfig it will be easier to sort and read
are there really any guidelines on what "CONFIG_SYS_" is for ? i havent really figured out what "_SYS_" is supposed to indicate, so the new proposed naming is just as confusing imo. -mike
Dear Mike Frysinger,
In message 200907181456.20670.vapier@gentoo.org you wrote:
are there really any guidelines on what "CONFIG_SYS_" is for ? i havent really figured out what "_SYS_" is supposed to indicate, so the new proposed naming is just as confusing imo.
Actually there ARE guidelines; they are not perfect, but better than nothing.
It helps to read the README.
If you think this is insufficint and yoiu have better ideas, please post a patch.
Best regards,
Wolfgang Denk
participants (6)
-
Alessandro Rubini -
Heiko Schocher -
Jean-Christophe PLAGNIOL-VILLARD -
Mike Frysinger -
Robin Getz -
Wolfgang Denk