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 4:12 PM
> To:	MiNT mailing list
> Subject:	RE: [MiNT] XaAES / GEM memory issues
> 
> 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.
> 
Me too, but you can't escape the fact that this is something that
*traditionally* doesn't belong in the GEMDOS. So adding GUI-related
functionality to this layer ("layer" in the sense that it runs inside the
kernel) doesn't break the design any more than the device-interface does.
>  
> > 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'm not so sure about that. I personally prefer loadable modules as well,
but it's not always something that can be used with the current design of
FreeMiNT. I don't know what Frank has in mind re. "kernel modules" though,
perhaps this is something that can be used to add functionality not covered
by the traditional filesystem/device modules.
>  
> > 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
> 
Not really, because this can be used to allow legacy code to run even with
the old AES API.

> another way, which I will not repeat because I already wrote it twice and
> Vincent alto several times :-)
> 
I believe it's possible to use the parameter block and still do it in a
clean way. Since the parameter block is local to each application, and the
AES is always called through the user mode library (it must be so to make
any sense), any data the kernel module may need can be sent by the library
using proper methods. I haven't studied this closely, so I might have missed
something obvious, but I believe it can be done. In fact, I don't think the
central server/kernel module would need to access the parameter block at
all. Only the library should need this.

But this ofcourse means that the AES library must run in the context of the
calling process, I assume this is what we're been talking about all the
time? If not, I have completely misunderstood this and made a fool of
myself... ;-)

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.

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