[lkml]   [2013]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/6] kexec: A new system call to allow in kernel loading
On Fri, Nov 22, 2013 at 10:09:17AM +0100, Geert Uytterhoeven wrote:
> On Fri, Nov 22, 2013 at 2:55 AM, Vivek Goyal <> wrote:
> >> Before you are done we need an ELF loader. bzImage really is very
> >> uninteresting. To the point I am not at all convinced that an in kernel
> >> loader should support it.
> >
> > Hi Eric,
> >
> > Why ELF case is so interesting. I have not use kexec to boot ELF
> > images in years and have not seen others using it too. In fact bzImage
> > seems to be the most common kernel image format for x86, most of the distros
> > ship and use.
> >
> > So first I did the loader for the common use case. There is no reason
> > that one can't write another loader for ELF images. It just bloats
> > the code. Hence I thought that other image loaders can follow slowly. I am
> > not sure why do you say that bzImage is uninteresting.
> Welcome to the non-x86-centric world ;-)
> Looking at kexec-tools, all of arm, cris, i386, ia64, m68k, mips, ppc, ppc64,
> s390, sh, and x86_64 support ELF.

How many of them use ELF to boot in real world? Also one can easily
add ELF loader. I am just not able to see why ELF loader should be
a requirement for this patchset.

> Only arm, i386, ppc, ppc64, sh, and x86_64 support zImage.
> It's not clear to me what alpha supports (if it supports anything at all?).

Motiviation behind this patchset is secureboot. That is x86 specific
only and bzImage is most commonly used format on that platform. So it
makes sense to implement bzImage loader first, IMO.

One should be able to add support for more image loaders later as need
arises across different architectures.


 \ /
  Last update: 2013-11-22 15:01    [W:0.249 / U:0.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site