Re: [MiNT] fVDI issues

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

>> Well, no, I asked about advantages when compared with the idea of
>> user-space AES libraries.
>
> The AES routines and data are protected from the user programs,

You mean that these will be protected equally as the kernel itself, right?
Which is currently unprotected (and you yourself moved the question of the
kernel protection to the "not-must" section of the todo list :-)).

> you
> don't need a complex synchronization between the AES processes,

There is no need for greater extent of synchronization than it must be done
by the screen manager.

> and
> finally you don't need a complex backward compatibility module the
> AES programs
> that catch the trap#2 and redirect this to the user process

The module I described is not complex. It would have almost as much
assembler instructions as there are points in which I described what it
should do (see my reply to Xavier). It is very simple task.

> (I'm sure
> that most programmers want to run their programs on FreeMiNT and
> MagiC [and
> some on TOS too]).

Yes, this is why I wrote that gemlib should only use new interface (assuming
there will ever be new interface at all) when the new interface is
available. This would ensure that "new" programs will still work under TOS.

>> The advantages you enumerated are (in my view) mostly similar
>> for both, except that the size of the kernel would not be so
>> dramatically enlarged.
>
> You still need a complex synchronization, not to mention how you
> handle global data.

What is "global data"? The list of all windows created by all applications?
The rectangle lists? This is all to be done by the screen manager, I
suppose. Which *may* be a kernel module/thread for convenience, but it also
might be an user thread (but MiNT has no user threads and Pexec(104) seems
somehow broken).

> This is as the existing AES simply don't see the fork. The same is
> true for the user level library you propose.

Well, no, not exactly. The problem is, that the AES, when reading/writing
the application global array, never knows, whether the DATA/BSS is the one
of the parent, or the one of the child. When the parent has created the
child with fork(), that is. This is so because the AES is a separate
process, which runs asynchronously to the two. A library routine is not a
separate process, so there would be no troubles I suppose - always the
proper DATA/BSS would be accessed.

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