Reuse of FAT32 parsing code in kernel and bootloader.

[rbgrube]

Hello!

I am currently attempting to develop a simple OS, and I decided to make a custom bootloader to gain experience with the boot sequence and assembly programming. My bootloader currently loads my kernel from a FAT32 partition on the boot disk, and therefore has many functions that are used to manage of the FAT filesystem (parsing of FAT Tables, following cluster chains, ect)

Now that I have started development on my kernel - which also need to parse the FAT filesystem - I've been struggling to decide on a code structure for this. The crux of my question is, should I use the same FAT32 parsing code from my bootloader in my kernel, or should I write new code entirely.

My bootloader executes almost fully in 16 bit real mode, while my kernel executes in protected mode (and I hope to implement virtual memory and paging) However, it just seems a little ridiculous to create a near duplicate of the FAT helper functions, and I have a feeling I could abstract the parts that differ based on execution mode. If I do use the same code, should I use shared source code that gets linked to both binaries, or should I call the bootloader functions directly from my kernel?

I just don't know what would be the cleanest and most efficient for my OS.

Thank you in advance!

[Octocontrabass]

should I use the same FAT32 parsing code from my bootloader in my kernel, or should I write new code entirely.

You should write new code. If you want your kernel to support writing to the disk instead of just reading, you'll need new code anyway. Even if you're planning on sticking to read-only, your bootloader and your kernel will probably need different things out of a filesystem driver. (And what about UEFI?)

If I do use the same code, should I use shared source code that gets linked to both binaries, or should I call the bootloader functions directly from my kernel?

If you did choose to call the bootloader functions from the kernel, how would you do it? Keep in mind the CPU can't run 16-bit code in 32-bit mode.

[rdos]

It's generally a poor idea since a bootloader just needs to read some sectors and does not need to handle random file access. Your file system will need buffers for disc and file content to deliver acceptable performance. Your boot loader needs none of that. Your file system might also want to support file systems other than FAT32.