Messages in this thread | | | Date | Mon, 13 Mar 2000 16:56:11 +0100 | From | almesber@lrc ... | Subject | bootimg: 2.4 or later ? |
| |
[ Copied to linux-kernel ]
Hi Linus,
maybe you've already seen the bootimg system call and framework that I've been working on recently. The idea is to let a Linux kernel load another Linux kernel (and initrd, etc.), and then to boot it. My latest version is on
ftp://icaftp.epfl.ch/pub/people/almesber/misc/bootimg-8.tar.gz
bootimg has the following uses:
- allows booting from media hard to support using traditional boot loaders (e.g. RAID, NFS, disk disabled in BIOS, etc.) - for many "advanced" features, it provides a single point of implementation instead of once per boot loader over all architectures - allows people to implement fancy boot procedures (e.g. mpegs of dancing penguins, with voice recognition for kernel selection) - should be useful for projects that put Linux into (EP)ROM, e.g. linuxbios - makes reboot even faster ;-)
Of course there are also some drawbacks:
- doesn't help people with very tight storage constraints - will trip over devices that don't do a full reset on initialization (1) - not ported beyond the i386 architecture yet (2)
(1) Right now, there is one known problem in the area: as of 2.3.48, SMP systems seem to reset interrupts only partially, so the system hangs after bootimg(2), waiting for interrupts that don't arrive. It also shows up occasionally on UP. (Of course, I only have UP, so I only see a problem every 10-50 reboots :-( ) (2) I'm confident that it will work well on ARM - half of the concept is adapted from the linux-7110 boot code)
Now my question is if I should work towards getting this ready for inclusion in 2.4 ? There's a bit of cleanup left to do, and the interrupts bug needs to be fixed. All this shouldn't take more than 0.5-2 weeks.
At the moment, the cases where people actually require bootimg to solve a specific problem seem to be few. On the other hand, I see a tendency towards more complex boot setups, so something like bootimg may become necessary sooner than we like.
Please let me know what you think.
Cheers, Werner
-- _________________________________________________________________________ / Werner Almesberger, ICA, EPFL, CH werner.almesberger@ica.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.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |