I use a Custom Filesystem - What Bootloader Solution is right for me?: Difference between revisions

m
Bot: Replace deprecated source tag with syntaxhighlight
[unchecked revision][unchecked revision]
m (Bot: Replace deprecated source tag with syntaxhighlight)
 
(2 intermediate revisions by 2 users not shown)
Line 36:
To load the program, your instructions to GRUB will be something like the following:
 
<sourcesyntaxhighlight lang="text">rootnoverify (hd0,PARTITION_NUMBER)
kernel 0+BOOT_RESERVED_OFFSET
boot</sourcesyntaxhighlight>
 
The kernel command loads a multibootMultiboot compliant kernel, and in this case, we have specified an absolute number of sectors to load. The 'kernel' command can automatically detect if the file it's loading from the sectors is an ELF program. In other words, your 'bootloader' may even be a full ELF program, using this trick. In fact, you may even decide to place your kernel's executable image ''as the first N sectors, and have GRUB ELF load the kernel as absolute sectors, and not have to worry about parsing your custom FS at all.''
 
Your kernel image, now loaded into memory (if it's an ELF, you can link it to 1MB physical), can then set itself up painlessly, and it also gets the benefit of the GRUB multibootMultiboot Data structure passed to it. This method completely invalidates the need to write a real mode bootloader. There are other reasons why it is probably ''best'' that Hobbyist OS Developers use this method:
 
The method implies that GRUB is placed into the MBR of a hobby OS partition installation, or even whole disk installation. If all hobby OSs use this method, whether or not they use a custom FS, it gives them the advantage of being able to load a full program, in ''protected mode'' via GRUB, and bypassing the Real Mode bootloader stage ''completely''. No more problems with writing an efficient program in 446 bytes.
 
[[Category:Filesystems]]
[[Category:Bootloaders]]
[[Category:FAQ]]