RE: [MiNT] XaAES / GEM memory issues

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

> > 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.
> > 
> I'm not talking about GEM either. I'm talking about some very basic
> GUI-functionality which isn't AES-specific, but which can be used by an
> AES-implementation that runs entirely in user space.

This I can accept :-)

> I can't see how this is
> less relevant to Atari users than cryptography or BOGOMIPS, to mention two
> of the new features added to MiNT.

BogoMIPS value is not a pure visual stuff, this serves for allowing device
drivers to make microdelays (= delays measured in single microseconds).

The crypto layer is a nice feature, however, the problem with it is that
no context switch can occur when the data get decrypted. It would be nice
if someone could do something with it, because this will not be fixed even
if we had background disk I/O.
 
> And what about device drivers? Hardware drivers is traditionally the BIOS'
> domain, but we have several in MiNT.

In the MS-DOS like world, yes. TOS is originally a BIOS plus Digital
Research DOS; the entire Atari ST design, with such an OS, and plus PC GUI
(at the time it wasn't known that GEM will not survive on the PC platform,
just to remind), PC floppy drive and PC keyboard seriously looks like a
68000 IBM PC. Just better. Being back to the main theme, it is quite
logical that we have a BIOS and this manages low level device drivers.
This is just a heritage we have.

MiNT just replaces this stuff with own device driver layer, which is
better, more flexible, and multitasking friendly. Being Unix-like, MiNT
can manage device drivers, because Unix basically manages all (well,
most) of its resources as filesystems. Thus we also have biosfs (/dev) and
devices appearing as pseudo files. I personally like this way much more
than BIOS-style.
 
> > To be strict, this makes a big difference.
> > 
> Very true. But it's impossible to decide which to use now, especially since
> there is no such thing as a "kernel module" yet.

I meant, that statical linking is completely unacceptable.
 
> > 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
> > 
> So you're saying that the possibility to allocate memory as global readable
> (and/or writeable) must be removed. This looks really promising for us
> desktop users...

No, this is something else. Although (this is different topic) I
personally think that new applications should avoid allocating global
memory, and should be designed so that private memory is OK. This
obviously applies to protocols as well.
 
> It can. The parameter blocks can simply be put in global memory (for legacy
> binaries) or simply be omitted (for new code).

But this means that application's TEXT/DATA/BSS space should be forced to
global first. This is not a good thing, especially when it can be solved
another way, which I will not repeat because I already wrote it twice and
Vincent alto several times :-)

> > the access rights owned by N.AES for example are higher than MiNT itself
> > 
> Can you explain? I don't know much about the OS_SPECIAL (or whatever it's
> called) mode.

I can. F_OS_SPECIAL allows the AESSYS process to access the application's
private memory. It is a flag, which basically allows it to override the
memory protection, and write to ANYWHERE, except free memory. This is very
dangerous, and if you want an example, load Devpac 3.10 editor into N.AES,
load a program into it and compile. You have very good chances to freeze
your machine solid, because the Devpac editor somehow fools the AES to
write into the area where system vectos are, and the AES, with its special
privileges, obviously can do that, and does.
 
--
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.