Restarting my kernel... Any Suggestions?
Posted: Thu Oct 04, 2007 9:59 pm
After a very long time after my first kernel got all messed up on user-space task switching and after a very long depression after that 
, I finally decided to restart os devving.
Now that I know exactly what I have to do instead of adding things in after the fact.
Anyway, my new kernel is going to be hugely minimal. It is only responsible for basic hardware access and security(process security is handled by a user space program), task switching, and message passing. It is based on the concept of actors. Each process is an actor which can receive messages. They are 5 levels of messages: 1 being for switch contexts and send the message now and 5 being normal delivery(the next time the process is switched to). In order to receive messages, each process has to register a thread and a function that is called whenever a message is sent. So to send a message to a process the kernel will switch to that thread and call that function with the message. In the meanwhile, the thread is kept in a suspended state. Scheduling is the job of the kernel but I would really like to be able to configure that and provide hints using a userspace actor.
Aside from the initial init process and a few specific and needed actors(Filesystems and disk actors) which are already loaded into memory at boot time, the kernel doesn't even handle process spawning. Basically, the init process will have to spawn a new child. Initially that child is set to execute messages with the default kernel function. By sending the appropriate messages the init process can spawn a new userspace child. This introduces an obvious security hole. However, each process will have its own capability and the only way to get that capability is to spawn the new process yourself or have the appropriate privileges(root can do anything). Capabilities and security are described in the next paragraph. However, in the case of processes, the kernel will have to handle the capabilities, with the security daemon acting as a bridge.
For security, I'm going to be using a userspace actor. It will be based on capabilities. A capability is a random number generated at boot time. Each facet of the operating system will have its own capability. Basically, to send a message to an actor requiring a capability, you would tell the kernel to send a message to the security daemon. Inside this message will be another message and the actor id to whom to send this internal message to. The security actor will check to see if the process has the appropriate privileges and if so, it will reformulate the message sent inside to contain the capability and it will act as a proxy to forward the message. This can be analogized to a proxy server on the internet.
Two other important actors are the input and output actors. Basically these abstract over other lower level actors. User programs can talk directly to those lower-level actors(they'll have a standard api), but it is not encouraged. The input and output actors are highly abstracted. For example a program could say to the input actor, "Give me a string from the user," and the input actor would see if the current terminal is graphical or textual. Depending on the terminal type, it would ask for input in that way. It would pop up a dialog for graphical and interrupt the screen for text. This could also be taken so that the input actor uses something else like a speech recognition engine(though that's REALLY REALLY REALLY REALLY REALLY far off). The output actor can also do things like that. This way, most programs can offer a fairly good graphical *and* textual interface without adding special ui's for each. Of course, some programs need more advanced things and so they can do direct lower-level messaging.
For networking, there will be a networking actor which like the input and output actors will abstract over lower-level actors. The lower-level driver is completely responsible for everything including the TCP/IP stack because some NICS can offer acceleration on that, however, due to the ability to forward messages, drivers without that ability can use the software based ones. I hope to use that kind of driver does all thinking for all drivers to be able to fully use hardware acceleration. Of course, there will be software backups for everything(except the base hardware).
I hope software installation to be like Portage in Gentoo except without the compiled from source ideology. Instead, you will be able to use a repository(no syncing) for some software. Other times you can just double click on a file(like an ebuild) and this system will install it for you. This offers the goodness of linux-type repository installs with the familiar windows software installation procedure.
I've probably overlooked some things(which is why I've posted my ideas here). I look forward to all your suggestions.
Also, I don't have a name for this kernel so any suggestions will be appreciated. I was leaning towards some type of animal like dolphin(because they're streamlined and work in groups), but I would like to hear what you have to say.
Thanks.
, I finally decided to restart os devving.Now that I know exactly what I have to do instead of adding things in after the fact.
Anyway, my new kernel is going to be hugely minimal. It is only responsible for basic hardware access and security(process security is handled by a user space program), task switching, and message passing. It is based on the concept of actors. Each process is an actor which can receive messages. They are 5 levels of messages: 1 being for switch contexts and send the message now and 5 being normal delivery(the next time the process is switched to). In order to receive messages, each process has to register a thread and a function that is called whenever a message is sent. So to send a message to a process the kernel will switch to that thread and call that function with the message. In the meanwhile, the thread is kept in a suspended state. Scheduling is the job of the kernel but I would really like to be able to configure that and provide hints using a userspace actor.
Aside from the initial init process and a few specific and needed actors(Filesystems and disk actors) which are already loaded into memory at boot time, the kernel doesn't even handle process spawning. Basically, the init process will have to spawn a new child. Initially that child is set to execute messages with the default kernel function. By sending the appropriate messages the init process can spawn a new userspace child. This introduces an obvious security hole. However, each process will have its own capability and the only way to get that capability is to spawn the new process yourself or have the appropriate privileges(root can do anything). Capabilities and security are described in the next paragraph. However, in the case of processes, the kernel will have to handle the capabilities, with the security daemon acting as a bridge.
For security, I'm going to be using a userspace actor. It will be based on capabilities. A capability is a random number generated at boot time. Each facet of the operating system will have its own capability. Basically, to send a message to an actor requiring a capability, you would tell the kernel to send a message to the security daemon. Inside this message will be another message and the actor id to whom to send this internal message to. The security actor will check to see if the process has the appropriate privileges and if so, it will reformulate the message sent inside to contain the capability and it will act as a proxy to forward the message. This can be analogized to a proxy server on the internet.
Two other important actors are the input and output actors. Basically these abstract over other lower level actors. User programs can talk directly to those lower-level actors(they'll have a standard api), but it is not encouraged. The input and output actors are highly abstracted. For example a program could say to the input actor, "Give me a string from the user," and the input actor would see if the current terminal is graphical or textual. Depending on the terminal type, it would ask for input in that way. It would pop up a dialog for graphical and interrupt the screen for text. This could also be taken so that the input actor uses something else like a speech recognition engine(though that's REALLY REALLY REALLY REALLY REALLY far off). The output actor can also do things like that. This way, most programs can offer a fairly good graphical *and* textual interface without adding special ui's for each. Of course, some programs need more advanced things and so they can do direct lower-level messaging.
For networking, there will be a networking actor which like the input and output actors will abstract over lower-level actors. The lower-level driver is completely responsible for everything including the TCP/IP stack because some NICS can offer acceleration on that, however, due to the ability to forward messages, drivers without that ability can use the software based ones. I hope to use that kind of driver does all thinking for all drivers to be able to fully use hardware acceleration. Of course, there will be software backups for everything(except the base hardware).
I hope software installation to be like Portage in Gentoo except without the compiled from source ideology. Instead, you will be able to use a repository(no syncing) for some software. Other times you can just double click on a file(like an ebuild) and this system will install it for you. This offers the goodness of linux-type repository installs with the familiar windows software installation procedure.
I've probably overlooked some things(which is why I've posted my ideas here). I look forward to all your suggestions.
Also, I don't have a name for this kernel so any suggestions will be appreciated. I was leaning towards some type of animal like dolphin(because they're streamlined and work in groups), but I would like to hear what you have to say.
Thanks.
