Re: [MiNT] fVDI issues

[Johan Klockars <rand@cd.chalmers.se>]

> >From my side it's planned to extend the kernel with a generic syscall
> handler for AES/VDI syscalls and a way to attach management data directly

I hope you'll talk to those of us who are involved in writing VDIs and
AESes before deciding on something overly general?
I suppose it's not much of a problem for an AES, but there are lots of
tiny VDI functions being called all the time, where any extra overhead
'hurts'.

For example, something like vsl_color is about a dozen instructions
of actual work in fVDI. Even with a minimal VDI dispatcher, there are
already two dozen instructions of 'overhead' on top of that (saving
only two registers on the stack).

Also, note that unlike for most other OS functions, the VDI (and
probably the AES) is very well suited to a single point of entry, where
lots of common functionality can be taken care of.
If you're interested, I can send over, or post, the code for the current
fVDI function dispatcher (as has been mentioned, my CVS server is
currently down).

> to the process descriptor. So a VDI/AES module only need to register the
> system calls and can attach process specific management data.

What you call 'process specific management data' sounds exactly like
what I want. If it can be taken care of by your 'generic syscall handler
for AES/VDI syscalls' (extremely lightweight, please!), that's OK.
But perhaps other kinds of kernel modules could make good use of the
same functionality?

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