Re: [MiNT] XaAES / GEM memory issues

[Sven Karlsson <svenka@it.kth.se>]

Hi again,

> > using device drivers:
> >  1. ACIA interupt occurs and is handled by the device driver
> >  2. The device driver wakes the waiting AES up. (one context switch)
> >  3. AES decides which application should get the event and wakes that
> > application up. (second context switch)
> 
>  This seems to be the only solution in my opinion....

It is the way XaAES, correct me if I'm wrong Henk, does it. The problem
is however that there are an awful lot of events coming out of the
device. Most of the time for no reason as the device do not know if the
AES is interested in all mouse events. Correct me, Henk, if this has
been solved since I looked at XaAES. It do not now if any AES client is
interested in them. Filtering events directly into the device driver
would reduce the traffic and synchronization drastically and increase
performance! And you can still use all kinds of shared memory tricks to
speed up the AES further. 

However in order to implement the filtering, the device driver must know
about the various AES applications, the location of their windows and
the events they are waiting for. The reason for this is simple. It needs
to know the identity of the top application or the location of the
windows depending on if events should go to the top application only or
to the application whose window is currently under the mouse pointer. So
in order get an efficient filtering I propose this handling should go
into the device driver.

I'll say this again for the last time in another way. I'm proposing to
move _all_ central AES handling as well as all mouse and keyboard
handling into the kernel using for instance a device driver so that the
rest of AES is completely in user space and cannot kill any other
process if memory protection is enabled. Let us call this device driver
A.

So when implementing an efficient AES event handler you would get the
bonus of being able to put the rest completely into user space.

Splitting the AES into three portions, one device driver, one "AES
server" and one user level library would only introduce unnecessarily
overhead. Using a device driver and a AES server without a user level
library is basically what we do today and we do have memory protection
problems. Splitting into a user level library would help quite a bit!

The gemdos and bios calls should use driver A as well and will of course
ignore the mouse and AES events. However if any AES application is
started, i.e., done a appl_init, A won't send events to any Gemdos
process unless they have done an appl_init. It is true that Gemdos wont
get any events once AES has started but it is the same thing today. Once
AES has started it grabs all events and you must put Gemdos applications
in a GEM window with TosWin or similar applications.

In the case of VDI the VDI could request permission to use the keyboard
or mouse when a process opens a workstation. Of course, events should
not be delivered if another process has done an appl_init. Once a
process has done an appl_init it can use both AES and VDI functions to
read the keyboard and get the mouse position. These can be interleaved
without problem. Provided you have a controling tty you could also use
gemdos and bios calls.

So in short either:
* one gemdos/bios process at a time could get the keyboard as controling
tty (like today)
* or one process using VDI calls (don't really know if this is handled
in a sane way anywhere today)
* or many AES applications (like today)

So things would be as usual minus the chance of AES killing other
processes.

> VDI/AES, I don't think the second would be a good option at all. Or it
> could be that I have misinterpretated things badly...

Given what you write above I think you have. See my text above. Using
the device driver A you will get rid of all AES functionality that would
need synchronization into one convenient place and you can put the rest
in a user level library. All event filtering is done in the device
driver which makes the event processing very efficient. With this the
AES cannot kill another application unless there is a bug in the device
driver A.

This is one way of putting the AES into user level. There are of course
others. But this is the most efficient one I can think of. Of course you
do not need to agree but I still believe that the arguments speak for
me.

Correct me if I'm wrong but doesn't the MiNT kernel still rely on the
TOS for keyboard and mouse input? Wouldn't using a device driver like
the one proposed eliminate this TOS dependency?

Also if someone so not quite understand, please ask instead of reading
between the lines and assuming something I haven't written or intended
at all.

Best regards
 Sven