[syslinux] Proposal for Chain-Loadable LDLINUX.SYS

Shao Miller sha0.miller at gmail.com
Wed Jan 2 10:20:22 PST 2013


On 1/2/2013 12:32, Bernd Blaauw wrote:
> Op 2-1-2013 3:32, Shao Miller schreef:
>
>> Time to review the (a) multiboot specification, anyway.  Thanks. :)
>
> ReactOS' FreeLDR bootloader/bootmanager might be a succesfull reference
> implementation of combined multiboot and legacy loading.
>

Actually, they've done some back-and-forth.  One of the formats it took 
(I can't remember which) was prompted by some IRC discussion, at one point.

Fortunately the specification actually includes reference code, but 
since it's FSF, I'd guess that GRUB would also be useful as a reference 
implementation.  Also fortunately, I doubt ldlinux.sys will have to care 
too much about all the fancier stuff, since it's pretty self-contained.

>
> I'm not sure what the spec says about finding config files though.
> Behaviour is:
>
> [1] bootsector -> A:\FREELDR.SYS -> A:\FREELDR.INI
> [2] bootsector -> A:\LDLINUX.SYS -> A:\SYSLINUX.CFG -> A:\MBOOT.C32 ->
>    A:\FREELDR.SYS -> C:\FREELDR.INI (doesn't search original bootdisk)
>
> 2nd case is quite annoying when C: doesn't contain the config file or
> you have a modified version on floppy.
>

The multiboot kernel can accept a boot disk notification from the 
boot-loader, but perhaps FreeLdr doesn't use it, or perhaps there's a 
bug somewhere...  This almost rings a bell as familiar discussion for 
mboot.c32...  I'm pretty sure Gert Hulselmans has thought about this 
stuff before.

> Benefit though of the multiboot style is gz-compression support, thus
> reducing size of the kernel binary on disk.

If we want ldlinux.sys to continue to work with the VBR code, any 
decompression support would also have to be present and available pretty 
early, I think.

On 1/2/2013 12:42, Bernd Blaauw wrote:
> Op 2-1-2013 12:15, Shao Miller schreef:
>
>> Just for fun, maybe it'd be neat to leave room for some possible future
>> hybridization in ldlinux.sys, such as:
>> - Current style
>> - Multiboot (thinking about tackling this)
>> - Linux x86 kernel-format
>> - DOS .EXE
>
> UPX executable binary compression support while at it (with leaving everything else mentioned intact).
> Then again, current core is tiny already. Something that would more benefit from that is some variant of GRUB.
>
> I think Eric Auer once wrote some kind of DOS-loader for Memtest+ including compression support.
>

(Compression mentioned above, too.)

>> Although launching from DOS could obviously have complications from DOS
>> hooks, TSRs, and a generally stale device state, plus .sys isn't .exe,
>> so'd have to be renamed unless launched from config.sys (so why bother).
>
> Don't suppose you'd favor changing the extension by default to .EXE hehe.

On the one hand, this'd be a change after years of users being used to 
ldlinux.sys.  On the other hand, they do have to worry about ldlinux.c32 
now, so perhaps it's the right time, if there's going to be such a time. :)

> Clean-boot is still possible in most DOS flavors.
>

I didn't know that.  I think hpa has mentioned a preference against this 
before, but I could be misremembering.  I also seem to recall that 
GRUB4DOS's GRUB.EXE was somehow able to restore the IVT to a post-POST 
state, but I could be misremembering that, too.

> If you want a real challenge, make the binary EFI-bootable as well
> (without legacy SMBIOS fallback/compatibility layer). SecureBoot support optional..

Well Syslinux 6.00 has a (U)EFI binary.  I'd have to review if PE 
conflicts with Linux x86 kernel-format.

- Shao Miller


More information about the Syslinux mailing list