lkml.org 
[lkml]   [2004]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/5] kbuild
On Tue, Jun 15, 2004 at 07:49:29PM +0200, Sam Ravnborg wrote:

> 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.

in the case where 'all' wasn't correct to start with. And i386 isn't
the convincing case here.

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

Honestly, I'm indifferent to this. This problem is equally, if not
better solved by documenting in the board-specific help "and use 'make
fooImage for foo firmware"

> - Other programs now have access to what kernel image has been built.
> This is needed when creating kernel packages like rpm.

I suppose this can clean up some of the globbing that might otherwise be
done, but I know for a fact that there's been kernel rpms before this :)

> 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.

This is where I see it blowing up, quite badly. As Russell noted,
you're going to have a horrible, unmaintainable list of boards and
firmware supported, or not, on each. Even on PPC32 where we really only
have "needs vmlinux, raw", "needs vmlinux, for U-Boot" and "can use
arch/ppc/boot/", it'll still get ugly noting which boards can use
U-Boot, which can use arch/ppc/boot/ and which can use both.

> But this trigger the discussion how much should actually be
> part of the kernel.

Yes, there's that another discussion, which at least I'm not talking
about right now. What I, and I think Russell as well, are noting is
that doing this is will make what we have in the kernel much uglier /
less maintainable.

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

\
 
 \ /
  Last update: 2005-03-22 14:03    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site