Re: [MiNT] This fight

[Petr Stehlik <joy@sophics.cz>]

On Thu, 2003-12-11 at 04:24, Konrad Kokoszkiewicz wrote:
> standard proposed as an API for programs willing to use NatFeats, which (the
> standard) is not acceptable in my personal view.

I was mostly alone in my opinion that NatFeats should not be available
to standard programs (like Qed or Calamus are). For me, NatFeats are a
way to talk to "hardware" directly. And as such they should be used by
drivers only/mostly.

The Shutdown(), for example, should be taken this way:

1) End user application (like the one in N.AES, or the implementation in
XaAES) calls a FreeMiNT function for shutdown.

2) FreeMiNT offers Shutdown function that when called just halts in an
neverending loop (or a STOP insn) if there is no better way (see below).

3) SHUTDOWN.XDD (or APM.XDD) implements hardware specific extensions for
the standard MiNT's shutdown neverending loop.

And in this schema the NatFeats clearly belong to the hardware specific
XDD (like Odd suggested earlier and as you see it makes great sense).

Also, if everything was implemented this way (if all special features
got a library that would offer clean API) the NatFeats with its cookie
would not have to be available to processes at all. So no pointers, no
private copies of this cookie, nothing.

The question is how quickly new libraries can be developed (or how
quickly current libraries can adopt NatFeats - for example MiNTlib in
its TOS compatibility mode should call the NatFeats in its current way,
IMHO, while under MiNT it could rely on the information provided by the
kernel).

But if you agree with my view (and agree with making FreeMiNT and
MiNTlib aware of NF) then the __NF cookie could simply be removed from
the CookieJar upon MiNT boot so you'd get a clean system with no
pointers.

Petr