From fnaumann@mail.cs.uni-magdeburg.de Sun Jan 25 15:37:49 2004 Date: Sun, 25 Jan 2004 15:34:57 +0100 From: Johan Klockars To: mint@fishpool.com Subject: Re: [MiNT] fVDI issues Message-ID: <20040125143457.GA3069@haddock.cd.chalmers.se> References: <20040122144133.GC17739@haddock.cd.chalmers.se> <00d401c3e198$9a156d80$0e0a63d9@blaszak> <20040123191858.GA28238@haddock.cd.chalmers.se> <20040124160439.GA24271@haddock.cd.chalmers.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Delivered-To: mint@fishpool.com Delivered-To: mint@lists.fishpool.fi X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: rand@cd.chalmers.se Precedence: bulk List-help: List-unsubscribe: List-ID: X-List-ID: > > Perhaps it would be a good idea if the VDI and AES developers talked > > a bit about what we want/need from this kind of functionality in MiNT? > > And, of course, it would be good if the MiNT kernel developers could > > describe what thoughts they have about this kind of interface. > > The idea is that it integrate the VDI and AES easily into the kernel, not > to make anything harder :-) Sounds good so far. :-) > > > Entering the kernel is an expensive operation, also for routines that just ... > > So, at least for the VDI, fully entering the kernel (build_context etc) > > is not really an option, IMHO. > > The kernel entering is not only done for fun, there are requirements to > fullfill. Of course. But going through the entire build_context thing is completely unnecessary if you will return to the same process again. Obviously you need to do it if you're not going to return, though, but IMHO that should not be the default assumption (certainly not always). > > Many often called VDI routines can make do with only a couple of > > registers saved on the stack. None of them pass any parameters on the > > stack. None of them, AFAICR, would have any reason to ever require a > > process to suspend. > > Can these simple calls put into user space? E.g. does they work without > any hardware access and without any critical, VDI global data? Lots of functions can make do without write access to global VDI data, but many things will require read access to it (to check their parameter values against min/max for the device in question, etc). I _think_ almost everything that does not actually access hardware or create new physical workstations should be OK with only read access to such data. And the functions that are left should mostly be things that will take quite a bit (relatively speaking) of time. > > Actually, it would make sense to make parts of the VDI actually execute > > in user mode. It's unfortunate that we're stuck with the Trap #2. > > But you need to go back to userspace after the Trap. I'm not sure I understood what you meant here. But it is obviously possible for the VDI implementation to, for some functions, return to user mode without actually returning to the caller, and thus do most of its work in user mode. Definitely a very good idea whenever possible under MiNT, since it would allow multitasking to continue unhindered, and it would also take care of at least some of the potential memory protection problems. -- Chalmers University | Why are these | e-mail: rand@cd.chalmers.se of Technology | .signatures | | so hard to do | WWW: http://www.klockars.net Gothenburg, Sweden | well? | (fVDI, MGIFv5, QLem)