[lkml]   [2004]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:03    [W:0.023 / U:1.332 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site