* "Hearty AOL" for kexec
@ 2002-10-23 13:47 Pavel Roskin
2002-10-23 15:03 ` Eric W. Biederman
0 siblings, 1 reply; 6+ messages in thread
From: Pavel Roskin @ 2002-10-23 13:47 UTC (permalink / raw)
To: linux-kernel, Eric Biederman
Hello!
I have tested the latest kexec patch (linux-2.5.44.x86kexec.diff) with
the kernel 2.5.44. It works for me on AOpen AK-33 motherboard with 1GHz
Athlon. I tried the same kernel and 2.4.20-pre10.
I really want to see this feature in the kernel. It is very useful in
embedded systems. Just imagine loading the bootstrap kernel, then
downloading the new kernel over anything - HDLC, 802.11, USB, decrypting
it from flash etc. Possibilities are infinite.
Believe me, this code is needed, and there will be kernel hackers using
it, so if anything needs fixing, it will be fixed by people who know to
fix it. It will be more an asset than a responsibility for the kernel
maintainers.
That said, I don't like the name kexec, and especially the work "execing"
in arch/i386/config.in. I think "in-kernel bootloader" or something like
that would be better. It is a reboot after all.
Little fix: there is no need to add kexec.o twice to obj-$(CONFIG_KEXEC)
in kernel/Makefile - it causes rebuilding kexec.o on every make. One time
is enough.
Little bug (missing feature): I cannot execute memtest.bin
(http://www.memtest86.com/):
./kexec /boot/memtest.bin
read error: Success
Cannot determine the file type of /boot/memtest.bin
I'm using kexec-tools-1.2. The rest of the system is Red Hat 8.0.
--
Regards,
Pavel Roskin
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: "Hearty AOL" for kexec
2002-10-23 13:47 "Hearty AOL" for kexec Pavel Roskin
@ 2002-10-23 15:03 ` Eric W. Biederman
2002-10-23 16:58 ` Torrey Hoffman
0 siblings, 1 reply; 6+ messages in thread
From: Eric W. Biederman @ 2002-10-23 15:03 UTC (permalink / raw)
To: Pavel Roskin; +Cc: linux-kernel
Pavel Roskin <proski@gnu.org> writes:
> Hello!
>
> I have tested the latest kexec patch (linux-2.5.44.x86kexec.diff) with
> the kernel 2.5.44. It works for me on AOpen AK-33 motherboard with 1GHz
> Athlon. I tried the same kernel and 2.4.20-pre10.
>
> I really want to see this feature in the kernel. It is very useful in
> embedded systems. Just imagine loading the bootstrap kernel, then
> downloading the new kernel over anything - HDLC, 802.11, USB, decrypting
> it from flash etc. Possibilities are infinite.
Yay!!!! My first embedded developer who doesn't think it is silly to
use a kernel as a bootloader :) Or at least the first to admit they
embedded developer.
I need to brush it off but I have a 16K user space that implements a
standard DHCP/TFTP network bootloader. 16K == sizeof(initrd)
> Believe me, this code is needed, and there will be kernel hackers using
> it, so if anything needs fixing, it will be fixed by people who know to
> fix it. It will be more an asset than a responsibility for the kernel
> maintainers.
>
> That said, I don't like the name kexec, and especially the work "execing"
> in arch/i386/config.in. I think "in-kernel bootloader" or something like
> that would be better. It is a reboot after all.
It is basically a kernel level exec system call.
But I will see if I can come up with better wording for arch/i386/config.in.
A mass renaming would probably be a hindrance at this point, unless I
see a name that really screams that it is the perfect name.
> Little fix: there is no need to add kexec.o twice to obj-$(CONFIG_KEXEC)
> in kernel/Makefile - it causes rebuilding kexec.o on every make. One time
> is enough.
Oh, thanks. When I updated my patch at some point that line must have
doubled.
> Little bug (missing feature): I cannot execute memtest.bin
> (http://www.memtest86.com/):
>
> ./kexec /boot/memtest.bin
> read error: Success
> Cannot determine the file type of /boot/memtest.bin
Sorry to be clear:
./kexec memtest
is the case that is expected to work.
My user space code currently understands two images formats.
bzImage 2.0 or greater and static ELF executables. So you need
the memtest86 static ELF executable.
> I'm using kexec-tools-1.2. The rest of the system is Red Hat 8.0.
Thanks for the success report.
Eric
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: "Hearty AOL" for kexec
2002-10-23 15:03 ` Eric W. Biederman
@ 2002-10-23 16:58 ` Torrey Hoffman
2002-10-23 17:31 ` Richard B. Johnson
0 siblings, 1 reply; 6+ messages in thread
From: Torrey Hoffman @ 2002-10-23 16:58 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Pavel Roskin, Linux Kernel
On Wed, 2002-10-23 at 08:03, Eric W. Biederman wrote:
> Pavel Roskin <proski@gnu.org> writes:
[...]
> > I really want to see this feature in the kernel. It is very useful in
> > embedded systems. Just imagine loading the bootstrap kernel, then
> > downloading the new kernel over anything - HDLC, 802.11, USB, decrypting
> > it from flash etc. Possibilities are infinite.
>
> Yay!!!! My first embedded developer who doesn't think it is silly to
> use a kernel as a bootloader :) Or at least the first to admit they
> embedded developer.
Yeah, another AOL "Me Too" here - I'm an embedded linux developer and
think would be useful. Being able to network boot the device, download
software to a flash, and then directly "kexec" boot from the kernel on
the flash would be nice.
Anything that reduces dependencies on the BIOS is good. I'd use this
feature if it was available.
Torrey Hoffman
thoffman@arnor.net
torrey.hoffman@myrio.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: "Hearty AOL" for kexec
2002-10-23 16:58 ` Torrey Hoffman
@ 2002-10-23 17:31 ` Richard B. Johnson
2002-10-23 17:43 ` Torrey Hoffman
2002-10-23 18:29 ` Pavel Roskin
0 siblings, 2 replies; 6+ messages in thread
From: Richard B. Johnson @ 2002-10-23 17:31 UTC (permalink / raw)
To: Torrey Hoffman; +Cc: Eric W. Biederman, Pavel Roskin, Linux Kernel
On 23 Oct 2002, Torrey Hoffman wrote:
> On Wed, 2002-10-23 at 08:03, Eric W. Biederman wrote:
> > Pavel Roskin <proski@gnu.org> writes:
> [...]
> > > I really want to see this feature in the kernel. It is very useful in
> > > embedded systems. Just imagine loading the bootstrap kernel, then
> > > downloading the new kernel over anything - HDLC, 802.11, USB, decrypting
> > > it from flash etc. Possibilities are infinite.
> >
> > Yay!!!! My first embedded developer who doesn't think it is silly to
> > use a kernel as a bootloader :) Or at least the first to admit they
> > embedded developer.
>
> Yeah, another AOL "Me Too" here - I'm an embedded linux developer and
> think would be useful. Being able to network boot the device, download
> software to a flash, and then directly "kexec" boot from the kernel on
> the flash would be nice.
>
> Anything that reduces dependencies on the BIOS is good. I'd use this
> feature if it was available.
But 'downloading' (actually uploading) software and writing it to
flash for a re-boot is a trivial user-mode task. The actual boot
from such a virtual disk takes 4 seconds on a real system (AMD SC520)
processor in an embedded system. You don't need any special kernel
hooks.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Bush : The Fourth Reich of America
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: "Hearty AOL" for kexec
2002-10-23 17:31 ` Richard B. Johnson
@ 2002-10-23 17:43 ` Torrey Hoffman
2002-10-23 18:29 ` Pavel Roskin
1 sibling, 0 replies; 6+ messages in thread
From: Torrey Hoffman @ 2002-10-23 17:43 UTC (permalink / raw)
To: root; +Cc: Eric W. Biederman, Pavel Roskin, Linux Kernel
On Wed, 2002-10-23 at 10:31, Richard B. Johnson wrote:
> On 23 Oct 2002, Torrey Hoffman wrote:
>
> > On Wed, 2002-10-23 at 08:03, Eric W. Biederman wrote:
> > > Pavel Roskin <proski@gnu.org> writes:
> > [...]
> > > > I really want to see this feature in the kernel. It is very useful in
> > > > embedded systems. Just imagine loading the bootstrap kernel, then
> > > > downloading the new kernel over anything - HDLC, 802.11, USB, decrypting
> > > > it from flash etc. Possibilities are infinite.
> > >
> > > Yay!!!! My first embedded developer who doesn't think it is silly to
> > > use a kernel as a bootloader :) Or at least the first to admit they
> > > embedded developer.
> >
> > Yeah, another AOL "Me Too" here - I'm an embedded linux developer and
> > think would be useful. Being able to network boot the device, download
> > software to a flash, and then directly "kexec" boot from the kernel on
> > the flash would be nice.
> >
> > Anything that reduces dependencies on the BIOS is good. I'd use this
> > feature if it was available.
>
> But 'downloading' (actually uploading) software and writing it to
> flash for a re-boot is a trivial user-mode task. The actual boot
> from such a virtual disk takes 4 seconds on a real system (AMD SC520)
> processor in an embedded system. You don't need any special kernel
> hooks.
Sure - once I've written the new software into the flash I can just
reboot normally. That's what I do now, it works, it's simple.
But on the devices we use, that requires an extra, unnecessary startup
delay of least 15 seconds as the BIOS does all the usual, PC-style
system startup. And it depends on the BIOS correctly determining that
it should boot from flash instead of the network.
Using "kexec" to go directly from setting up the flash to booting from
it would cut our system startup time in half and reduce BIOS dependency.
Not a big deal, but it would be nice.
Torrey Hoffman
thoffman@arnor.net
torrey.hoffman@myrio.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: "Hearty AOL" for kexec
2002-10-23 17:31 ` Richard B. Johnson
2002-10-23 17:43 ` Torrey Hoffman
@ 2002-10-23 18:29 ` Pavel Roskin
1 sibling, 0 replies; 6+ messages in thread
From: Pavel Roskin @ 2002-10-23 18:29 UTC (permalink / raw)
To: Richard B. Johnson; +Cc: Torrey Hoffman, Eric W. Biederman, Linux Kernel
> > Anything that reduces dependencies on the BIOS is good. I'd use this
> > feature if it was available.
>
> But 'downloading' (actually uploading) software and writing it to flash
> for a re-boot is a trivial user-mode task. The actual boot from such a
> virtual disk takes 4 seconds on a real system (AMD SC520) processor in
> an embedded system. You don't need any special kernel hooks.
The flashing can be trivial, but downloading and verification of the
software is not. One of the systems I was working on required synchronous
PPP protocol and HDLC drivers to load the kernel. The network was
untrusted, so checking the signature of the kernel was a very good idea.
None of that functionality was required for normal operation. In fact, it
was preferred to disable any network protocols on the working nodes.
By the way, kexec makes it possible to avoid any write operations. The
bootstrap kernel can be in the true ROM (not PROM), the secondary kernel
can be loaded into the RAM.
Finally, I'm subscribed to the GNU GRUB mailing list, and it's quite
common to see people trying to boot their systems over 802.11 or something
like that, not to mention problems with large hard drives and USB
keyboards. kexec makes it possible to implement a bootloader with full
BIOS-independent support for USB keyboards and drives, IDE, SCSI and
everything else, even fancy animated logos on the framebuffer.
--
Regards,
Pavel Roskin
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2002-10-23 18:23 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-10-23 13:47 "Hearty AOL" for kexec Pavel Roskin
2002-10-23 15:03 ` Eric W. Biederman
2002-10-23 16:58 ` Torrey Hoffman
2002-10-23 17:31 ` Richard B. Johnson
2002-10-23 17:43 ` Torrey Hoffman
2002-10-23 18:29 ` Pavel Roskin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox