Re: [MiNT] XaAES / GEM memory issues

[Johan Klockars <rand@cd.chalmers.se>]

> About XaAES/AESes:
> 
> In the oAESis project we have had this concern too. To give (some of) the AES's 
> functions ability to write into other applications's memory, we had the idea of 
> implementing those functions in a device driver. It also lets the MiNT kernel 
> deal with mutual exclusion (instead of having semaphores like in XaAES), but it 
> involves more communication and the debugging is not very convenient since a 
> crash means a reboot. (so yes, with this the AES can make the whole system go 
> down).

Now that you mention it, I remember hearing about this before.
I didn't think of using a device driver when I was working on XaAES, but it
even if it works, it seems like a kludge. And as you say, debugging could
be quite unpleasant.

> FYI, oAESis 0.91 can use communication via sockets (instead of pipes in XaAES) 

I considered that too, since the current (or perhaps not (I haven't checked
if Henk has modified this)) scheme in XaAES limits the number of GEM
processes to the number of file handles you can fselect on, IIRC.

> or Pmsg() between the bindings ('shared lib') and the trap #2 handler 
> ('server'). But the Pmsg-based comm is not MP safe since the messages carry 
> pointers on non-shared memory zones. Christer Gustavsson is aware of that, but I 

I seem to recall having some other problem with Pmsg, but that might just
have been a performance issue.

> The idea is that as many functions as possible should run in the user domain 
> (thanks to the shared library) and that just the rest be performed by the AES 
> server.

That is what the 'direct calls' are about, but if there was only the server,
there would be no need for any other synchronization...

> Another point is that the VDI would have the same problem when passing MFDB 
> structures.

fVDI currently doesn't try to do anything 'smart' when it detects that it
is running under MiNT, except for allocating memory differently.
It is always running in user context and therefore has no trouble accessing
anything. Also, unlike the AES, it doesn't provide user access to any
internal structures (which resources are, in a way) and has no 'call-backs'
(like userdef objects (I guess the mouse vectors and such are somewhat
similar, but I don't do anything about those so far)), so those kinds of
problems don't really occur.
There are some global things, though, like the VDI handle table and 
non-true colour palettes, which I'd be happier if I could protect.

As for the AES and resources, I would have been much happier if the user
had not been able to modify (or even create) MFDBs on his own.
In the RageII driver I try to cache memory blocks on the graphics card, but
some programs insist on doing 'bad' things that causes this to fail. It
works nicely for most, though, and can give very significant speedups.

> Also, the VDI doesn't use /dev/mouse to read mouse events, and does not provide 
> anything for the AES to Fselect on. (That's why the Moose exists, and oAESis has 
> the same thing).
> how does fVDI manage the mouse ? and the keyboard ?

For various reasons, it doesn't, so far.
All keyboard/mouse calls are simply passed on to the previous VDI (which
causes some other problems, but nothing bad enough that I've decided to
do anything about it yet).

> Is the format returned by /dev/mouse standard ? Do you know of any application 
> using this device ? Johan, what about using /dev/mouse and /dev/kbd to retrieve 
> mouse events into fVDI ?

I could certainly do that, once I get around to implementing those functions
at all (perhaps someone else would like to?).

> IMHO, a clean VDI is the first step to have a clean GEM, and the FreeMiNT kernel 
> now provides (almost :) ) everything required for a clean graphic system, so 
> let's move on !

Perhaps it would be a good idea if everyone involved in AES and VDI
development 'got together' and discussed these matters?

-- 
  Chalmers University   | Why are these |  e-mail:   rand@cd.chalmers.se
     of Technology      |  .signatures  |            johank@omicron.se
                        | so hard to do |  WWW:      rand.thn.htu.se
   Gothenburg, Sweden   |     well?     |            (fVDI, MGIFv5, QLem)