From fnaumann@mail.cs.uni-magdeburg.de Tue Jan 27 10:02:32 2004 Subject: Re: [MiNT] fVDI issues From: Petr Stehlik To: mint@lists.fishpool.fi In-Reply-To: <03d701c3e4af$accb24f0$0e0a63d9@blaszak> References: <20040122144133.GC17739@haddock.cd.chalmers.se> <00d401c3e198$9a156d80$0e0a63d9@blaszak> <20040123191858.GA28238@haddock.cd.chalmers.se> <20040124160439.GA24271@haddock.cd.chalmers.se> <035f01c3e333$a67d1b80$0e0a63d9@blaszak> <03d701c3e4af$accb24f0$0e0a63d9@blaszak> Content-Type: text/plain Message-Id: <1075193841.3713.14.camel@joy.sophics> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Tue, 27 Jan 2004 09:57:21 +0100 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p5 (Debian) at sophics.cz 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: joy@sophics.cz Precedence: bulk List-help: List-unsubscribe: List-ID: X-List-ID: On Tue, 2004-01-27 at 09:28, Konrad Kokoszkiewicz wrote: > >> Yes, the same for the AES. Ideally, the AES should be a bunch of > >> shared libraries executing completely in user mode, plus one screen > >> manager process, perhaps. This would solve memory access problems to > >> a great extent, I suppose. > > > > Maybe. But you still have the problem to go back to usermode after the > > process has trapped (e.g. entering kernel -> leaving kernel). > > This is why I agree with Johan's statement that the fact that we are stuck > with trap #2 is quite unfortunate. Theoretically we can design a new standard for AES/VDI under FreeMiNT. Say that there would be a FreeMiNT with "integrated" AES and VDI that would not use the TRAP #2 but would call themselves directly. The next step would be to enhance some most used GEM libraries to allow using this FreeMiNT direct (avoiding TRAP #2) access to AES and VDI functions (if it is available, otherwise falling back to proven TRAP #2 and so keeping compatibility with TOS and MagiC). End user applications would need no change - users would just upgrade their *gem.slb. The TRAP #2 AES/VDI entry would still be used for old apps as a safe fallback but applications built on modern GEM libraries would fly with speed of light. Petr