All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.