Re: [MiNT] AES in kernel

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

Hello,

Some time ago, I wrote a device driver (which sources I sent to Frank), which 
was taking the events generated by the Atari VDI (mouse movement, mouse buttons, 
20Hz timer)  and was making them available via a device /dev/VDIevents.
My intention was to allow an AES server (namely, oAESis) to Fselect on them.
The plan was to also make the keyboard events available through this loadable 
device driver.
Of course, other AESes would have been able to use it. (After all, there were 
just a succession of APP_EVNT to read from the device, nothing proprietary).

In that device driver, I had to use the VDI vex_xxx functions to get the events 
from the regular VDI, and Frank pointed out that it was not clean since the VDI 
is not supposed to be called from within a GEMDOS-level device driver. And he 
was so damn right that I gave up further developments. 

But it made me realize that the bad input devices management was due to a bad 
VDI design, that's why I switched my activities from oAESis to oVDIsis.

I also started writing a "AES server in kernel" as described by a couple of you 
guys here, about a year ago. The plan was to be an event dispatcher so that an 
application can send a request and block-Fread for a reply.
This could have also be done as a regular user process (like oAESis and XaAES) 
but this mean the "32 files limitation" and problems of mutual exclusion (I saw 
the semaphores in XaAES and got scared). I prefered let the FreeMiNT kernel deal 
with that, which it does perfectly.
The problem was that this "AES server" device had to get its events from other 
devices (eventually /dev/VDIevents), and I was not sure if this was legal or 
not.
Also I didn't have the debugging facilities so I gave this one up too.


To conclude, I agree with Frank/Draco, we shouldn't mix the GEM with the GEMDOS.
As fas as the GEM is concerned, input devices managements is up to the VDI, 
which the AES should use to get its events and dispatch them.
An AES in the kernel pauses the problem of being able to Fselect an VDIevent 
device, and also the system can be dragged down by a crashed AES. But it solves 
the problem of synchronisation, 32-fd limit and improves performance.

Vincent