[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] Memory protection for the FireBee?
On 27/08/2015 07:52, markus@mubf.de wrote:
Frankly, to me it's one of the things that makes the difference between
a 'toy OS' and a serious one.
Definitely.
First level is memory protection, as FreeMiNT does on 680x0. It prevents
user processes to crash the OS, or to crash each other.
Second level is virtual memory. It makes the addresses used by user
processes different than physical ones. This allows more flexibility
such as no need to relocate executables, real fork() support,
memory-mapped files, and even swap files to get more pseudo-RAM.
FreeMiNT has currently no support for that.
There's a whole lot of software around that's not written as clean as
one would wish (especially on the Firebee).
If I want to write clean software, I cross-compile it, I test it with
ARAnyM and memory protection, then I recompile it for ColdFire. And voila.
Of course, this can't be applied when using the FireBee as development
machine.
BaS_gcc already contains a working page fault handler and code to map
and unmap virtual pages. This code could be exposed to MiNT
Definitely.
I saw this as well when I tried to understand how memory protection is
supposed to work, but was at the impression this would be an unfinished
or at least barely tested feature?
I wondered the same...
Anyway, that feature is currently disabled in FreeMiNT for ColdFire. I
considered it as a secondary goal, and I didn't try to port it.
I also wondered if that could work with FireTOS and its CF68KLib.
Theoretically, yes. Even if supervisor-only instructions like movec
would have to be emulated twice:
- one for the fake supervisor mode emulated by the CF68Lib for FreeMiNT
- one for the fake supervisor mode emulate by FreeMiNT for the user program
does that mean there is a something like a common interest in getting
this to work although its quite a lot of effort?
That would be cool, but personally I don't think it is worth.
--
Vincent Rivière