OSDev.org

I am working on a kernel for a CPU that doesn’t have a MMU, so I am going for a simple single-tasking system, much like the earlier DOS systems.

However, I would like to know how I would go about loading a program and setting its offset to where it assumes its free memory starts at 0 or wherever they automatically assume their memory starts, and more so — returning back to the kernel when the program is finished.

So basically, how would I go from kernel memory -> program -> kernel memory

Would I have to keep the kernel loaded in RAM at all times? Or would I leave a bit of “kernel loading” code somewhere to jump to when the program is done.

From the sounds of it, it doesn't look like your program will be using the kernel for anything, is that right?

So your kernel sounds more like a program loader and that's it?



At a minimum, you'll need to keep in memory any kernel services required by the program. If your program uses the kernel to access any devices or filesystem, then clearly that will need to be kept resident.

And if you want to be able to load and run a sequence of different programs, the kernel will require some minimal device and filesystem drivers to load said programs from whatever storage you'll be using.

If you're NOT going to be running different programs, then you're perhaps better off with a unikernel design, where the kernel and application are one and the same, and are loaded and run together as a single unit.

From a build perspective, your kernel would effectively be a library that gets linked into your application, and the resulting binary is deployed to your device as required.

Then, all you'll need to keep resident is some sort of image loader, to which your application/unikernel will return to once it's finished, ready for you to load the next unikernel application.

Sorry — should’ve explained my kernel structure more

My kernel is loaded from a binary file from the fat32 disk, and it has a basic fat32 driver at the moment. I plan on making a simple shell to execute and run these programs that needs to be returned to when the program is done executing.

So, it sounds like you need an exec system call to overlay the current process with a new program.

So, your kernel could start your shell (using exec() internally,) do whatever your shell needs to do determine the next program to run, exec() that (overlaying the shell), then the program will exit().

In your kernel, exit() will just be the trigger to restart the shell using exec() again, and the process repeats.

This is basically what DOS and COMMAND.COM together does.

And of course, the benefit of using exec/exit is that you can develop your user programs on an existing posix like system.

Those early DOS systems just loaded programs to a fixed location (often 0x100) and then stayed mostly in memory so programs could use the kernel API for things like input and output, figuring out how much memory is available, and returning to the kernel. Using the kernel API meant the same software could run on different computers as long as the CPU was compatible.

If the shell is an ordinary program, you can free up the memory it uses while other programs are running, and allow the user to specify which program should be the shell.

All single-address-space OSes have to have all their programs be position-independent. Typically by way of an ABI that allows for that. In the case of DOS, the program was loaded to an arbitrary paragraph boundary, and then the segment registers were set up to always make it seem like the thing was running at address 0x100. DOS also had its system calls in software interrupt 0x21. Though there was no need for privilege escalation in those days, there was still a need for hardware (and lowlevel software) abstraction. It is just way nicer to tell the OS to open "foo.txt" than to write a PATA+FAT driver yourself.

For a non-x86 example I can offer my knowledge of OS-9 on the PPC, which simply has register r2 point to the data memory and r13 point to the code memory, and so the program can access constants and variable data relative to those registers safely. Note that OS-9 is multi-tasking, though, so it wants to keep code and data separate so multiple instances of the same program can share code.

So that's what you will have to do: Figure out a way for the OS to tell the program where it is. And a way for the program to make kernel calls. The rest should then follow.

Only the ones that can run more than one program at a time. (Early DOS systems could not do that.)