RE: [MiNT] XaAES / GEM memory issues

["Konrad M. Kokoszkiewicz" <draco@obta.uw.edu.pl>]

> > This only means that the top application, which received the event, must
> > reroute the event to proper place after discovering that there is none of
> its windows at the place where the user for example clicked. Still this
> can be done by the event library (running in user context) and there is no
> need to put all this into the device driver. 
> 
> But this means that there is no performance gain - the entire idea of doing
> this inside the driver is to reduce the number of context switches. By

Well, no. The application receives the event not sooner than the scheduler
grants time to it. You gain nothing putting this into the kernel,
moreover, you loose something, because the CPU spends more time in 
supervisor mode and this delays context switches.

> moving this functionality outside the driver again you basically have XaAES
> today...

Except the XaAES requires the same hack as N.AES, i.e. F_OS_SPECIAL flag,
to work with memory protection. Once I realized that, you may be sure
that I also was extremely disappointed.

In these terms XaAES is purely traditional AES.

--
Konrad M.Kokoszkiewicz
mail: draco@atari.org
http://draco.atari.org

** Ea natura multitudinis est,
** aut servit humiliter, aut superbe dominatur (Liv. XXIV,25)
*************************************************************
** Taka to juz natura pospolstwa, ze albo sluzy ono unizenie,
** albo bezczelnie sie panoszy.