OSDev.org

I had an epiphany at church, after thinking about the design of my os for a couple months. I came back here and realized the idea is really like a exokernel more or less. I liked the idea of having the interface to all the devices in userspace. And completely blocking all userspace applications from accessing kernel functions.


PS. I really hate the way my mind works. Example: discovering parts of calculus on my own before I had even finished pre-alg.
Now realizing that I came up with something already in existence.

Actually, what you described is a microkernel. An exokernel doesn't have drivers.

But yes, someone has previously come up with it unfortunately.

Yeah, thanks for the correction, didn't know which one to use. Though what I'm thinking of may not actually be drivers. Just need to collect the thing on paper now and see what it is.

In Steven Levy's Hackers, Bill Gosper summarizes your position quite well:

Anyway, rediscovering fire isn't necessarily a bad thing, but rediscovering getting burned is. Just make sure you avoid the later in this field as much as possible.

I've already been burned alot. I've been studying lately and I think I can get my hands dirty without an epic fail.

Which goes to show how interesting you find church :)).


JAL

Actually, it was while everyone was singing. Easy to zone out then.

In my mind it seems to be coming out as an exokernel. I'll post the details when I have my first draft complete.

EDIT: Now I realized, wouldn't it be cool if the OS could rotate between sets of 32 bit and 64 bit libraries?(What I'm thinking of could not be considered a library though.)

Unless userspace programs aren't protected from destroying each other at will, then they can't communicate with each other nor with the hardware without accessing the kernel. So you'd have programs, but they can't take input and they can't give output. Nice.

What you probably mean is that only a few functions (like sending a message to the root task) is permissible for userspace applications.

And also, most people who say they are making an exokernel are really making microkernels. But they can't say they are making microkernels because most people who say they are making microkernels actually end up making normal, modular kernels because it's easier. So to sum it up: The exokernel guy wants to make a microkernel, but sees the task as too complex and gives up. The microkernel guy wants to make a microkernel, follows the tutorials for a standard unix kernel, and ends up with a standard unix kernel.

Actually, I mean having different security levels on certain applications. Having drivers run as if they were applications but having a lower security level than user applications. Making all system calls made by the driver-libraries(hehe). The plan is to have all IPC go on in user level. I might be missing something, so feel free to point anything in here that is infeasible.

And I fit in there like this: I want to make a Unix-style kernel in assembly but I end up with some combination of Unix, DOS, and MikeOS. Therefore, it's all gone from a normal state to a crazy state.

Still a microkernel. But that doesn't make it a bad idea (I'm making one myself).

If it has drivers, abstractions (like files, threads, etc.) or any of that stuff most people have come to expect from an OS, its not an exokernel. Exokernels essentially do a sort of para-virtualization: they allow each "process" access to certain hardware, keep it from screwing with other "processes", and then let it have fun.

You're missing something: IPC can't be done entirely in userland. There must be some kernel support. That means a syscall accessible to all processes doing IPC.
Take a look at Sartoris. It's a microkernel with security on syscalls, so not any process can call any syscall (which is mostly necessary for all serious microkernels).

I don't seem how IPC couldn't be done by some sort of driver. But that might make it slower , I'll have to think more about it.

And how would you talk to the driver? IPC, which must already be in place! Or, the driver may run in the kernel, which means a kernel call.

You can have IPC without using a kernel call by using a shared memory page. However, how do you make a shared page? A kernel call!

Good idea.