Re: [MiNT] XaAES / GEM memory issues

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

> Btw. you can simply avoid the context switches if you integerate the AES
> into the kern itself (or at least the syscall handler and the event
> manager that dispatch between the AES tasks and the AES server).

No, don't. So far we have a kernel which is less or more independent of a
gui, and no type of a gui is favourized. While the AES gets intergrated
into the kernel we:

1) loose the freedom of choosing a gui, because the kernel will favourize
one
2) we will have another microsoft windows.

I've already stated my point and will not repeat it, except for sucha
reminder: IMHO a proper AES should be just a set of libraries usable in
user context + a device driver (*explicitly* loaded as an XDD, no
hacks) which basically generates events.

Traditional AES design is bad, basically for example because no
application program (a clean one) should ever steal an interrupt vector,
because of the obvious reason (when the application dies, and it can die
any time because there is no misery in case of SIGKILL, the vector starts
to be invalid and the system crashes). trap #2 vector *is* an interrupt
vector. Perhaps in a single tasking TOSthis didn't matter, but in a
mulititasking system the design MATTERS if evertying that has to work
stable. Assuming the "traditional" solution, no AES will ever be safe,
eventhough it was really 100% bugfree, because killing it off will bring
the system down.

Thx,

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