Jivin Ben Kloosterman lays it down ...
> >>
> >> Also can the nvidia driver work ?
> >
> >I highly doubt the nvidia binary driver would ever work on a NOMMU x86.
> >I don't think they have any interest in supporting anything other than
> >the 99.999% standard x86 setup.
>
> Damn so it will prob be painfull if at all, unless I can fake a lib stub.
> >
> >Running x86_64 without MMU simply sounds insane. I can't imagine there
> >is a good reason for doing it.
> >
> >The memory fragmentation issues with NOMMU are painful and given the
> >chance I would always use MMU if available. I don't care if it costs
> >a few percent in performance, it simplfies so many things and helps
> >provide so much more robustness and helps debuging.
> >
> >I guess I really don't understand the desire for uclinux on x86 at all.
> >:)
>
> 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) .
>
> 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) .
>
> Here is a blog post
>
> http://www.shanghai-software.com/blog/archive/2010/04/06/managed-os.aspx
>
> 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.
>
> 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).
You may be able to learn something about performance possibilities by looking
at the ARM example here.
http://opensrc.sec.samsung.com/document.html
uClinux+mono pain will probably depend on mono more than anything.
* how much does it fork() (and is it vfork safe)
* reliance on loadable modules and shared libraries.
* stack usage (to some extent)
Cheers,
Davidm
--
David McCullough, david_mccullo...@mcafee.com, Ph:+61 734352815
McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org
_______________________________________________
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
