All of lore.kernel.org
 help / color / mirror / Atom feed
From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] a couple questions about CONFIG_SYS_LONGHELP
Date: Sat, 26 Jan 2013 12:45:42 +0100	[thread overview]
Message-ID: <20130126124542.5645cb9b@lilith> (raw)
In-Reply-To: <alpine.DEB.2.02.1301260633410.21951@oneiric>

Hi Robert,

On Sat, 26 Jan 2013 06:38:51 -0500 (EST), "Robert P. J. Day"
<rpjday@crashcourse.ca> wrote:

> 
>   first, is there any need for so many header files to define the
> macro CONFIG_SYS_LONGHELP individually?  a quick count of how many
> u-boot source files do just that:
> 
> $ grep -r "define.*CONFIG_SYS_LONGHELP" * | wc -l
> 479
> $
> 
> is it really necessary for almost 500 source files to each define that
> macro?

Yes, is is, because each target should decide individually if they want
to embed the long help, which costs space and time, two valuable
resources in embedded development.

>   and second, i'm not sure how to read this out of cmd_pci.c:
> 
> ===== start
> 
> #ifdef CONFIG_SYS_LONGHELP
> static char pci_help_text[] =
>         "[bus] [long]\n"
>         "    - short or long list of PCI devices on bus 'bus'\n"
> #ifdef CONFIG_CMD_PCI_ENUM
>         "pci enum\n"
>         "    - re-enumerate PCI buses\n"
> #endif
>         "pci header b.d.f\n"
>         "    - show header of PCI device 'bus.device.function'\n"
>         "pci display[.b, .w, .l] b.d.f [address] [# of objects]\n"
>         "    - display PCI configuration space (CFG)\n"
>         "pci next[.b, .w, .l] b.d.f address\n"
>         "    - modify, read and keep CFG address\n"
>         "pci modify[.b, .w, .l] b.d.f address\n"
>         "    -  modify, auto increment CFG address\n"
>         "pci write[.b, .w, .l] b.d.f address value\n"
>         "    - write to CFG address";
> #endif
> 
> U_BOOT_CMD(
>         pci,    5,      1,      do_pci,
>         "list and access PCI Configuration Space", pci_help_text
> );
> 
> ===== end
> 
>   note how, if CONFIG_SYS_LONGHELP is defined, the symbol
> "pci_help_text" is created as the text, but its *usage* just below in
> the U_BOOT_CMD macro is *outside* of that preprocessor check.  how
> would that work if CONFIG_SYS_LONGHELP is undefined?  not at my dev
> host right this minute so i can't test, but it just looks ... weird.

Probably would not work. Submit a fix. :)

> rday

Amicalement,
-- 
Albert.

  reply	other threads:[~2013-01-26 11:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-26 11:38 [U-Boot] a couple questions about CONFIG_SYS_LONGHELP Robert P. J. Day
2013-01-26 11:45 ` Albert ARIBAUD [this message]
2013-01-26 12:11   ` Robert P. J. Day
2013-01-26 12:27     ` Albert ARIBAUD
2013-01-26 12:37       ` Robert P. J. Day
2013-01-26 15:55         ` Albert ARIBAUD

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=20130126124542.5645cb9b@lilith \
    --to=albert.u.boot@aribaud.net \
    --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.