I?m not that far that I can load and execute a program, but I want to start to think about that before I will start actually coding!
How is this done in a microkernel?
I thought that a program or the app-server makes a syscall for executing a program and it gives the address of the fileimage to this syscall. Then the kernel would create a new pd and moves the image first into the kernel space then it would change to this new task and the new task will be first in kernel space. It will then interpret the image and copy the data into the right place. Then it would jump into ring3 and starts executing the code.
Is there a another waay of doing it or is there also a better way?
The problem that I see with this version is, that the could not have enough free place to move the image into kernel space.
microkernel program loading and executing
-
AR
Re:microkernel program loading and executing
I haven't got this far but I'm currently reimplementing my Kernel to use a HAL so I have some limited knowledge of this.
You'll need to decide what executable format you want first as that will certainly affect how you load programs, ELF is simple enough and has quite a bit of open endedness so that you can add custom modifications without disrupting the core ABI.
It's easiest to just have the loader in the Kernel (otherwise the app server would need to tell the Kernel to create a "blank" process to share memory with which it can then load the process into - and getting the App server going to start with becomes complicated). With ELF [using a Kernel loader] you just examine the headers, verify that it's valid then use the program header table to map the process into memory (it basically says "File offset 0x100 for 0x2000 bytes goes in memory at 0x40000000 and is writable").
A complexity is introduced for shared objects though, if there is an Interpreter section then you'll need to map in the Dynamic Linker using the same approach (verify headers, then read the program header table to map it in), push a few params on the [userspace] stack and then start the process at the linker's entrypoint (ld.so will automatically call the program's entrypoint after it finishes loading, no intervention is neccessary beyond this point).
You'll need to decide what executable format you want first as that will certainly affect how you load programs, ELF is simple enough and has quite a bit of open endedness so that you can add custom modifications without disrupting the core ABI.
It's easiest to just have the loader in the Kernel (otherwise the app server would need to tell the Kernel to create a "blank" process to share memory with which it can then load the process into - and getting the App server going to start with becomes complicated). With ELF [using a Kernel loader] you just examine the headers, verify that it's valid then use the program header table to map the process into memory (it basically says "File offset 0x100 for 0x2000 bytes goes in memory at 0x40000000 and is writable").
A complexity is introduced for shared objects though, if there is an Interpreter section then you'll need to map in the Dynamic Linker using the same approach (verify headers, then read the program header table to map it in), push a few params on the [userspace] stack and then start the process at the linker's entrypoint (ld.so will automatically call the program's entrypoint after it finishes loading, no intervention is neccessary beyond this point).
Re:microkernel program loading and executing
Hi,
During boot I load a "boot image" that contains the kernel and any files needed to access storage devices, file systems and networking. The files from the boot image are moved into the "virtual file system" code's cache, which behaves like a RAM disk. From there software can tell the kernel to load and run any file (even when there are no file systems or device drivers).
When a new process is started, the kernel creates a new/empty process (which for me is just a "process data area" containing a few details) and spawns a thread for the process (which involves creating an address space, "thread data area", etc). This thread starts by running kernel code that does a few checks and loads the file from the virtual file system into the address space. After a bit more fiddling about the thread jumps to the user-level code.
Sooner or later I'll support "memory mapped files" so that the entire executable file doesn't have to be loaded into memory before the process's code is jumped to.
I don't have a syscall that allows a process to be started directly from memory - it must be loaded using file IO. This is because each file has access restrictions that determine who/what can execute it (similar to *nix file permissions). It also means that for each file in the boot image there's directory entry information (file name, permissions, timestamps, etc).
I'd try hard to avoid storing the executable file in kernel space. You could have a huge executable file or the OS may be trying to start a heap of programs at the same time.
Cheers,
Brendan
During boot I load a "boot image" that contains the kernel and any files needed to access storage devices, file systems and networking. The files from the boot image are moved into the "virtual file system" code's cache, which behaves like a RAM disk. From there software can tell the kernel to load and run any file (even when there are no file systems or device drivers).
When a new process is started, the kernel creates a new/empty process (which for me is just a "process data area" containing a few details) and spawns a thread for the process (which involves creating an address space, "thread data area", etc). This thread starts by running kernel code that does a few checks and loads the file from the virtual file system into the address space. After a bit more fiddling about the thread jumps to the user-level code.
Sooner or later I'll support "memory mapped files" so that the entire executable file doesn't have to be loaded into memory before the process's code is jumped to.
I don't have a syscall that allows a process to be started directly from memory - it must be loaded using file IO. This is because each file has access restrictions that determine who/what can execute it (similar to *nix file permissions). It also means that for each file in the boot image there's directory entry information (file name, permissions, timestamps, etc).
I'd try hard to avoid storing the executable file in kernel space. You could have a huge executable file or the OS may be trying to start a heap of programs at the same time.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.