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

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

> > As for integrating VDI and mouse accelerator, well. I have my mouse
> > accelerator in Clocky ;-) And fVDI (what else VDI would you integrate?)
> > is probably better on its own. At least Johan, its author, seems to like
> > the modularity better.
> 
> Yes, but the fvdi, IIRC, is loaded AFTER MiNT. This means, that MiNT

It's actually supposed to be loadable before or after MiNT.
I seldom use MiNT, though, so I'm not sure if both variants work at
this point.

As Frank suggested some time ago, I'll probably make it loadable as
some kind of actual MiNT kernel module ('fake' device driver or
otherwise) too.

> doesn't have control on the VDI trap. So, everyone who telnets to you, can

IMO, MiNT should take full responsibility for the Traps. That is, it
should not allow chaining of any kind, but rather use some mechanism
to distribute calls appropriately.
This, obviously, would mean that lots of software that modifies the
vectors would need to be changed...

> use your VDI, even if he's a restricted user. This is baaaad :-)

Privilege enforcement could be done inside fVDI, if necessary.

> Of course, this also applies to NVDI, currently.

And it's much more likely to continue to apply to that one.  ;-)

> Apart of that, I don't see why an 'integrated vdi' cannot be modular
> simultaneously. The integrated part would be just a VDI kernel (even fvdi

That depends on what you mean by 'integrated'.

IMO, the VDI definitely should not be part of MiNT (or any other
larger piece of code, for that matter). It could very well be a
loadable MiNT kernel module, though.

> has a kernel, right?) plus most basic driver(s). The rest would have to be

fVDI has an 'engine', which deals with everything except actual drawing,
and drivers which are responsible for the latter (the engine has
generic drawing functions that allow for drivers that only deal with
single pixel access, for example).
(Well, a driver can actually replace any VDI function it wants to
 handle by itself (on a per driver basis).)
I intend to make outline font handling a loadable module too, and
probably mouse/keyboard handling (which fVDI currently relies on
the original VDI for).

> > If we wanted to get rid of supercalls we would have to patch each and
> > every existing program. You have no idea how many programs run an FPU

Well, to some degree I believe it should be possible to get away
with a virtualization instead. That is, only fool the programs into
believing that they are actually in supervisor mode, and let MiNT
decide whether their behaviour warrants killing or not.

> > check in their startup C library. And it's always the same - jump to
> > Super(), set up bus error vector, try FFFFFA42 (or what's the address),
> > restore bus error, return from Super. Virtually each program does that.

With virtual memory, the program would not necessarily be modifying
the actual bus error vector (even without it, the vector base can
be moved). MiNT could then 'easily' take care of this specific case.

> Sounds bad. Which compiler has such a startup code? BTW. in an extreme

I've been wondering that too, since I've never seen it (and I have
had reason to trace around in lots of programs (although I do of course
skip as much of the code as I can, so I might well have missed it)).

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