Toy OS Filesystem [closed]

Question

I have developed a basic kernel in assembly/c that runs a basic terminal. I have set it up to run off of an iso with grub.

I would like to continue this OS, but without a file system, I feel as if there's really nothing else I could do. After much time on the internet, I have come up with really nothing I can do to implement this.

People have said implement FAT or make a VFS, but nothing any further, nor tutorials, nor any references to anywhere.

Could someone explain how a file system works, where I can get started/where I can connect a pre-made system, and how to use it?

Also, I do not have access to standard libraries when compiling my os. I use gcc, nasm, ld, and grub-mkrescue(for the disk image). I use qemu for emulation.

EDIT to make less OT

Can someone describe, in detail how a file system works, so when I look at the sources of file systems that have been implemented, like FAT, I can understand how to apply it to my own operating system?

EDIT - Simpler

Even easier. How could I directly access the hard drive? My kernel runs completely in protected mode, so could I switch out and write directly to the hard drive. A file system could be implemented with a file looking like this:

name special char text special char

ie:

hello world.script 0x00 println "Hello, world!!" 0x00

Where you wouldn't need special segmentation, you would just look until you find the file name and the special character (something not in a string like '\0') and then read until you find the second non-string character.

Would there be a way to access the hard drive by switching in and out of protected mode or write a hard disk driver in order to implement this?

Answer 1

First, read wikipage on file systems to have some broad view.

The relevant resource about operating system development is OSdev (but perhaps your question is off-topic here). Kernelnewbies could also help (explaining how Linux is doing). OSdev have wikipages explaining FAT & Ext2 in details.

You could design an OS without any files (but some other persistence machinery). See this answer. You could have persistent processes (read also about application checkpointing, garbage collection, continuations, hibernation).

But you should read some good books about Operating Systems (e.g. by Tanenbaum, or the freely downloadable Operating Systems: Three Easy Pieces book). Be fluent with some existing free software OS, e.g. Linux (& POSIX), so read Advanced Linux Programming (at least to understand many concepts and get a good terminology).

IMHO, the FAT is such an ugly and inefficient file system that it is not worth looking into (except for legacy and compatibility reasons). Ext4 (see here) should be better & the wikipage on Ext2 has a nice picture.

You could adapt some library providing a file system (e.g. libext2) to your kernel.

You could perhaps adapt sqlite to work on a raw disk partition.

You might have a notion of file which is not like MSDOS (or Windows) or POSIX or <stdio.h> files. For example, it might be a sequence of fixed size records (e.g. of 1Kbyte), not a stream of bytes.

You could organize your OS as a microkernel and have file systems given by application code. Look into VSTa and HURD.

You need of course a disk driver, which fetches/writes blocks (of 4Kbytes) from your drive (disk I/O is always by blocks or disk sectors. Old small disks had 512 bytes blocks. New large disks have 4Kbytes ones, see advanced format). It should be interrupt driven and uses DMA. You need a task scheduler. AFAIU, you won't use the BIOS for this (perhaps the UEFI); you need to understand how common hardware (SATA & AHCI) works.

You should publish (today!) your toy OS as free software (e.g. under GPLv3+ on github) to get feedbacks and contributions.

You might copy (if licenses are compatible) existing code from other free software operating systems, and you certainly will study their source code to understand things.

So code some task scheduler, a page fault handler, a virtual memory, then add interrupt driven disk IO, and some file system code above that. Then you'll beginning to understand that an OS cannot be a small toy.... You might consider a microkernel or exokernel approach.