[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] This fight



On Thu, 11 Dec 2003, Petr Stehlik wrote:

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

 This idea makes me smile ;-)

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

 This is also an issue I partly addresses somewhere else. Not sure I know
if this can apply to all NF, but.. Lets take Shutdown(), as this is a
standard, generic kernel function. The kernel should then use the external
modules to actually perform the hardware part of the shutdown. Also I got
the impression that NatFeats should NOT be used by user applicaitons (only
the OS). Why then do we need to make MiNTlib aware/use NatFeat?

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

 I think I need to know more about NatFeats. I thought it could be
regardes as "new/different hardware". In which case support for it should
go in XDD's, and only there. Not in MiNTlib or anywhere else.

 Where can I read about what NatFeats really is?


-- 
 Regards,

 Odd Skancke - ozk.atari.org - http://assemsoft.atari.org