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

[Johan Klockars <johan@klockars.net>]

> > 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
> 
> A privilege check is usually one or two comparisons and a branch.

I did not understand myself what this referred to until I went back to
the previous message. The context was:
> > > 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.

That is, it was the 100+ instructions for a Trap that mattered, not the
few instructions needed for the actual operation.

> Not much, really.

Together with the 100+ overhead it is, which was my point.

Anyway, with fVDI as a kernel module, using a direct call interface
for the check rather than going via a Trap, the overhead shouldn't
be significant.

> > > > Why would anyone want that?
...
> > 'MiNT to be a complete self-contained OS'.
> 
> Anyone who would want to have full control on its operation. Currently MiNT

As I said, it depends on your definition of 'complete self-contained OS'.

> is dependent on the BIOS in ROM (not open source) and hard disk driver
> (not open source either).

I fully agree that MiNT should bypass the TOS BIOS/XBIOS. The useful
things in there should be simple enough to rewrite for the standard
Atari hardware. The various TOS compatible machines are a different
matter, obviously.

The hard disk driver is a more serious problem.
There's always the Linux and BSD code to look at, though.

> > 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.
> 
> Including VDI (or whatever) drivers doesn't mean forcing. Everyone still

If the only (or only reasonable) way to access the screen is via the VDI
(which it would be for the general case), I'd call that forcing.

> can behave just like there was no driver. At his own risk, of course :-)

If you don't have some kind of driver, there might as well be no screen
at all, since you'd have no way of accessing it.

Please, note that I'm not against kernel protection for screen drawing.
I'm against making the VDI the API for such.
The VDI is bad enough as an application level library, and would
terrible as the only possible screen access method.

> > I'd rather have the VDI 'engine' running as a user mode library, with
...
> Very nice idea, but this would require shared libraries (as it doesn't make

Sort of. It would not need to be a demand loaded one, and it could do
completely without any kind of static per process storage.

That is, it should be enough if it was available in globally executable
space, at an address that applications can find out somehow.

> much sense to statically link such a thing to every GEM program).

No.
The same applies to most libraries, of course.

-- 
                        | Why are these |  e-mail:   johan@klockars.net
                        |  .signatures  |
                        | so hard to do |  WWW:      http://www.klockars.net
                        |     well?     |            (fVDI, MGIFv5, QLem)