Re: [CFT] kexec syscall for 2.5.43 (linux booting linux)

[Eric W. Biederman]

Kasper Dupont <[e-mail]> writes:

> "Eric W. Biederman" wrote:
> > 
> > I believe it is inappropriate to assume the interrupt
> > controller is going to be used by dos when it is shut down.
> 
> If Linux was booted by LILO or SYSLINUX, there will be no DOS
> in memory. But the BIOS interrupt vector table and other data
> structures are in the first physical memory page which is not
> touched by Linux, so I'd expect the BIOS to be usable if we
> can just leave the hardware in a usable state. Booting to DOS
> from Linux might actually be possible.

I agree.  To rephrase I believe it is inappropriate to assume a
classic x86 PCBIOS is present on the machine.

All the shutdown routines should do is to place the hardware in a
quiescent state, that the linux driver init code can recover from.
Since arbitrary code can be loaded leaving this policy to the users of
the kexec system call is reasonable. 

> OTOH if Linux was booted by LOADLIN, there will have been a
> DOS in memory. DOS has changed interrupt vectors to point to
> DOS own code in segment 0x70, but that code will be outside
> the first physical page and will thus have been overwritten
> by Linux. In this case neither DOS nor BIOS routines can be
> used reliable. Any INT instruction can potentially crash,
> this lead to problems with kmonte, does kexec have the same
> problem?

The system call does not.  My user space component needs a bit more
work to bypass setup.S and do a reasonable job at it.  I have all of
the code in a tested state except the code that queries the current
kernel for the BIOS setup information.

Getting the last pieces together so I can reliably boot a linux kernel
is the next step.  My user space started out as a proof of concept and
is evolving into something useful from there.  I refuse to use the
hack of copying the empty_zero_page from the old kernel to the new
kernel. 

Eric