On Fri, Apr 09, 2010 at 09:32:08AM +0800, Ben Kloosterman wrote: > Damn so it will prob be painfull if at all, unless I can fake a lib stub.
I think it will be not at all. Code compiled to run on an MMU system doesn't have the offset tables to update when loading on a NOMMU system. It simply doesn't work that way. The other way around can be done easily (FDPIC-ELF can do that for example). > For an OS running non safe ( memory and type) apps or /and monolithic I > agree. But I'm not I'll explain. > > It's a long story but basically 10 or so of us have been working on a > Singularity style software protected (ie no ring 3) OS Toolkit ( to build > OS) with software protection for about 3-4 years. ( These come under Mosa , > Cosmos , Sooos and sharp OS) but its bogged down as most of the efforts > (90%) has gone into the AOT compiler and tools ( debugger), though we do > have some booting OS with file system support. For such an OS to be useful > (past education) you need a very good optimizing compiler now the mono or MS > C# to CIL compilers do a lot but not enough. While this has been going on I > have been designing an OS for about 12 months and have been building it on > windows (using an emulation HAL) but as a lazy, time stricken older dev it > struck me that I can get a MMUless version of Linux running with Mono , then > I have something useful already and after adding new Async IPC ( for managed > to managed) and some runtime checks can then slowly migrate drivers to safe > language micro kernel style user apps ( even if it is just a wrapper of > some mature code) . How can software protect you from bad pointers clobbering memory from some other process? Sure the language/compiler can runtime check every pointer before using it. Sounds very inefficient though. > The benefit here is I start with a mature and useful code base and can > continue to improve it . It is also very portable ( a lot of the porting > between arch is problematic due to different MMUs) since like Java the C# > apps will just work on dif arch. Note we support all the .Net language ( > C#, VB , F# , j# , Iron Python , ruby , php ) as well as Java ( via a Java > to CIL converter) . The MMU really isn't the biggest problem in going between architectures. Allignment issues and endianess can often be much bigger issues. > Here is a blog post > > http://www.shanghai-software.com/blog/archive/2010/04/06/managed-os.aspx That seems to just timeout. > Please note the Mosa guys will prob run with a monolithic MMU ( but no ring > 3) while im working on a micro kernel style OS. Lots of microkernel OSs use MMUs (because they are such a good idea). > Note Linux is just an idea at the moment , if uClinux + Mono proves more > trouble than it's worth than its back to a pure green field C# OS . My goal > is to gain about 10% perf from dropping the MMU ( see paper Rethinking the > Software Stack 2006) and use about 5% of that to make it a Micro Kernel ( > but note we have no ring 3) and a few run time checks ( most of the checking > is in the AOT compiler the only executable you can run are CIL ( managed) > libs. We can do this because without a ring 3-0 switch context switches just > become cheap task switched. The end result is a self healing ,easier to > maintain more secure more reliable OS with about the same speed or slightly > faster than Linux. The cost is you can only run CIL/Java apps and drivers ( > though a few trusted drivers could be wrapped native). I highly doubt you will gain 10% by not using the MMU. On some architectures perhaps, but not in general. There are things that are trivial to do in hardware and very hard (or at least very expensive) to do in software. Memory protection is one of those things. -- Len Sorensen _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
