[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] XaAES / GEM memory issues



Hi,

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

And that is _exactly_ my point as well! I only say that you must think
about the keyboard related TOS calls as well as the VDI. The bottom
line: We need a keyboard/mouse device driver that is always used to
manage the keyboard no matter if the application use TOS, VDI or AES
calls.

Last time I checked, although quite some time ago, MiNT relied on TOS
for keyboard input. It wouldn't be that hard to use the AES/VDI device
driver instead. It is certainly possible to rewrite fVDI to use such a
driver or am I wrong Johan?

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

I couldn't agree more and I never said the AES should steal any
interrupt handler.

Best regards
 Sven