Linked by Thom Holwerda on Tue 22nd Jul 2008 12:27 UTC, submitted by danmassa7
Scott Finley, a researcher at the University of Wisconsin-Madison has ported the Linux files system Ext2 to Microsoft's new research operating system Singularity. One of the most striking observations was the author's comments on Singularity's robustness. "Perhaps the best testament to Singularity's dependability was the extremely good system stability during the development of ext2... If the ext2 process terminated as the result of a failure, it only resulted in open channels closing. Other processes could (and did) recover gracefully." Finley's report details all his findings quite extensively.
Thread beginning with comment 324125
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:
2005-07-06
I think you are right and I am wrong about SIPs. I have done a little reading and it seems that singularity has inspired a few design decision in other managed OS's. It also seems that manifest based programming is being implemented in differing forms in other managed OS's.
http://lab.obsethryl.eu/content/sharpos-stream-c-sharp-c-kernels was in interesting read for me.
From the interview
Bruce Markham: There has been a bit of debate as to how we should approach this. There is no doubt that we want the performance and security gains of SIPs, (with the exception, from the original Singularity implementation, of still having code sharing.) But we also expressed a desire to be able to virtualize other OS's application binary interfaces (ABIs) down the road, so that basically we will be able to run, say, a Windows program, without recompiling the way WINE and ReactOS already allow. This would require hardware isolation, and reduce performance for any processes involved.
William Lahti: The SIP functionality that Singularity integrates is really one of the exciting parts of a managed operating system. Although we do not have code for processes yet (as we are still flushing out the AOT compiler, runtime, and corlib), we intend to use SIP (software isolated processes) as the first-class citizen process in SharpOS.
With that said, we realize pragmatically that hardware isolation will be required for unsafe/unmanaged code, and we want to account for that. Our SIPs will run in the same address space/ring as the kernel, allowing us to reduce context switching time considerably, as well as the overhead of communication between the kernel core, drivers, and the individual processes. For those who are unfamiliar with SIPs, the idea is that verification of IL code replaces the need for barriers between separate software entities.