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

    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.021 / U:39.800 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site