[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] XaAES / GEM memory issues
Hi,
It is clear that I wasn't precise enough.
> And to handle the ACIA interrupt, AES process muist steal the interrupt
> vector and point it to own TEXT segment. Thus the text segment must be in
> supervisor accessible memory (1), and when the AES dies, the vector starts
> to point to invalid memory and the system crashes down when next ACIA
> interrupt occurs (2).
>
> No, thanks. We exercised this too many times already.
I never said that the entire AES should be in kernel mode in any way.
I'm only suggesting that the keyboard and mouse handling part of AES/VDI
is moved into kernel mode. This includes:
* Mouse and keyboard handling
* Cliprectangle handling
* handling of window locations
This is a very small piece of code. Naturally there will possibly always
be bugs in software but you can never avoid that even in device drivers.
All suggestions so far all in some way suggests using special mouse or
keyboard device drivers. I cannot see the difference.
The portion of AES that displays objects and windows should never ever
be executed in kernel mode and my suggestion avoids that with very low
overhead. It does not break any of the memory protection schemes in MiNT
or any other OS with memory protection. As Henk and others pointed out
more than 90% of the AES code and certainly more then 90% of the VDI
code can be put entirely in user space. I suggest the rest and _only_
that is put in kernel space which in MiNTs case would suggest a device
driver. (In Fenix it would mean a server in kernelmode as it is a exo
kernel with microkernel features.)
However, in practice all AESes available today and that I know of is
executing in "kernel space" as they override memory protection.
Best regards
Sven