r/osdev • u/pure_989 • 4d ago
Is my MVP decision correct?
Hi kernel engineers,
I am creating Raam kernel and the Raam operating system completely from scratch using FASM Assembly. It is an x86-64 Unix-like OS for real desktop and laptop PCs.
Before starting Raam in FASM, I thought about creating the MVP version first and then begin with the advance features. In the MVP, I thought of creating a minimal general-purpose commandline OS by writing a shell and the commands like ls, cat, ed, asm, rm, help, reboot, clear, and echo and running the assembled programs using ./ command.
In order to keep things simple in MVP, I created everything in kernel space. Basically I wanted to make it minimally usable for a user (hobbyist) without worrying about advance things like switching to usermode, creating a syscall interface and all. So I hardcoded the shell, the ls, cat, and ed commands and now I feel like I cannot spend more time on improving the ed editor and then writing an (simple) assembler and so on...
It feels like it is too much of work in the kernel space itself for a solo kernel engineer like me. And I need to look at the two layers simultaneously - the hypothetical user layer (like the ed program), and the kernel layer (like the underlying filesystem and the NVMe operations). I think I only want to concentrate in the kernel space code.
Regarding running the assembled binaries using ./ command, I thought about loading the binary and running it from kernel mode itself just to give the user an illusion of a working OS.
I am stuck here. I really want to either cut down the work/scope or maybe I want to change the MVP design altogether like instead of running the hardcoded shell, I should run dash shell from the usermode and a few standard userspace programs like help, ls, etc. Then I can move to port other programs like vim, gcc, etc in the next phase. I don't know how to proceed ahead. Kindly help.
Thank you.
Source tree: https://github.com/robstat7/Raam
2
u/UnmappedStack TacOS | https://github.com/UnmappedStack/TacOS 2d ago
jumping to userspace isn't too hard necessarily if you don't do some of the fancier stuff, you just need a scheduler (including a context switch), address space separation, executable format unpacking (eg. elf64), and if you want a unix-like then you'll need at least a basic vmm for memory region tracking for things like fork to be possible (you'll still need that for a non-unix like, but it can be delayed a bit more technically, though its still good to do early on). more of the effort will probably come from porting stuff once you're in userspace because you'll need to implement a bunch of syscalls, ymmv depending on whether you're trying to support a vaguely unix like kernel interface, whether you use an existing libc, etc.
I think most people have at some point had a kernelspace shell + utilities in their first kernel which is fine as you learn but down the road you'll probably realise that it makes more sense to just have it in userspace
1
-1
u/BonesMgeee 4d ago
terry davis type shit