Re: [Qemu-devel] [PATCH 0/4] Add multiboot support (x86) v2

[François Revol]

> >> The BIOS boot specification doesn't have any notion of command
> > > line
> >> AFAIK.
> >
> > Indeed, at least not the PC BIOS.
> > OF has the concept OTH... and QEMU does pass it through IIRC, and
> > Haiku
> > should be able to get it AFAIR.
> >
> > The idea would be to have it pass it anyway through a multiboot
> > frame.
> > It would them behave just as if the OS was booted by grub and args
> > had
> > been typed at boot time, as well as select the boot resolution.
>
> Why would an OS want to parse multiboot structures but not implement
> proper multiboot support? I mean, this really isn't anything
> complicated. When you have enabled it to understand multiboot
> structures
> you are only missing a handful of bytes for the multiboot header.
>
> What is it that you need to do differently for Haiku?

Because Haiku has its own second stage loader, which requires the BIOS
to locate the kernel and module in a BFS partition which grub doesn't
implement btw. It also handles PM switching by itself.
Haiku might also use the BIOS for other stuff, like VESA mode
switching, so I'd need to make sure all calls aren't strictly required.

IIRC someone proposed a patch to support multiboot in Haiku, but it
didn't get much interest.

The only way we could use multiboot without BIOS is with the tgz trick
(a tgz of kernel and modules located after the loader on the floppy
image, that is used for CD boot too, and for PXE, or by reading them
from a non BFS partition first.
But those ways require extra stuff besides the plain BFS partition, so
it complicates things for users.

I suppose I could still support it for special uses like the os zoo...
Then I could map -kernel to haiku_loader or an ELF version, and use -
initrd to pass the kernel tgz...

I started looking at adding BFS support to GRUB2, but of course until
it propagates to the existing installed base...

François.