[syslinux] Proposal for Chain-Loadable LDLINUX.SYS

Shao Miller sha0.miller at gmail.com
Mon Dec 31 03:36:55 PST 2012


On 12/5/2012 19:38, Shao Miller wrote:
> A proposal for changing the LDLINUX.SYS layout and flow:
>
> The current situation ("old style"):
>
>    ldlinux.bin's physical layout:
>    - VBR
>    - 512 bytes of padding (never lands in memory)
>    - ldlinux.sys, which is:
>      - Sect1 code (494 bytes, leaving enough room for at least one
> extent, as planned)
>      - Extent pointer patch space (1920 bytes)
>      - The rest of the code
>
>    ldlinux.bin's in-memory layout:
>    - VBR @ 0:7C00 (or wherever else a crazy BIOS might put it)
>    - ldlinux.sys @ 0:8000
>      - Sect1 code @ 0:8000
>      - Extent pointers @ 0:81EE
>      - The rest of the code @ 0:896E
>
> Proposal for a future style:
>
>    ldlinux.bin == ldlinux.sys
>
>    ldlinux.sys' physical layout:
>    - Sect1 code
>    - Extent pointer patch space
>    - The rest of the old-style ldlinux.sys code
>    - 1024 bytes of Special Padding (you'll see why, later)
>    - New Special Code
>    - Padding to a 512-byte boundary
>    - VBR
>
>    ldlinux.sys' in-memory layout (unchanged from old style):
>    - VBR @ 0:7C00 (or wherever else a crazy BIOS might put it)
>    - ldlinux.sys @ 0:8000
>      - Sect1 code @ 0:8000
>      - Extent pointers @ 0:81EE
>      - The rest of the code @ 0:896E
>
> The goals are:
>
>    - That the installers wouldn't carry the VBR around as a separate
> blob, but could extract it from the end of the embedded ldlinux.sys,
> instead.
>
>    - Sect1 could check to see where the instruction pointer is.  If it
> is near 0:7C00, then some other boot-loader has loaded the whole
> ldlinux.sys there.  Because the whole file is loaded, jump to New
> Special Code.  If it is near 0:8000, then this is the usual load from
> the VBR; carry on as usual (no more discussion about the usual case).
>
>    - New Special Code only runs when the whole ldlinux.sys has been
> loaded into memory.  It shuffles down everything _before_ Special
> Padding from 0:7C00 (where some other boot-loader loaded all of
> ldlinux.sys) down to 0:8000 (where it's usually loaded by the VBR).
>
>    - Now Special Padding has been obliterated and New Special Code
> immediately follows the rest of the old-style ldlinux.sys code (not that
> it really matters, as long as New Special Code is not overwritten)
>
>    - New Special Code reads _the_actual_ disk VBR to 0:7C00, since
> everything's been shuffled down
>
>    - New Special Code patches 0:7C00 with the ldlinux.sys VBR code,
> leaving the FS data intact.  It then patches the VBR code to skip
> loading Sect1 from disk.  It also patches Sect1 to skip loading the rest
> of ldlinux.sys from disk.  (Sectors to load == 0)
>
>    - New Special Code then jumps into the VBR code.
>
>    - VBR code then does what it does except for loading Sect1, but still
> jumps to it.
>
>    - Sect1 then does what it does except for loading the rest of
> ldlinux.sys from disk.
>
>    - The rest of ldlinux.sys executes
>
> Does this make any sense as a possible way to chain-load ldlinux.sys
> from another boot-loader, without much risk of interfering with the
> current and common loaded-from-VBR flow?
>
> If my design makes sense, the only space needed from currently existing
> blobs would be for the new "check and possibly jump if we're at 0:7C00",
> in Sect1.
>
> The installers would obviously need to deal with a change in the layout
> of ldlinux.sys/ldlinux.bin
>
> I don't know if NASM allows for the VBR (which will live at 0:7C00) to
> come, in the binary file, physically after the usual ldlinux.sys code at
> 0:8000.
>
> I think a big win for this is that users don't need the installers for
> this...  Wherever they happen to find an ldlinux.sys (with these
> changes), it should be transferable to anywhere else.  Having a modified
> version means the two can be confused ("Well where did you get it from?
>   Did the installer make it?  Or is it renamed from the special one? ...")

Alternatively, the following three features could result in a useful 
chain-loadable Syslinux binary:
   - Multiple FS support (called "multi-disk"?).  This would remove the 
boot-from-FS limitation
   - CPIO "FS" support
   - Linux x86-format Syslinux binary

Then one could chain a "syslinux.lkrn" with a minimal "initrd" 
(CPIO/initramfs archive) containing some .c32s or whatever.

Maybe that'd work best?  What needs to happen to get the "multi-disk" 
GSoC work into Syslinux?  Some mailing-list review?  Or is it (review, 
merge, whatever) already assigned to a particular person's to-do list?

This e-mail prompted by reboot.pro forum members asking about 
chain-loading Syslinux from GRUB4DOS, etc.

- Shao Miller


More information about the Syslinux mailing list