1
votes

I'm trying to find if there's a name for this concept, and if something similar has already been done:

Do you know of any Operating System (or any kernel design paradigm) where user-land programs don't issue syscalls using the usual trap/interrupt/cpu-instruction technique, but instead the kernel behaves as a runtime dynamic linker whenever an executable is run, so that the kernel loads the executable, locates the unresolved syscalls, attaches them to the proper syscall hooks within the kernel, and then runs the executable?

Think of it as if executables were programs stored in ROM chips: The system loads the ROM, plugs all the unresolved hooks, and launches the process. I'm not thinking in ROM programs, but I think it clarifies the idea.

EDIT: I didn't mean that the application runs in kernel space. The functions in the kernel will switch to kernel space when they are entered, and switch back to user space when they return to the application. What I mean is that all the magic regarding "calling the kernel" happens within the kernel, because the kernel and the dynamic loader are the same thing. The user-land libraries just feel like if there is no kernel (the user-land libraries don't have any means to "call the kernel", but however the implementation of some functions in the user-land libraries is missing, because the kernel will hook them to kernel code when the application is loaded).

1
Windows OS uses something similar (see informit.com/articles/article.aspx?p=22442)xmojmr
@xmojmr: Very instructive! Thanks a lot for pointing this out. Maybe I'm thinking in a very similar approach, but I need to read the article in more detail.cesss

1 Answers

1
votes

It works more or less same way for modules written to run in kernel space. Like device drivers can directly call another module.

For userspace application to run kernel functions - it is not allowed and is mostly done for protection. In early operating systems like DOS did not have any protection and it was actually possible to call any piece of code from any application. BIOS functions are actually stored in EEPROM chips and apps, knowing the mapped address, could call those. It was not nice though.

It has been 10 years since I worked on kernel mode module. Things could have been changed since then.