[MiNT] XaAES / GEM memory issues

[Vincent Manuel Barrilliot <vbarr@cme.nist.gov>]

Hi,

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

FYI, oAESis 0.91 can use communication via sockets (instead of pipes in XaAES) 
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 
am not sure if it is fixed yet.
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.

Another point is that the VDI would have the same problem when passing MFDB 
structures.
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 ?

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 ?

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 !


Vincent