From: "Robert P. J. Day" <rpjday@crashcourse.ca>
To: "U-Boot Version 2 (barebox)" <barebox@lists.infradead.org>
Subject: can someone explain this CONFIG_COMMANDS, CFG_CMD thing?
Date: Mon, 21 Dec 2009 09:56:07 -0500 (EST) [thread overview]
Message-ID: <alpine.LFD.2.00.0912210947530.18397@localhost> (raw)
i'm looking at some of the stuff sascha commented on earlier, like:
$ grep -r CONFIG_MII drivers
drivers/net/Makefile:obj-$(CONFIG_MIIPHY) += miiphy.o
drivers/net/at91_ether.c:#if defined(CONFIG_MII) || (CONFIG_COMMANDS & CFG_CMD_MII)
drivers/net/at91_ether.c:#endif /* defined(CONFIG_MII) || (CONFIG_COMMANDS & CFG_CMD_MII) */
drivers/net/at91_ether.c:#if defined(CONFIG_MII) || (CONFIG_COMMANDS & CFG_CMD_MII)
$
and i'd like to clarify what any of that is *supposed* to mean.
first, what means "CONFIG_COMMANDS"? that is, in the sense that
you're *bitwise* or'ing it with something else? is that supposed to
be a test that a command has been selected for inclusion? surely
there's a cleaner way to do that.
and what would the difference be between CONFIG_MII and CFG_CMD_MII?
as i read it (and i could be totally out to lunch), something like
CONFIG_MII would be selecting a particular *feature* to build in,
while CFG_CMD_MII would be selecting the actual "mii" command, is that
it?
but should those two selections be independently selectable?
possibly -- i can imagine an argument that that should be true. but
in a perfect world, how should all this be done? personally, i can
imagine selecting *features* one by one and, for each feature,
selecting any of the relevant and associated commands.
so (as a random example), i might first select MII support with
CONFIG_MII, then separately select to include the "mii" command with
CONFIG_CMD_MII. and commands should be Kconfig dependent on their
associated feature, so that there would be no need to test
#if defined(CONFIG_MII) && defined(CONFIG_CMD_MII)
it would be sufficient to test
#if defined(CONFIG_CMD_MII)
or am i completely misreading what should be happening here?
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
========================================================================
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next reply other threads:[~2009-12-21 14:56 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-21 14:56 Robert P. J. Day [this message]
2009-12-21 16:23 ` can someone explain this CONFIG_COMMANDS, CFG_CMD thing? Sascha Hauer
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=alpine.LFD.2.00.0912210947530.18397@localhost \
--to=rpjday@crashcourse.ca \
--cc=barebox@lists.infradead.org \
/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.