public inbox for linux-kbuild@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Tyser <ptyser@xes-inc.com>
To: Wolfgang Denk <wd@denx.de>
Cc: Grant Likely <grant.likely@secretlab.ca>,
	linuxppc-dev@ozlabs.org, linux-kbuild@vger.kernel.org
Subject: Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages
Date: Sun, 03 Jan 2010 17:52:46 -0600	[thread overview]
Message-ID: <4B412DCE.4030509@xes-inc.com> (raw)
In-Reply-To: <20100101104449.6DAC63F6FF@gemini.denx.de>

Hi Wolfgang,

> The "new" FIT image type should become the default, and old "legacy"
> images should only be generated upon special request (i. e. if some-
> one needs these for compatibility with an old, not yet FIT-aware
> version of the boot loader).

Agreed.

>> What do you think about changing the U-Boot documentation to rename
>> those 2 image types to:
>> 1 uImages
>> 2 FIT Images
>
> Let's make this "uImage.old" (or "uImage.legacy" similar) and
> "uImage", then.

I'm in favor of keeping the old uImage format/naming the same, and 
calling the new image format a FIT Image.  ie no mention of uImage for 
FIT images.

<snip>

>> uImages have to agree with U-Boot's header format defined in the U-Boot
>> source code, so the uImage name does make sense with respect to the
>> "legacy" uImages.
>
> Well, you can read "uImage" as "universal Image", which kind of fits
> the FIT approach :-)

I agree that the FIT image is a type of "universal Image", but I think 
"FIT image" is much more descriptive and accurate than "universal 
Image".  The FIT naming convention is designed to match device tree 
naming, which has lots of meaning.  eg:
   Flattened Device Tree (FDT) -> Flattened Image Tree (FIT)
   device tree source (.dts) -> image tree source (.its)
   device tree blob (.dtb) -> image tree blob (.itb)

>> My vote would be to make the Linux FIT target rule "fitImage" and then
>> update the U-Boot documentation to make obvious the differences between
>> uImages and FIT images.
>
> I think we should not try to support both legacy and FIT images on the
> same level - the idea is clearly that legacy images is the old, to be
> replaced format, while FIT images is the new, to be used as standard
> format.

Agreed.

In this sense I vote for using plain and simple "uImage" for
> the (new) standard format, and marking the old format by some ".old"
> or ".legacy" suffix.

I disagree here.  I don't think calling FIT images "FIT uImages" adds 
much value and it would add confusion as there are now multiple uImage 
formats that a user needs to keep straight.  Keeping the legacy uImage 
naming/format the same, and calling the new FIT images "fitImage" (or 
possibly itbImage to line up with the dtbImage target) would make more 
sense to me.  Is there a compelling reason to keep the uImage word 
connected to FIT images?

Best,
Peter

  parent reply	other threads:[~2010-01-04  0:54 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-22  1:50 [PATCH v2 0/3] powerpc: Add support for FIT uImages Peter Tyser
2009-12-22  1:50 ` [PATCH v2 1/3] powerpc: Use scripts/mkuboot.sh instead of 'mkimage' Peter Tyser
2009-12-30 22:25   ` Grant Likely
2009-12-22  1:50 ` [PATCH v2 2/3] powerpc: Add support for creating FIT uImages Peter Tyser
2009-12-22  3:48   ` Olof Johansson
2009-12-22  4:50     ` Peter Tyser
2009-12-30 22:57   ` Grant Likely
2010-01-01 14:18     ` Wolfgang Denk
2010-01-03  5:23       ` Grant Likely
2009-12-22  1:50 ` [PATCH v2 3/3] powerpc: Add support for ram filesystems in " Peter Tyser
2009-12-30 23:02   ` Grant Likely
2009-12-30 23:39     ` Peter Tyser
2009-12-31  0:01       ` Grant Likely
2009-12-31  1:10         ` Peter Tyser
2010-01-03  5:08           ` [U-Boot] " Grant Likely
2010-01-03 10:10             ` Wolfgang Denk
2010-01-04  1:07               ` Peter Tyser
2010-01-04  8:27               ` Grant Likely
2009-12-31  8:01         ` Peter Korsgaard
2010-01-01 14:12         ` Wolfgang Denk
2010-01-03  5:18           ` Grant Likely
2010-01-03 10:15             ` Wolfgang Denk
2009-12-31 22:44     ` Wolfgang Denk
2009-12-31 23:10       ` Peter Tyser
2010-01-01 10:44         ` Wolfgang Denk
2010-01-03  5:13           ` Grant Likely
2010-01-03 10:12             ` Wolfgang Denk
2010-01-03  8:06           ` Peter Korsgaard
2010-01-03  9:50             ` Wolfgang Denk
2010-01-03 14:27               ` Peter Korsgaard
2010-01-04  8:34                 ` Grant Likely
2010-01-03 23:52           ` Peter Tyser [this message]
2010-01-03  5:10       ` Grant Likely

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=4B412DCE.4030509@xes-inc.com \
    --to=ptyser@xes-inc.com \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=wd@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