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

["Konrad M. Kokoszkiewicz" <draco@obta.uw.edu.pl>]

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

This is good idea.
 
> IMO, MiNT should take full responsibility for the Traps.

Of course, it should.

> This, obviously, would mean that lots of software that modifies the
> vectors would need to be changed...

Generally, I tend to think, that software that modifies trap vectors
should be loaded before MiNT. I even though of disabling the code that
executes the auto folder after MiNT is loaded. But well, how much users
would complain?
 
> > use your VDI, even if he's a restricted user. This is baaaad :-)
> 
> Privilege enforcement could be done inside fVDI, if necessary.

How would you check the privileges from outside the MiNT? AFAIK, an
external program could do it only via trap calls, and this is sloooow :-)

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

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
components. In the first case it must contain VDI. Also, if MiNT would be
self-contained, it would be more portable.

Let's face it, Atari hardware is dead. Eventhough these are great machines
(if I thought something else, I wouldn't be using one of them to this time
:-)), no new ones will get produced. So, if MiNT and GEM has to be
preserved and avoid the death, it must migrate to another hardware. Petr's
Aranym sounds very promising, but at the other hand the more functions
MiNT contains, the easier is porting to other machines, even without
Aranym, or it is easier to prepare Aranyms for future machines (going deep
into future, that is).
 
> 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).

As for MiNT, it currently has a keyboard handler integrated, and it will
get developed to completely replace the TOS code. If you want anything the
handler could do for fvdi (the *.xdd version), just tell me. It is not
necessary to replace the code as long as we are inside MiNT.
 
> 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.

Yes, this is good idea.
 
--
Konrad M.Kokoszkiewicz
mail: draco@atari.org
http://draco.atari.org

** Ea natura multitudinis est,
** aut servit humiliter, aut superbe dominatur (Liv. XXIV,25)
*************************************************************
** Taka to juz natura pospolstwa, ze albo sluzy ono unizenie,
** albo bezczelnie sie panoszy.