public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC] CONFIG naming convetion
Date: Sat, 18 Jul 2009 17:52:35 +0200	[thread overview]
Message-ID: <20090718155235.GG30699@game.jcrosoft.org> (raw)
In-Reply-To: <200907181115.26404.rgetz@blackfin.uclinux.org>

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.

  reply	other threads:[~2009-07-18 15:52 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-18 11:03 [U-Boot] [RFC] CONFIG naming convetion Jean-Christophe PLAGNIOL-VILLARD
2009-07-18 12:50 ` Wolfgang Denk
2009-07-18 13:05   ` Heiko Schocher
2009-07-18 14:48   ` Jean-Christophe PLAGNIOL-VILLARD
2009-07-18 17:33     ` Wolfgang Denk
2009-07-18 15:15 ` Robin Getz
2009-07-18 15:52   ` Jean-Christophe PLAGNIOL-VILLARD [this message]
2009-07-18 21:30     ` Robin Getz
2009-07-18 17:50   ` Wolfgang Denk
2009-07-18 21:13     ` Robin Getz
2009-07-18 22:25       ` Wolfgang Denk
2009-07-20  3:55         ` Robin Getz
2009-07-20 20:33           ` Wolfgang Denk
2009-07-21 15:59             ` Robin Getz
2009-07-20  8:02         ` Alessandro Rubini
2009-07-20 14:27           ` Wolfgang Denk
2009-07-19  5:54     ` Heiko Schocher
2009-07-18 18:56 ` Mike Frysinger
2009-07-18 19:08   ` Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090718155235.GG30699@game.jcrosoft.org \
    --to=plagnioj@jcrosoft.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox