Re: [MiNT] fVDI issues

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

Yes, it doesn't. However, there are those Magic SLBs. I already heard a lot
on how a crap is this, why it cannot be called a shared library, but "at
most a kind of shared code", and so on. Such arguments are usually
reasonable, because e.g. an SLB and a process that call it cannot share
common DATA/BSS segment, i.e. the library is in fact not "linked" in any way
to the process that wants to use it. Also the calls are slower, than a
simple jsr. And so on.

However, none of the things the real shared library has, and the SLB lacks,
is needed by the AES. So (most of) the AES can perfectly be an SLB, the
calls made by new programs could be a lot faster than current AES trap
dispatcher, and it would be all done in user mode. Moreover, the emulation
code for old programs would be in my view less kludgy, than the one you have
described, and it would not need any new special AES/kernel calls to be
added.

Also the AES would no more be a process that hooks onto exception vectors
(trap #2 is an exception, right? :)). The trap #2 vector would be taken by
the kernel, thus there would be no danger, that the AES suddenly dies and
the vector will suddenly point to invalid memory.

I suppose that the idea you have described is exactly the same as mine, but
again, there are already mechanisms inside the kernel that could help to
avoid so much hacking as you propose. No matter how we "hate" the SLB idea
and implementation, as long as it is there and it can be used for something
useful, we should use it.

Let me write a bit more about it. An SLB is simply a binary executable that
consists of functions thrown into its TEXT segment. The TEXT segment of an
SLB is "executable" for every process that have opened the SLB (this is
yours "making AES code executable for everyone", but except non-GEM
programs). The entry point to the SLB functions is provided to the process
by the operating system as a result of the system calls that causes the SLB
to be opened (Slbopen(), actually). So we are done with this as well, no
hacks.

The current implementation (in the 1.16, that is) provides a different entry
point to the same SLB for different processes. In other words, each process
owns a piece of user code, that serves for SLB handling (and for some other
things too). This is shortly called "trampoline". It is private-protected.
The same space can be also used as a part of the trap 2 emulation dispatcher
for old programs. Specifically, for the part that will switch from supermode
to user, etc. The trampoline is "visible" from the inside the kernel, since
the proc structure contains a pointer to that area.

The trap 2 emulation dispatcher (for use by old fashioned programs only)
would consist of two parts:

1) the part running in supervisor mode, hooked onto trap #2 vector and
intercepting AES calls.

This would actually:

- fetch the pointer to the second part of the dispatcher residing in the
user memory (= trampoline);
- jump to the address pointed to by the pointer;

Notice that we don't go through all the context routines. This is not
necessary in this case IMHO, since we'll leave the super mode straight away
and at the other hand stay in the same user context.

2) the part residing in user space:

- pop the return address off the supervisor stack;
- switch to user mode
- push the return address onto user stack :-)
- call the AES SLB normally (i.e. the way the "new" programs would simply do
it without going through trap #2)
- return to user (RTS)

I suppose that the emulation code described would be actually equally fast
(equally slow) as the actual trap dispatcher (so there is no speed loss for
them), and for new fashioned programs the procedure would be greatly faster.
I'd suppose that gemlib could solve the problem of using the new interface
when available.

Also we get rid of double process management (kernel's one and AES's one)
because every process will in fact "manage" itself, its memory structures
etc. and the rest will be managed by the kernel as it is now in case of all
processes.

Of course, also the screen manager would have to be built into the kernel
(or better loaded as a module), so there's a question of designing a
protocol so that the library routines could program, wait for and receive
events etc.

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

** Ea natura multitudinis est, aut seruit humiliter, aut superbe dominatur.
** Taka to juz natura pospólstwa, albo sluzalczo sie plaszczy,
** albo bezczelnie sie panoszy. (T. Liuius XXIV, 25).