From fnaumann@mail.cs.uni-magdeburg.de Wed Jan 28 23:11:50 2004 Message-ID: <1075326883.40182fa37b0c6@imp6-q.free.fr> Date: Wed, 28 Jan 2004 22:54:43 +0100 From: Xavier Joubert To: mint@fishpool.com Subject: Re: [MiNT] fVDI issues 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> <1075193841.3713.14.camel@joy.sophics> <07ba01c3e58b$26865ae0$0e0a63d9@blaszak> In-Reply-To: <07ba01c3e58b$26865ae0$0e0a63d9@blaszak> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.1 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: xavier.joubert@free.fr Precedence: bulk List-help: List-unsubscribe: List-ID: X-List-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by prinz.cs.uni-magdeburg.de id i0SMBno00398 Hi Konrad ! Selon Konrad Kokoszkiewicz : > Let's theoreticize: the code would have to reside in the application's > "memspace". The code behind the trap #2 would have to jump into it. Then the > return address would have to be popped off the supervisor stack (along with > the stack frame), and saved somewhere. Then the CPU would have to be forced > back into user mode (andi.w #~$2000,sr), dispatch the call, and either load > the library, or call one of its functions, or unload the library. And > finally go back to the application using the saved return address. The problem is that FreeMiNT doesn't support shared library yet. But I can see a way to get around this and begin to write a "user-mode AES". The basis are the same as your idea, but adapted to current kernel design : This AES is a program that will hook into trap #2, and then act as an event dispatcher. It would be also a container for user-mode AES routs, so it would have to set his text segment as executable for any process, and its data/bss as readable (I think all writes to the AES global datas should still be done in supervidor mode, but I may be wrong). Trap #2 would contain 3 different parts : - A new call that would allow programs linked against the new gemlib to get the entry point of the user-mode code. This would be called by the new gemlib when the programs do its appl_init() and the adress would be stored in the program bss (alocated by the new gemlib). Then the new gemlib would have to setup everything like for a current AES and then jsr to the entry point. - An emulation layer to allow old programs to work. If trap #2 is entered to call an "old" AES function, copy return adress on top of user stack, copy entry point adress instead of old return adress in the supervisor stack frame and RTE to execute user-mode AES. - New supervisor calls to let user-mode AES modify global parameters. Of course, this is a hack. But it would allow to begin port of AES to user mode today. Once FreeMiNT supports shared libraries, this is just a matter of changing the way we enter it. So this is a *temporary* hack. Comments ? Flames ? Maybe I averlooked something but at least I manage to avoid the "pointer in cookie" method to get the entry point address. But, thinking about it, getting it through trap #2 is not really better... ;) Regards, Xavier