Re: [MiNT] fVDI issues

[Frank Naumann <fnaumann@mail.cs.uni-magdeburg.de>]

Hello!

> > The AES routines and data are protected from the user programs,
>
> You mean that these will be protected equally as the kernel itself, right?

No, modules fall under normal memory allocation after the kernel is
initialized.

> Which is currently unprotected (and you yourself moved the question of the
> kernel protection to the "not-must" section of the todo list :-)).

Looking at the changelog ... the relevant change is from charon with the
following log message (I don't changed anything on this file at all):

revision 1.5
date: 2003/11/23 21:33:49;  author: charon;  state: Exp;  lines: +3 -1
marked the "not must"-stuff listed by draco

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

Sure, but you still need to detect a fork. Or you must fork all windows
and other elements on the screen too (e.g. requires special support by the
screen manager -> special kernel support; the same as I already wrote).

The AES processes are still registered somewhere on an central isntance
that manage the windows on the screen. Theses central instance must be
fork aware, it doesn't matter if the AES routines are a library or not.
This is the thing I meant with global data.


Ciao
   ...Frank

--
ATARI FALCON 040 // MILAN 060
-----------------------------------------
http://www.cs.uni-magdeburg.de/~fnaumann/
e-Mail: fnaumann@freemint.de