PavelCheckov wrote:
I was using it as an example: I mean reading a font from my filesystem (probably /usr/share) instead of linking one, like ToaruOS.
For my kernel (Misaka; just to be clear, ToaruOS had a different kernel up until May of this year, Misaka is a totally new thing), I embed a bitmap font, and I skip all of the silly tricks for "linking" a raw binary by encoding that font
as a C source, so it ends up in my kernel binary like any other preinitialized object. It gets used by
a framebuffer logging mechanism. The filesystem is not involved in this process.
(My bootloader
does the same thing so it can draw text after modesetting)
Ethin wrote:
You can get away with something like Tarfs -- that's quite a minimal filesystem and easy to work with. And it would be good as a "bootstrap" filesystem. But either way, its going to require you to write quite a bit of code, particularly if the font isn't linked to your kernel.
Yep! My current initrds are compressed tarballs, and my current boot process has just the initrd image as a multiboot/multiboot2 "module", so it's loaded by the bootloader alongside the kernel (I used to also load device drivers as modules, kinda like Hurd, but now the essential stuff is directly in my kernel and the less essential stuff is just a file on the ramdisk, loaded by the userspace startup scripts with an "insmod" syscall). Misaka has a rudimentary gzip decompression implementation so it can unpack the compressed image, provide it as ramdisk, mount the ramdisk directly with a read-only "tarfs", and then normally it gets migrated into a more flexible in-memory read-write tmpfs which is what the live CD uses from there.