Eric W. Biederman wrote:
> There are a couple of differences.
> But the big one is I'm trying to do it right.
So why do you need a file-based interface then ? ;-)
Since this is a highly privileged operation anyway, you may as
well trust user space to use the right data format ...
I get the impression that you incur quite a lot of overhead just
to make it fit with the exec interface. I agree that it's
conceptually nice, and it looks cleanly done, but I don't quite
see the practical value. (Except, perhaps, that this allowed you
to pick the rather cute name "kexec" ;-)
> Additionally mine is the only one that has a real chance of booting
> a non-linux kernel.
Hmm, I think all approaches could boot a non-Linux kernel, but ...
As far as loading is concerned, bootimg probably has an advantage
there, because you can put things together in memory (e.g. some
OS-specific chain loader), without going to secondary storage.
(Proof of concept: bootimg is able to load all currently supported
kernel image formats on ia32.)
As far as execution is concerned, you're probably slightly better
off with an approach that goes back to real mode. (Or use a chain
loader - this can be transparent to the kernel.) But then, I'm not
sure if you can re-animate the BIOS in any consistent way, so your
choice of operating systems may be quite limited, or you have to
provide your own BIOS substitute.
Concerning complexity, you don't need to use assembler for the
copying (arch/i386/kernel/relocate_kernel.S), see bootimg,
kernel/bootimg_pic.c
Also, why did you implement your own memory management in
fs/kexec.c:kimage_get_chunk ?
- Werner
-- _________________________________________________________________________ / Werner Almesberger, ICA, EPFL, CH Werner.Almesberger@epfl.ch / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Nov 15 2000 - 21:00:25 EST