Re: [MiNT] fVDI issues

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

>>> Both have advantages and
>>> disadvantages.
>>
>> And what are advantages, when you integrate AES and the kernel? I'd
>> appreciate, if you enumerate it.
>
> Compared to the current design I see these advantages:

Well, no, I asked about advantages when compared with the idea of user-space
AES libraries. The advantages you enumerated are (in my view) mostly similar
for both, except that the size of the kernel would not be so dramatically
enlarged.

Of course I can be missing something important, that's why I am asking
opinions.

> But on the other side XaAES is already an problematic user process. As
> stated above it's not a 'clean' user space process and therefore use
> lot of tricks and hacks to reach some things.

Most probably. But I suppose, at least a part of these hacks are "necessary"
not because the XaAES (or N.AES or Atari AES) is an user space process, but
rather because it is a separate process at all. What is a difficult task for
a process (e.g. reading/writing the GEM arrays owned by GEM programs and
private-protected), is not difficult at all if a GEM program reads/writes
own arrays (i.e. when AES routines and the GEM program are both the same
context). There would be no more problems with fork() done by a GEM program,
I suppose, for example.

> In fact that means, if XaAES crash and don't exit gracefully you
> already have a problem in your system and with the stability.

See above.

--
CVV
Konrad M.Kokoszkiewicz, http://draco.atari.org

** Ea natura multitudinis est, aut seruit humiliter, aut superbe dominatur.
** Taka to juz natura pospólstwa, albo sluzalczo sie plaszczy,
** albo bezczelnie sie panoszy. (T. Liuius XXIV, 25).