From mint-bounce@lists.fishpool.fi Wed Dec 9 10:57:14 2009 X-Authentication-Warning: antyk.ibi.uw.edu.pl: draco owned process doing -bs Date: Wed, 9 Dec 2009 16:20:08 +0100 (CET) From: Konrad Kokoszkiewicz To: Vincent Rivi?re cc: mint@fishpool.com Subject: Re: [MiNT] XaAES sources for FreeMiNT 1.16.3 Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (antyk.ibi.uw.edu.pl [127.0.0.1]); Wed, 09 Dec 2009 16:20:08 +0100 (CET) X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: draco@ibi.uw.edu.pl Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: > The TRAP API (like any other TOS system call) is very inefficient, and the > VDI/AES is probably the worst. A new API, directly from the user programs to > the VDI implementation would be far better, there is no doubt. > > But why the VDI would have to be a kernel module ? Most of its work is to > draw in the video memory, there is no need to switch to supervisor mode and > play with the hardware or kernel internals to do that... Heh. Everything needs to be a "kernel module" because a kernel module sounds cool, and besides it runs in "supermode", which sounds even more cool. Once, before XaAES became the kernel module, I tried to convince the list that implementing the AES as user-space libraries would be better. I haven't been even understood: I wrote "user-space libraries", and the readers read something like "client-server architecture" - consequently I got replies completely irrelevant to my suggestion (such as "client-server architecture is inefficient" or "it was implemented in XaAES before[1]" etc.) [1] there was an API in a version of XaAES which used MiNT pipes to transfer messages between the app and the XaAES core, or something like that. Pozdrawiam KMK