Bootloader Development Goals.

[yByonic]

Hello everyone! I'm thinking about developing an operating system and I had some doubts about bootloader development. From what I've read, using your own bootloader and a public one (like GRUB) doesn't make that much of a difference, and I don't have that much to lose by getting full project oversight in return. So, I went to investigate trying to know the goals of a bootloader (and in case I forget one, please remind me):
-Use identifier 0x55aa.
-Create a GDT.
-Switch from real mode to protected mode (32bits).
-Start the kernel.

Something I keep thinking about is the hard drive and file systems. When, in the future, the kernel jumps to other spaces on the hard drive, is it the bootloader that has to do "the request"? As a bootloader, is it necessary/recommended to work with file systems?
Please give your opinion. Thanks in advance.

[Octocontrabass]

From what I've read, using your own bootloader and a public one (like GRUB) doesn't make that much of a difference,

It makes a big difference! GRUB is stable. If you write your own bootloader, you have to debug it too, and there will be bugs that only happen on real hardware.

Also, GRUB does the work of at least six bootloaders: BIOS hard/floppy disk, BIOS CD, BIOS PXE TFTP, UEFI disk, UEFI PXE TFTP, and UEFI PXE HTTP.

-Use identifier 0x55aa.
-Create a GDT.
-Switch from real mode to protected mode (32bits).
-Start the kernel.

-Load the kernel into memory.
-Get information from the firmware (memory map).
-Initialize the display.

When, in the future, the kernel jumps to other spaces on the hard drive, is it the bootloader that has to do "the request"?

Typically no, but you can do that if you really want to. I've heard of kernels that work this way before the storage drivers are loaded.

As a bootloader, is it necessary/recommended to work with file systems?

It's not necessary, but it is convenient. GRUB works with file systems.