RE: [MiNT] XaAES / GEM memory issues

[Jo-Even.Skarstein@vital.no]

> -----Original Message-----
> From:	Konrad M. Kokoszkiewicz [SMTP:draco@obta.uw.edu.pl]
> Sent:	Wednesday, January 10, 2001 3:28 PM
> To:	Skarstein, Jo Even
> Cc:	mint@fishpool.com
> Subject:	RE: [MiNT] XaAES / GEM memory issues
> 
> > 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.
> 
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. 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.

And what about device drivers? Hardware drivers is traditionally the BIOS'
domain, but we have several in MiNT.

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

> 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
> 
It can. The parameter blocks can simply be put in global memory (for legacy
binaries) or simply be omitted (for new code). Synchronization and events
will be handled by the kernel module, everything else by a user mode
library. This will even make userdefs perfectly legal and clean.

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

> has. This is sick situation and results in sick behaviour during problems.
> 
And it can be fixed.

Jo Even Skarstein

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

This email with attachments is solely for the use of the individual or 
entity to whom it is addressed. Please also be aware that 
Vital Insurance/DnB Group cannot accept any payment orders or other 
legally binding correspondance with customers as a part of an email. 

This email message has been virus checked by the virus programs used 
in the Vital Insurance/DnB Group.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *