From fnaumann@mail.cs.uni-magdeburg.de Tue Jun 29 10:34:44 2004 Date: Tue, 29 Jun 2004 10:29:01 +0200 From: mikro To: mint@fishpool.com Subject: [MiNT] mint & mmu Message-ID: <20040629082901.GA17656@hysteria.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on onyx.hysteria.sk X-Spam-Status: No, hits=-4.9 required=5.0 X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at fishpool.fi Delivered-To: mint@fishpool.com Delivered-To: mint@lists.fishpool.fi X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: mikro@hysteria.sk Precedence: bulk List-help: List-unsubscribe: List-ID: X-List-ID: X-Milter: ClamAV 0.70/0.70kjel X-Milter: milter-regex 1.5jel X-Milter: ClamAV 0.70/0.70kjel X-Milter: milter-regex 1.5jel hi, looking at that discussion about MP, i remember one idea i've got some time ago, i would to know your opinion on that: we know how it's tos/gem with supervisor. it's the matter of one system call and voila, we're in supervisor, we can do anything we want, change the palette, set interrupts, rewrite operating system:) And since we want to keep the compatibility with original TOS, we can't forbide to switch to supervisor to any application, right? (there are even some things that cannot be done without SV). So, the idea: what about coding 'fake' sueprvisor handling? Let's repeate, why we would need to switch to SV: 1. to access to hw regs (DSP, MFP, palette, ...) [high memory] 2. to access to low memory (vectors, exceptions, os variables, interrupts) as far as i know, there's no other reason, why should application switch into SV. Every average coder is able to catch trap exception. So what we are waiting for? Application calls SV. OS gives back "OK status" + fake ssp. Applications now "thinks" it's in SV. (or do you know the app which checks the sr to be sure? ;-) So... we modify mmu to allow(!) access to low/high memory also in user mode. (this can be configurable, some kind of security levels). And the rest -that means parts of OS and another apps- will be still protected. There could be also some kind of "system restore" after possible program crash - simply we save old values of system vectors for example (a lot of possibilities here) I think we can expect that interrupts that sets the app will be handled by this application correctly (if not, system crashes and this happens under TOS, too and we can't do anything with that except to stop the using that app :) Any opinions why it shouldn't work? ;-) apropo, mmu: i guess mint uses own mmu tree? since i'm owner of ct60, there's a modified mmu to keep the compatibility with old TOS+030. So I see "modified mmu" warning and i'm not able to switch under MP. Why we can't replace it? After reset mmu sets to its default status, so i don't see any problem. but maybe i miss something here, if you can give me an explanation someone, thank you in advance. -- --------------------------------------------------------------------------- MiKRO Atari XE/XL/Mega STE/Falcon060 http://mikro.atari.org ---------------------------------------------------------------------------