Re: [MiNT] Shutdown() discussion

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

>> ago. IIRC, I have pointed out, that the natfeat makes direct JSR
>> calls to ROM
>
> No, it doesn't. Currently it uses the value of the __NF cookie as a
> pointer to a structure of two pointers (IIRC). These pointers are not
> fixed to point to ROM as I suppose FreeMiNT kernel would contain its
> own NatFeat code. And I believe that with your system of "private
> copies of cookies" we would be able to copy even the code that
> invokes the
> NatFeats physically (which are currently illegal opcodes) into
> process' private memory. So basically there would be no pointers
> outside of the process memory.

Basically, if we forget that the "system of private cookies" currently does
not work and is disabled, you are right. The kernel can make private copies
of cookie jar for each application, and also can copy over the NF cookie
with everything behind it and make a private copy of this for each
application.

Great. But - what for? How many user programs will have to shutdown the
system? It will be one, and you request MiNT to allocate yet another 8k of
RAM to keep NF in it for EACH application? For your information, a single
program, except its own TEXT/DATA/BSS and stack, takes about 16k for process
structure, at least 8k for environment, and 8k for the trampoline, and God
knows what else I forgot. 8k is the pagesize. Yet one page now for NF?

As for NF, you can answer that NF offers not only shutdown facilities, but
also gives an access to the accelerated graphics card of the host machine
etc. Question: why this way? Why such things are not done via VDI drivers?

As someone wrote here, you (Aranym developers) seem sometimes a bit too
aggressive (see Mr. Jurik mails, the last one is purely sick). As if you
accepted every voice of critics as an attack on the idea of Aranym and your
work as a whole. Not. Aranym is a great piece of software, its usability is
great. Also the idea of native
features themselves is great. BUT the idea of using Cookie Jar as a way to
use it is completely broken. It is, apart from anything else, yet another
misuse of the Cookie Jar, btw.

You write in the other mail that Aranym is not an emulator of a particular
machine. Great. But what prevents you then from doing things like these are
done on a real machine (even if such one does not exists)? Why the
"hardware" features are not done via "hardware" registers, with whose MiNT
could detect the presence of a feature the usual way and use it the usual
way, whether directly or via a driver?

You need speed? How move.w #xxxx,$yyyy.w is slower than an illegal
instruction or a JSR?

I still remember a bit of the discuss on the Aranym list at the begin of
this year. You (I mean the list members who participated in the discussion)
sorta agreed, that the current solution is misconcepted and something must
be done with it. The discuss has ended then and you did nothing about it.

>> It was then argued on the list, that it does not matter, because
>> *Aranym* does not support memory protection
>
> ARAnyM does support memory protection for years now. Such an argument
> would be stupid.

Then you just have called Johan Klockars stupid :) because he was using such
an argument. "OK, this is illegal, but inenforcible", since there is no
practical MP on the emulator. And it is not, because the MMU version of
Aranym is seven times slower, than the non-MMU version, so nobody will use
it for daily gcc compiling, for example.

>> *However* I see now that natfeat is also to be accepted on real
>> machines,
>
> ?? what real machines are going to accept it?

See Xavier's mail.

> And BTW, I'd like to see the memory virtualization much sooner than in
> two three years.

You can wait even two-three thousands of years, if you enforce a standard
that conceptually breaks it.

--
CVV
Konrad M.Kokoszkiewicz, http://draco.atari.org

** Ea natura multitudinis est, aut seruit humiliter, aut superbe dominatur.
** Taka to już natura pospólstwa, albo służalczo się płaszczy,
** albo bezczelnie się panoszy. (T. Liuius XXIV, 25).