[Mono-dev] [Mono-devel-list] Operating System in C# Project

[Victor Costan]

Hi, guys!

I've been thinking of something similar.

I've seen a Singularity presentation at MIT, and it seems to me that they're
placing a lot of focus on static verification -- when they talked to us,
they were trying to make driver contracts, so that drivers can be verifiable
too. I think that's taking it a bit too far... and this means there's room
for another C#-based OS.

I wrote an e-mail about this on the Mono list in late August, and I didn't
get any answer, so I kind of gave up hope. I think there's value in having a
.net OS, for (at least) the following reasons:
* easier debugging and optimization because of metadata
* easier development due to high-level languages
* (if properly made) better test bed for research projects
* more security, due to the .net verification process

I think that most of the OS kernel, and everything on top of that, can be
managed (although not safe) code. C# supports unsafe pointers, and that can
be used to implement memory management (which is needed by the runtime) and
most resource management functions you'd expect in a kernel. I conjecture
that we only need asm and C/C++ for a boot loader and a small library of
architecture-dependent functionality (interrupts, context switching, TLB
flushing, and GDT/IDT setup come to mind).

The way I was thinking of doing this is:
* use g++ to compile the native functions
* use mono's AOT process to compile the C# kernel
* use a tool (written in C#) to build an executable image
	* patch the AOT output to make it run
	* statically link the native g++ output into the image

My problem is that I'd like architecting the new system and implementing the
new kernel and the library... but I don't want to spend the time to develop
the tool I mentioned, or modify the mono compiler. Of course, this can
change if other people are willing to help.

Please let me know what you think,
	Victor


From: mono-devel-list-bounces at lists.ximian.com
[mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Suresh Shukla
Sent: Tuesday, October 03, 2006 7:14 AM
To: William Lahti; mono-devel-list at lists.ximian.com
Subject: Re: [Mono-dev] [Mono-devel-list] Operating System in C# Project

> As for the runtime being managed-- that depends on the ability to
> translate the entirety of it's CIL to 100% unmanaged code (without
> runtime-support). I'd say this is where the real challenge is.

CIL required for this task requires to be identified. One good point to
start the project can be rewriting of an OS (preferably MINIX) in C# and to
find the CIL generated. This would give fair idea of how much work is
required. Also if language has all constructs to support our task.

> It would also provide a way to create unmanaged ELF
> executables based on C# software.

You are right on the nail. Combined with the above resulting OS and
CIL-native  compiler this would allow system programming in C#.

Mono AOT and DotGNU runtime already have something on this. 
I found this interesting: http://dotgnu.info/html2.0/pnet.html

William Lahti <xfurious at gmail.com> wrote:
Hello, Suresh!

Your managed OS idea intrigues me. I have been working on a
Linux-based OS which uses C# solutions for as much of the high-level
(non-OS level) stuff like the boot agent, toolkit, OS tools, etc.
Perhaps that code would be usefuI for your project? I have been
considering doing C# rewrites of UNIX tools too.

In any case, I am very interested in this project and would like to
help/participate.

Kernel and user space code translation shouldn't be all too difficult,
considering mono does just that. Assuming the translated code would
still require a runtime, mono's AOT facilities could handle this.

As for the runtime being managed-- that depends on the ability to
translate the entirety of it's CIL to 100% unmanaged code (without
runtime-support). I'd say this is where the real challenge is.

Yeah, the ability to generate fully-native executable files instead of
shared libraries when invoking AOT compilation... perhaps instead of a
new tool, this change could be implemented as another mono runtime
compilation option like AOT (IE, mono --native or such). This would
minimize the amount of redundant work, and since it would be right in
the runtime, the checks for runtime-dependent code would probably be
easier/complete. It would also provide a way to create unmanaged ELF
executables based on C# software.

Another idea: a subset of C# could be defined so the compiler can
report runtime-dependent code as errors...

On 9/28/06, Suresh Shukla wrote:
> This is very interesting idea.
>
> I had been thinking about this for some time. To bring the language
> cleanliness and clarity of Java / C# down to OS layer.
>
> The OS I have in my focus is mikrokernel based distributed servers
> architecture, actually MINIX. Minix brings many best practices and
> cleanliness from OS side.
>
> In my opinion a compiler for generating native code from C# would be
> required. Then the task could boil down to a port/rewrite of MINIX.
>
> Suresh
>
>
> ________________________________
> Find out what India is talking about on - Yahoo! Answers India
> Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get
> it NOW
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

  
________________________________________
Find out what India is talking about on - Yahoo! Answers India 
Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get
it NOW