[syslinux] Proposal for Chain-Loadable LDLINUX.SYS
Gert Hulselmans
hulselmansgert at gmail.com
Mon Dec 31 13:02:07 PST 2012
A LDLINUX.SYS that confirms to the (a) multiboot specification might
be a possibiltity to consider.
The multiboot entry point can be a different one than the normal entry
point (e.g doesn't need to load
the rest of LDLINUX.SYS from disk).
- Gert
2012/12/31 Shao Miller <sha0.miller at gmail.com>:
> 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
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
>
More information about the Syslinux
mailing list