[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [MiNT] XaAES / GEM memory issues
> > 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
> >
> There's no reason *not* to implement basic GUI-stuff in the kernel, since
There is. Like it was several times pointed out, we should not mix GEMDOS
with GEM. MiNT is GEMDOS, AES is GEM. These are two different layers
sitting on two different levels, where the GEMDOS is lower one.
> Whether to statically link this or load it as a kernel module or device
> driver I really don't care.
To be strict, this makes a big difference.
I may be wrong, but I feel that - apart from anything else - the will to
incorporate AES - or parts of it - into MiNT is caused by an assumtion,
that such an incorporation will make the method of accessing the parameter
arrays by GEM (overriding memory protection) more legitimate. No way. This
is a hack and this will remain a hack eventhough the king of Saudi Arabia
comes and states otherwise. :-) Even if there would be made a decision
about the incorporation to be done, the AES should be *first* redesigned
in the way that allows it to operate without special privileges; currently
the access rights owned by N.AES for example are higher than MiNT itself
has. This is sick situation and results in sick behaviour during problems.
--
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.