Re: [MiNT] fVDI issues

[Xavier Joubert <xavier.joubert@free.fr>]

Hi Konrad !


Selon Konrad Kokoszkiewicz <draco@obta.uw.edu.pl>:
> 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