All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Sokolovsky <pmiscml@gmail.com>
To: Richard Purdie <rpurdie@rpsys.net>
Cc: openembedded-devel@lists.openembedded.org,
	angstrom-distro-devel@linuxtogo.org
Subject: Re: [Angstrom-devel] [RFC] Get rid of adhoc machine-specific messing with kernel packages
Date: Fri, 29 Dec 2006 04:05:45 +0200	[thread overview]
Message-ID: <1065634639.20061229040545@gmail.com> (raw)
In-Reply-To: <1167337946.5596.77.camel@localhost.localdomain>

Hello Richard,

Thursday, December 28, 2006, 10:32:26 PM, you wrote:

> On Thu, 2006-12-28 at 18:50 +0100, Koen Kooi wrote:
>> Paul Sokolovsky schreef:
>> > Hello angstrom-distro-devel,
>> > 
>> >   Thanks for providing pre-holiday 20061219 snapshots for testing.
>> > They don't provide separate zImages, but well, that's ok - they are in
>> > the images, after all.
>> > 
>> >   Well, not for hx4700, for example. Because:
>> > 
>> > ======== linux-handhelds-2.6.inc =====
>> > FILES_kernel-image_hx4700 = ""
>> > ALLOW_EMPTY_hx4700 = "1"
>> > FILES_kernel-image_htcuniversal = ""
>> > ALLOW_EMPTY_htcuniversal = "1"
>> > ======================================
>> > 
>> >   Oops. Sources of such a special treatment of hx4700 and htcuniversal
>> > would be unclear to outsider, but people who deal with (mis)features
>> > of "ipaqs" know, that hx4700 has one (sic!, even if the most popular)
>> > bootloader which doesn't use zImage in the image, but instead requires
>> > adhoc means to install kernel, ditto for Universal, though bootloader
>> > is another.
>> > 
>> >   So, what is tried here is to "save space". But there're few issues:
>> 
>> Those lines should go, but not before we have a way to exclude 'kernel-image' from the
>> rootfs *and* kernel-module-foo doesn't depend kernel-image anymore.

> The accepted approach is to make the kernel-image file empty which
> solves both those problems.

  Richard, is this response to Koen or to me? If to Koen, that's ok,
but my original mail (
http://lists.linuxtogo.org/pipermail/angstrom-distro-devel/2006-December/000058.html )
started with observation that there're few things wrong withe exactly
this approach.

> This is the same as the Zaurus which also
> requires an external zImage file (and this code is handled in
> linux-rp.inc in the same way as the above but for all machines).

  Well, looking into linux-rp.inc, it becomes clear what is actual
problem:

---------
# Compensate for sucky bootloader on all Sharp Zaurus models
#
FILES_kernel-image = ""
ALLOW_EMPTY = "1"
---------

  And PocketPC have exactly the same problem of having sucky
bootloaders. But I wouldn't like to accept that as the eternal state of
affairs, but tackle it to get some generic and reusable solution. The
path I see here is:

1) Stop issuing broken kernel-image packages which don't actually
have kernel image; instead, offer other means to achieve the
result of not having zImage in rootfs, for the cases when it is
needed.

2) Argue to Angstrom maintainers to stop killing zImage from rootfs at
all - consistently for all machines.

3) Move towards adopting 3-level bootloading with a tool like LAB (Linux as
Bootloader) with the following stages:
  a) 1st level bootloader bootstraps 2nd level bootloader out of NAND
  and such - in most cases supplied by device vendor.
  b) 2nd level bootloader boots LAB out of flash (what we have now is
  that 2nd level bootloader boots actual production kernel). 2nd level
  bootloader is vendor's stuff, or small bootloader like u-boot or
  HH.org bootldr.
  c) LAB, 3rd stage bootloader, boots actual kernel out of real
  rootfs, like it is usually done on standard desktop systems.


  Package management of the kernel is fully ensured. LAB, being
essentially a full Linux kernel itself, offers amazing capabilities
for diagnostics and recover in the case of problems - it can easily
boot from secondary storage, NFS, whatever.

  I already heard ideas in that direction from Koen, and well, knowing
that he worked on LAb himself, I assume he would have close picture in
mind to what's written above anyway.

  So, I'd like to start initial small steps in that direction. I don't
pledge for them to apply to anything else but PocketPC (hh.org)
devices, and just hope that Angstrom maintainers will support further
steps outlined above.

  Of course, it's clear that it's a case of common "choose 2 of 3"
compromise, but I really think that general-purpose distro like
Angstrom has good reasons to value "consist and general support across
all (many) devices" over "could hack a way to save a megabyte".

> Arguably, the machine files should perhaps set this...

  Well, in my initial days I was told many times what should be
within machine's discretion, and what's not, and I think I got idea
;-). So, I'd argue that distro config should set it for machines it
supports. This is based on the ideas outlined above - suckiness of
a bootloader is not unalienable property of machine, you can easily add
a 1Mb level to abstract away that suckiness. And in this regard, it is a
distro policy, if it wants to abstract away at some expense, or deal
with dirty details striving to save some space.

> The only other solution probably involves a nasty anonymous function
> acting on a setting of EXTERNAL_KERNEL_IMAGE = "1" in kernel.bbclass.

  The solution I propose,

ROOTFS_POSTPROCESS_COMMAND += "remove_zimages; "

is not nastier than what we already have and use.

> Richard



-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com




  reply	other threads:[~2006-12-29  2:06 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <53610736.20061228191750@gmail.com>
2006-12-28 17:50 ` [Angstrom-devel] [RFC] Get rid of adhoc machine-specific messing with kernel packages Koen Kooi
2006-12-28 20:32   ` Richard Purdie
2006-12-29  2:05     ` Paul Sokolovsky [this message]
2006-12-29 11:34       ` Richard Purdie
2007-01-04 19:03         ` [Angstrom-devel] [RFC] Get rid of adhoc machine-specific messing with [linux-handhelds-2.6] " Paul Sokolovsky
2007-01-04 20:55           ` Richard Purdie
2007-01-04 21:22             ` Koen Kooi
2007-01-04 21:33               ` Richard Purdie
2007-01-04 21:38             ` Paul Sokolovsky
2007-01-05  8:41           ` Marcin Juszkiewicz
2007-01-05  9:15             ` Koen Kooi
2007-01-05 10:15               ` pHilipp Zabel
2007-01-06 10:26             ` Paul Sokolovsky
2006-12-29  1:30   ` [Angstrom-devel] [RFC] Get rid of adhoc machine-specific messing with " Paul Sokolovsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1065634639.20061229040545@gmail.com \
    --to=pmiscml@gmail.com \
    --cc=angstrom-distro-devel@linuxtogo.org \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=rpurdie@rpsys.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.