Re: [MiNT] fVDI issues

["Konrad Kokoszkiewicz" <draco@obta.uw.edu.pl>]

>> 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.

I hope we all agree that the current situation is hm... unacceptable in
longer terms. I have no clear thoughts about VDI, but for the AES I think
that Atari have made a mistake hooking it onto trap #2. Or any trap, to be
strict. As a consequence we now have an AES running as a separate process,
which creates all sort of problems and enforces many kludges because the AES
designed so must have an access to other programs' private memory which is
normally not allowed.

However, I am unable to see any conceivable reason, why a good solution
would be to throw all the AES into the kernel space, integrate with FreeMiNT
and allow to run in supervisor mode. This would be a bad solution IMHO.

I see no reason nor any advantages of a situation when functions like
objc_draw() or fsel_exinput() should run in supervisor mode as a part of the
kernel. Honestly, I cannot even imagine the GEM fileselector opening and
waiting in supervisor mode for user interaction. This would be a nonsense.

These are functions that belong to an user library and they should run as
user code. Most of the AES is designed so. Its abstraction level is so high,
that it does not have to deal with hardware, nor any stuff that is
disallowed to deal with for an application. The AES is, practically,
hardware independent. So, to say it again, I can't see why it should be
integrated with the kernel and run with kernel privileges.

There are really few AES functions which need some support from the kernel
side. These are functions which belong to the event library, this is
wind_update(), which sets and resets a global semaphore allowing an access
to the screen. Maybe few others. But again, none of these needs to be a part
of the kernel. At last, this is the screen manager which generates most
events, and owns the screen semaphore. So the screen manager should perhaps
be a kernel thread, but nothing else, considering parts of the AES.

To say it again, the "correct" solution is to design a shared library that
would contain all AES functions. However, there is a problem what to do with
old programs, which use trap 2. Even if such a call could be converted into
a library call, it would be a big piece of kludgy code. At least, the
appl_init() would have to load the library, no? :)

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.

Theoretically possible.

--
CVV
Konrad M.Kokoszkiewicz, http://draco.atari.org

** Ea natura multitudinis est, aut seruit humiliter, aut superbe dominatur.
** Taka to już natura pospólstwa, albo służalczo się płaszczy,
** albo bezczelnie się panoszy. (T. Liuius XXIV, 25).