Re: [RFC,PATCH] scripts/package: add powerpc images to tarball

From: Milton Miller
Date: Sat Jul 26 2008 - 13:20:49 EST


On Jul 25, 2008, at 11:55 PM, Grant Likely wrote:
On Thu, Jul 24, 2008 at 9:08 PM, Milton Miller <miltonm@xxxxxxx> wrote:
Add support for powerpc builds in the buildtar script, to include
a few default images.
---
RFC: any requests for more/less boot images?
..
+ for img in zImage zImage.pseries zImage.iseries \
+ dtbImage dtbImage.ps3

Yes. How about all dtbImage, zImage, cuboot, treeboot, etc
that are newer than vmlinux?

dtbImage is not a buildable image. Neither is cuImage, treeImage or
simpleImage. All of those targets embed a device tree which is
specified by adding the .dts filename to the target name.

I intended "all dtbImage" as a wildcard for dtbImage.*, etc.

so, for example, 'make cuImage' fails. Instead you do 'make
cuImage.lite5200b' which pulls in dts/lite5200b.dts.

The user does make zImage which makes cuImage.lite5200b based on Kconfig. Or it was that way until your change in 2.6.25 to allow the later, but they can still do the former.

Hmm, we really need to fix our calls to make boot images with make -j. Something for my todo list.

Also, zImage is a 'meta' target that builds all the default image
targets (the $image-y list). The zImage is actually just a symlink to
the first file in the list of default images. So zImage can actually
point to any kind of kernel image depending on how the kernel is
configured. I wonder if we should just remove the zImage file
entirely, or at least make it always linked to one particular image
type.

I think its fine as it is. It says "make what is configured" that lets cross-platform building scripts be dumb and not need to know specificially what image makes sense to make. Perhaps we should make it default to our additional target in Kconfig if specified, this allowing the user to specify which version he gets.

milton

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/