OSDev.org

Ah, hardware bangers. You think too much in terms of performance, and far, far too much in terms of the status quo.

YES, such a language would reduce the need for mode-switching. But the really useful thing is to express the entire interface exposed by the kernel to the process in this language. Why write a syscall to get the current process ID when the kernel will interpret the identifier "Application" in a script as referring to a Process object representing the current/running/calling process? Likewise for security and IPC: security is just a matter of what other processes or processes' objects have names in the current process's script namespace, and IPC is just a matter of naming another process in a script and invoking an operator on that process to send data to it.

The idea is to build a domain-specific language especially suited to getting done, elegantly and efficiently, those tasks reserved for kernel-space. Doing so would allow not only a reduction in the number of user/kernel switches, but would allow a reduction of complexity of the kernel operations themselves. For example, there would be no need to supply separate blocking and unblocking I/O operations. If the application will either send a script that just says:
if it wants asynchronous operation, or:
to perform the same operation synchronously (if we assume that an I/O operation finishing wakes the appropriate process/thread).

Alboin wrote: There wouldn't be. In fact, Inferno, a friend of Plan9, used this idea for most of its applications. They were written in the Limbo programming language, and were then interpreted by the system vm.

Exactly, so instead of having a huge overhead with ring switching, language parsing, bytecode execution, etc. why don't you either (1) use my batch system call idea or (2) simply make your entire os written in managed code(except the low-level kernel and vm of course).

Personally, if I was you, I would choose option 2 because performance is reasonable and you get to have your little script idea.

You could have a command buffer (which is done in some drivers and graphics APIs to reduce the number of context switches, and for sending data over networks). When you make system calls you basically store the instruction in byte code format in a buffer. When the buffer becomes full (or you forcefully flush the buffer) the entire buffer is sent and processed in one kernel call.

iammisc wrote:@Alboin, how about, instead of a script you can have regular system call that execute all system calls that are in a user-supplied list.

Could I call this a VLIW kernel?

JJ