Re: [MiNT] Future (was Re: MiNT 1.16)

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

> > There's no real need for a Trap to be slow. The trap itself is about
> > 30 cycles on a 68000, 20 on an '030 and 16 on an '040.
> 
> I know. But I also know what procedure MiNT has behind a trap and this,
> eventhough isn't really slow, isn't the fastest either. Anyways, as Frank

100+ instructions minimum overhead (for GEMDOS calls) doesn't matter for
most things.

It does matter for the particular case we were talking about here
(privilege checks in a library that gets called a lot) as well as for
some types of inter-process/thread communication/synchronization (which
was what I was concerned with when I last looked deeply into the MiNT
kernel), though.
Of course, we don't have any of that right now, but that might be
precisely because the current MiNT kernel isn't well suited for it.  ;-)

> suggested, having VDI as XDD module would give it faster access to
> appropriate internal structures, and there is no real need to create
> special backdoors for auto programs or whatever.

True.

> > By the way, I'm somewhat surprised that noone has done anything about
> > the calling methods. After all, there are lots of free traps that could
...
> The current interface is satisfying in my opinion. But if you have better

Well, it works, and for the vast majority of applications probably even
fast enough.

> idea, please stop to be surprised :-) and go ahead with a proposal.

;-)

I might if I ever actually use MiNT again. As it is, I don't think I've
even booted with it for at least six months (the only thing I do with
my Falcon is fVDI development, and multitasking interferes with my
debugging efforts).

> > > This is the problem of answering the question, whether we want MiNT to be
> > > a complete self-contained OS, or rather we want it to rely on underlying
> > 
> > Why would anyone want that?
> 
> Why anyone would want what?

'MiNT to be a complete self-contained OS'.

Depends on how you define that, of course.

> > And an AES and a desktop, I presume?
> 
> You presume wrong.

Well, definitions do vary.

So, you think a 'complete self-contained' MiNT should include the
kernel, drivers for various kinds of hardware, and an application
level graphics library (and a badly designed one at that)?

I would not want to force the VDI on anyone, and MiNT can work just
as well with, for example, X on top of it if you want graphics.


I'd rather have the VDI 'engine' running as a user mode library, with
kernel calls where necessary (for mutual exclusion, for example)
and a 'server' task to handle global things (such as the mouse pointer).
Each task would have its virtual workstation structures allocated in
its own memory space.
(Incidentally, this is how fVDI is/was to work under Fenix.)

Some kind of kernel level driver could be responsible for actual
drawing operations. I have not looked into how the various Linux etc
frame buffer interfaces work (but I would not want to allow direct
screen access at all), but something similar to the current fVDI
device driver interface would be fine (it is, for the most part, not
dependent on fVDI at all).
Since GEM, unfortunately, does not place screen area (window, rectangle,
region, or whatever you want to call it) protection under the control
of the graphics library, drawing could actually be done from user space
code too without (other than the normal) ill effects.

-- 
  Chalmers University   | Why are these |  e-mail:   rand@cd.chalmers.se
     of Technology      |  .signatures  |
                        | so hard to do |  WWW:      http://217.215.149.49
   Gothenburg, Sweden   |     well?     |            (fVDI, MGIFv5, QLem)