Making DragonFly Multiboot capable

[Radosław Szymczyszyn]

Hi,

[TL;DR]

As part of my Master's project I'm trying to tackle the problem of
making DragonFly BSD Multiboot capable.

Is this the right place to ask detailed questions regarding the
approach and implementation or maybe I should contact someone specific
directly? Then whom?

How to adjust the file offset (not LMA/VMA) of a specific section in
ELF image generated by ld?


[Long version]

Some facts about 32/64bit DFly and GRUB:

- GRUB doesn't support switching to 64bit Long Mode (in fact it does,
but not when booting Multiboot kernels). The Multiboot spec doesn't
cover 64bit OSs.
- DFly loader does.
- Long Mode requires paging - not (or hard to be?) OS agnostic.
- Patching GRUB DFly port to enter Long Mode just for DFly defeats the
purpose of having a common specification/API.
- `x86_64_tramp.S` is part of loader internal library `libi386`. GRUB
sets up a 32bit environment and execs the kernel which must then run
(almost?) the same code as the `x86_64_tramp.S` - redundancy.

Given all of the above, I've decided to go with i386 first to get my
feet wet and only continue with x86_64 if some reasonable approach is
found.

The first step to make a kernel identifiable as Multiboot compliant is
to embed the Multiboot header (MB header) in the first 8K bytes of the
image. That's when the problem arises.

I've (just started actually) edited `sys/platform/pc32/i386/locore.s`
to include a new path from boot by a Multiboot bootloader to calling
`mi_startup` and included the Multiboot header in the file. However,
the generated image contains that header quite late in the file, far
after the first 8K bytes.

To leverage that problem I've tried putting the MB header in its own
section and placing that at the beginning of the linker script.
Inspection of the ELF file shows that the LMA/VMA of this section are
just after `kernbase` - that's OK. However, the file offset is still
very far into the file contents and that's what needs to be lowered
for any MB compliant loader to recognize the image. Any pointers how
to deal with that?

I'd grateful for any advice in this matter. If you think my approach
is flawed, I'd like to know your point of view too.

Best regards,
Radek Szymczyszyn