Re: [PATCH 0/5] kbuild

[Sam Ravnborg]

On Tue, Jun 15, 2004 at 08:41:36AM -0700, Tom Rini wrote:
> On Mon, Jun 14, 2004 at 10:40:29PM +0200, Sam Ravnborg wrote:
> 
> > Hi Andrew. Here follows a number of kbuild patches.
> > 
> > The first replaces kbuild-specify-default-target-during-configuration.patch
> > 
> > They have seen ligiht testing here, but on the other hand the do not touch
> > any critical part of kbuild.
> > 
> > Patches:
> > 
> > default kernel image:		Specify default target at config
> > 				time rather then hardcode it.
> > 				Only enabled for i386 for now.
> 
> While I'd guess this is better than the patch it's replacing, given that
> most i386 kernels are 'bzImage', what's wrong with the current logic
> that picks out what to do for the all target now?

Compared to the original behaviour where the all: target picked the default
target for a given architecture, this patch adds the following:

- One has to select the default kernel image only once
  when configuring the kernel.
- There exist a possibility to add more than half a line of text
  describing individual targets. All relevant information can be
  specified in the help section in the Kconfig file
- Other programs now have access to what kernel image has been built.
  This is needed when creating kernel packages like rpm.

Where I see this really pay off is for architectures like MIPS with
at least four different targets, depending on selected config.
When one has selected to build a certain kernel, including a specific
bootloader only the make command is needed.
No need to remember the 'make rom.bin' or whatever target.

But this trigger the discussion how much should actually be
part of the kernel.
Building a kernel, storing it on target, and starting the kernel
should be a simple process.
>From this the current behaviour seems good:
$ make
$ copy image
$ reset the board (reset PC whatever)

If we remove the current support for for example uboot we create an
additional step in between the make and copy image.

What is the problem today is more the lack of infrastructure
support for different kernel images.
And this is where we should concentrate.

	Sam
-
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/