[syslinux] multiple comboot files?

[H. Peter Anvin]

Bryan E. Chafy wrote:
> Is there a way for isolinux/syslinux to execute a list of comboot files
> immediately at startup, and only once?

Not directly, no.

> Also, in my case some of these comboot files are ISRs, so they need to stay resident
> in some way, even just before transferring the IP to a kernel.
> (they work individually already, but just one at any given time and crash
> at the point when a kernel is loading into memory).
> Is there a way to ensure a loaded comboot file stays resident and
> the memory it uses wont get overwritten, for example even when loading a kernel
> or by yet another comboot file?
> If the comboot file could be instructed to load in a reserved high segment,
> or even just after the BDA, the
> available memory reported by the bios (INT 12 and INT 15 AX=E820h)
> could be reduced, but I dont know if this approach will work under syslinux.

That's pretty much what MEMDISK does -- it relocates itself to the very
end of DOS memory, and installs hooks into INT 12h and INT 15h.
However, you don't want to do that for each one for a bunch of different
files, you want to do it only once.

>>From the source, it looks like comboot_seg is 4000, right in the middle.
> 
> Also, related to the first question, if I want to disable one of my
> ISR's just before loading a kernel, I need to execute another smaller comboot
> file to restore the IVT and other hardware registers.
> When some action is exceuted, by say a keyword label, or default,
> I would like to be able to load that smaller comboot file, followed by
> the loading of the kernel, basically like above, but not at startup.

What you're really asking for is a scripting engine in syslinux.  It's a
common enough request, but it's unlikely to happen until I find time
enough to rewrite the UI functionality in C.

For now the only way to do this is to have your comboot file invoke the
next one instead of returning (via API function 0003h or similar.)

These ISRs aren't MS-DOS TSRs, are they?  If so, there is pretty much no
hope to get them to work; DOS TSRs load from the bottom up, whereas in a
pure BIOS environment you have to load from the top down.

	-hpa