MOSA-0003: MOSA Kernel and Process Model (Discussion)

Coordinator
Jan 7, 2009 at 11:07 PM
Edited Jan 7, 2009 at 11:13 PM
I've posted an initial (incomplete) draft of a MOSA Kernel and Process Model RFC in our wiki

This RFC discusses the MOSA process model in an architecture independent way. The kernel model provides foundations to run kernel services, drivers and applications in processes in various isolation levels. This RFC specifies various parts with respect to this goal. This RFC also defines the way kernel services offer their features to other processes, how applications can take advantage of these services and the way hardware is integrated into this model. The architecture defined in this RFC also provides foundations in order to secure and isolate applications from the system and from each other. It provides a means to run individual applications or services in a sandbox in full isolation from the remainder of the system.

Please discuss the RFC in this thread. Any comments, additions or opinions are welcome.
Developer
Jan 16, 2009 at 8:29 PM
I was wondering, mayhaps we can emulate some of this? Once an RFC has defined some of these interfaces a little better, maybe our emulated kernel could do something like manually AOT code, load it into memory allocated by System.Runtime.InteropServices.Marshal , and with a synthetic scheduler (using already-present threads in the operating system), start a virtual process and use InteropServices.Marshal to wire everything up!

Maybe, once the time comes, test the JIT this way?

Eh?

On Wed, Jan 7, 2009 at 7:07 PM, __grover <notifications@codeplex.com> wrote:

From: __grover

I've posted an initial (incomplete) draft of a MOSA Kernel and Process Model RFC in our wiki:

<tt>This RFC discusses the MOSA process model in an architecture independent way. The kernel model provides foundations to run kernel services, drivers and applications in processes in various isolation levels. This RFC specifies various parts with respect to this goal. This RFC also defines the way kernel services offer their features to other processes, how applications can take advantage of these services and the way hardware is integrated into this model. The architecture defined in this RFC also provides foundations in order to secure and isolate applications from the system and from each other. It provides a means to run individual applications or services in a sandbox in full isolation from the remainder of the system. </tt>

Please discuss the RFC in this thread. Any comments, additions or opinions are welcome.

Read the full discussion online.

To add a post to this discussion, reply to this email (mosa@discussions.codeplex.com)

To start a new discussion for this project, email mosa@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Coordinator
Jan 17, 2009 at 2:48 AM
I've had similar thoughts about using the emulated environment for initial prototyping the RFCs, but I never thought about extending it to the JIT. It's a long strench but I don't see why that won't work.
Developer
Jan 17, 2009 at 2:57 AM
You don't even have to get to the full trampolining point to do it. You could could AOT code, with the kind of restrictions on the IL that would be needed for user space anyway.

Paging and page restrictions could be hard to emulate, but the core kernel abstractions would be really easy to wire up. The IPC will be different (no *real* interrupts), but the patterns involved would be spot-on.

I'm wondering though, what other kinds of RFCs we need to tackle before we can get to that point. The boot process RFC is still hanging out there, along with this one, and the debugging one. But I think alot of what is in the way, is compiler support. So I guess we need to make sure we have a well defined path of progression for it...
Coordinator
Jan 17, 2009 at 12:15 PM
Good idea illuminus86, I've got some more RFCs in my head, specificially one relating to scheduling/thread dispatching. However as there's not much of a response to the previous ones I'm a bit disappointed. I didn't intend the RFCs to become defacto standards immediately, but rather as a base to start brainstorming.

About trampolines, I've got close to get them really working in Win32, however if we AOT the jit and load it ourselves, it is much easier to get them working, as we don't have to restrict ourselves to the MS .NET/Mono calling conventions there. Most of the trouble I had was getting around the security placed in the managed->unmanaged  transitions...
Developer
Jan 21, 2009 at 2:40 AM
Damn job seems like it's 24/7 most days...

The RFC by itself reads okay. I was just under the impression that this subject was going to be a "recommendation" type wiki page, and not a formal RFC? It goes back to the whole idea of the possible perception that MOSA is imposing a design standard on the client OSs in order for the OS to work with our compiler, runtime, etc. Or that could be me. I know we're eventually trying to be like a managed OS POSIX standard. POSIX just happens to go hog-wild about OS design standards. :)

I also like Bruce's idea of using an idealized emulated kernel as our integration test case. This can serve a dual purpose, in both providing an integration test framework for all of our projects, and also providing a "you don't have to design your OS this way. But here's some base skeletal boot / kernel code to get you going" reference source. I just don't want the scope creep of providing a full scheduler, memory manager, etc in MOSA, unless we want to actually go down a "MOSA OS" road. But I'm just repeating myself at this point. :)

At this stage, when I think of RFCs that have to be written, I'm thinking of a few major ones that are of the "what do I provide, what do I need?" format. What is the interface that defines what a MOSA-compliant compiler provides to a MOSA-compliant runtime and/or the OS on top, and what is the interface of the services the compiler needs from the runtime and OS? Same for a MOSA-compliant runtime. What does it provide, what does it need? This will codify the separate projects as interchangeable skeleton modules. Then your compiler, Phil's runtime, etc become reference implementations of a written standard. So down the road, I might be able to use Mike's compiler with Mono's runtime (assuming Mono would ever implement the MOSA runtime/VM interfaces), with MS's MOSA-compliant managed driver framework (heaven forbid...). I can swap out as necessary, without "vendor lock in". Hope that made sense.

I'm done for now, lest I let the brownies in the oven burn.

--S

__grover wrote:

From: __grover

Good idea illuminus86, I've got some more RFCs in my head, specificially one relating to scheduling/thread dispatching. However as there's not much of a response to the previous ones I'm a bit disappointed. I didn't intend the RFCs to become defacto standards immediately, but rather as a base to start brainstorming.

About trampolines, I've got close to get them really working in Win32, however if we AOT the jit and load it ourselves, it is much easier to get them working, as we don't have to restrict ourselves to the MS .NET/Mono calling conventions there. Most of the trouble I had was getting around the security placed in the managed->unmanaged  transitions...

Developer
Jan 21, 2009 at 12:52 PM

The RFC by itself reads okay. I was just under the impression that this subject was going to be a "recommendation" type wiki page, and not a formal RFC? It goes back to the whole idea of the possible perception that MOSA is imposing a design standard on the client OSs in order for the OS to work with our compiler, runtime, etc. Or that could be me. I know we're eventually trying to be like a managed OS POSIX standard. POSIX just happens to go hog-wild about OS design standards. :)

I don't personally know about POSIX's pros and cons, but I know that MOSA is charged with standardizing it enough such that MOSA-compliance compares, in purpose and functionality, to POSIX. The level of desired rigidity for such standards I believe is what concerns Scott. The biggest concern for compliance that I see, is compiler contructs, runtime contructs, and the interaction/integration with the kernel/userspace code that is being compiled.

Which is the main reason why, right now, you can't take say, SharpOS' AOT, and use it to compile Cosmos or MOSA reference materials. Because they all work differently.
I also like Bruce's idea of using an idealized emulated kernel as our integration test case. This can serve a dual purpose, in both providing an integration test framework for all of our projects, and also providing a "you don't have to design your OS this way. But here's some base skeletal boot / kernel code to get you going" reference source. I just don't want the scope creep of providing a full scheduler, memory manager, etc in MOSA, unless we want to actually go down a "MOSA OS" road. But I'm just repeating myself at this point. :)

Yea, like grover has said, I don't think we want a "MOSA OS". But I know that alot of OS components are going to have to be developed around here to support some of the reference implementation stuff. This is why the compiler is the most important piece. Because if we can get other projects (e.g. Ensemble, SharpOS) to use the compiler and it's integration mechanisms, we can start writing VMMs, etc., and then contribute them to MOSA under MOSA's licensing so that MOSA isn't spending time writing OS components that it really only needs for support.

At this stage, when I think of RFCs that have to be written, I'm thinking of a few major ones that are of the "what do I provide, what do I need?" format. What is the interface that defines what a MOSA-compliant compiler provides to a MOSA-compliant runtime and/or the OS on top, and what is the interface of the services the compiler needs from the runtime and OS? Same for a MOSA-compliant runtime. What does it provide, what does it need? This will codify the separate projects as interchangeable skeleton modules. Then your compiler, Phil's runtime, etc become reference implementations of a written standard. So down the road, I might be able to use Mike's compiler with Mono's runtime (assuming Mono would ever implement the MOSA runtime/VM interfaces), with MS's MOSA-compliant managed driver framework (heaven forbid...). I can swap out as necessary, without "vendor lock in". Hope that made sense.

Exactly. I fully agree.