[syslinux] comboot use cases

[Thorsten Glaser]

On Thu, 6 Nov 2014, Geert Stappers wrote:

> > The MirBSD bootloader actually took advantage of COMBOOT to
> > provide access to SYSLINUX storage and other things. It was
> > integrating nicely.
>
> Please tell more about that COMBOOT use case.

Okay.

The BSD kernels are normally loaded by their own BSD-specific
bootloaders (although some other bootloaders can, with sometimes
limited success, load them too). I hacked our bootloader to be
more flexibly usable – we have one binary that can be booted via
floppy, HDD, CD (El Torito or direct), under DOS, as Multiboot OS
Kernel (*ahem*, but it reverts to mostly-16-bit mode then), and
since DOS was already there, under SYSLINUX (and the others).

You boot a kernel by telling it the path, for example
	boot wd0a:/bsd
or	boot tftp:/bsd.rd
and, when booted from DOS or SYSLINUX, you can do
	boot c:/mirbsd/bsd
(and, in general, access paths the same as SYSLINUX does).

(When booted via Multiboot, it can also access the “modules”
passed from e.g. GNU GRUB2, as a virtual in-memory filesystem.)

Another benefit from running as COMBOOT module under SYSLINUX
is that it can ask SYSLINUX to reset the display to text mode,
which is something I have not found any documentation about how
to achieve in the vesamenu.c32 config file (there appears to be
no flag to say “return to text mode before booting this entry”).

It also plays nice with PXELINUX, “inheriting” the network stack.

(I don’t remember if I tested whether iPXE http works. Never
needed that yet.)

I could achieve most of this with memdisk, but that’s much less
flexible because it’d need filesystem images, not the bare files,
and has its own problems especially with large-ish images and/or
small-RAM machines (MirBSD targets sorta the low-end range).


On Thu, 6 Nov 2014, Gene Cumm wrote:

> Though not official, I can try to offer some insight.
[…]

Thanks, much welcome. This makes it more understandable. (Funnily
enough, due to the “joy” that GCC is when writing bootloaders, I’ve
moved more code *towards* being written in assembly. Well, more core
code anyway. New filesystem stuff is C obviously, and some of the
new device access stuff too, which just calls out to asm functions
internally, which do the basics.)

> I believe some reasons the COMBOOT functionality was not rewritten
> were a perceived low benefit for the likely large cost and time

Right – rewrites are always annoying, anyway.

> limits.  In my (unofficial) opinion, if it were reimplemented, it
> would be best as a library (ie libcbt.c32) which would eliminate the
> payload from the core and make it a little easier to only build for
> BIOS (the sole possible platform).

No idea if that can be done (I’d need to look at it more in-depth;
also, it lets the COMBOOT module run in 16-bit mode, which may also
no longer work), but that would be welcome.



Sorry for the previous rant. I was a bit annoyed having to debug
all of this on a system I’m not even the primary admin of, only
to run into a complete API break.

bye,
//mirabilos
-- 
>> Why don't you use JavaScript? I also don't like enabling JavaScript in
> Because I use lynx as browser.
+1
	-- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel