[U-Boot] [RFC] CONFIG naming convetion

[U-Boot] [RFC] CONFIG naming convetion

[Jean-Christophe PLAGNIOL-VILLARD]

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.

[U-Boot] [RFC] CONFIG naming convetion

[Wolfgang Denk]

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

-- 
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: wd at denx.de
"At least they're __________EXPERIENCED incompetents"

[U-Boot] [RFC] CONFIG naming convetion

[Heiko Schocher]

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
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] [RFC] CONFIG naming convetion

[Jean-Christophe PLAGNIOL-VILLARD]

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.

[U-Boot] [RFC] CONFIG naming convetion

[Robin Getz]

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

?

[U-Boot] [RFC] CONFIG naming convetion

[Jean-Christophe PLAGNIOL-VILLARD]

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.

[U-Boot] [RFC] CONFIG naming convetion

[Wolfgang Denk]

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 at 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 at lists.denx.de

Proposal:
	...
	Received: from ns32433.ovh.net (HELO localhost)
	(plagnioj%jcrosoft.com at 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

-- 
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: wd at denx.de
"Look! There! Evil!.. pure and simple, total  evil  from  the  Eighth
Dimension!"                                         - Buckaroo Banzai

[U-Boot] [RFC] CONFIG naming convetion

[Wolfgang Denk]

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

-- 
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: wd at denx.de
Politician:  An  eel  in  the  fundamental   mud   upon   which   the
superstructure  of  organized  society is reared. When he wriggles he
mistakes the agitation of his tail for the trembling of the  edifice.
As  compared with the statesman, he suffers the disadvantage of being
alive.                                               - Ambrose Bierce

[U-Boot] [RFC] CONFIG naming convetion

[Mike Frysinger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090718/734999c1/attachment.pgp 

[U-Boot] [RFC] CONFIG naming convetion

[Wolfgang Denk]

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

-- 
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: wd at denx.de
The price of curiosity is a terminal experience.
                         - Terry Pratchett, _The Dark Side of the Sun_

[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@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

[U-Boot] [RFC] CONFIG naming convetion

[Robin Getz]

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

[U-Boot] [RFC] CONFIG naming convetion

[Wolfgang Denk]

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

-- 
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: wd at 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] [RFC] CONFIG naming convetion

[Heiko Schocher]

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
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] [RFC] CONFIG naming convetion

[Robin Getz]

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.

[U-Boot] [RFC] CONFIG naming convetion

[Alessandro Rubini]

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

[U-Boot] [RFC] CONFIG naming convetion

[Wolfgang Denk]

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

-- 
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: wd at denx.de
The more complex the mind, the greater the need for the simplicity of
play.
	-- Kirk, "Shore Leave", stardate 3025.8

[U-Boot] [RFC] CONFIG naming convetion

[Wolfgang Denk]

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

-- 
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: wd at denx.de
Any sufficiently advanced bug is indistinguishable from a feature.
                                                      - Rich Kulawiec

[U-Boot] [RFC] CONFIG naming convetion

[Robin Getz]

On Mon 20 Jul 2009 16:33, Wolfgang Denk pondered:
> Dear Robin Getz,

[snip]

> You seem to live on a different planet than me. 

That is a well though out point.