Re: [MiNT] 1.15.10 (fwd)

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

Hi,

> > I wonder where it is "documented". Please direction to real docs?
> 
> This
> is a flaw in the documentation, IMO, and shouldnt be used as a reason for
> allowing the functionality to change. To take this to the extreme, it is not
> documented in the readmes that it is API call compatible with TOS, so is it
> okay to change the API such that you cannot run any TOS program upon MiNT?

To be strict: I think you are wrong. The compatibility with TOS is in fact
documented. The first (or one of the first) sentences of the original MiNT
documentations says: "MiNT is a replacement for (most of) GEMDOS". Since
only a part of TOS is replaced (namely GEMDOS), and it is obvious that
other parts (AES, VDI, XBIOS) which are not replaced will still use GEMDOS
calls, which (calls) boil down to MiNT, thus, all this logically implies
that MiNT's API is compatible with TOS' GEMDOS API, because otherwise
nothing would work.

> The assumption that "np" means no protection is a very well established one,
> and changing this functionality is IMO a mistake - for example, many users
> (eg owners of various accellerators, such as the BlowUP-FX) will need to set
> this to be able to boot - and this is written in THEIR documentation, even
> if it isnt in the FreeMiNT readme. Note that KGMD's (or kellis's English
> translation - presumably its in the .de version too) installation
> instructions refer to NP to make it work with some hardware - this will
> break these installation instructions, and I'm sure many FAQ's and
> historical usenet posts, and webpages - meaning more faq emails to the
> maintainers because they arent aware of the change in functionality.

As you noticed, the 'np feature' is not documented, however, it is very
well known. Nevertheless, as I understand it, the possibility to disable
the memory protection was introduced only to maintain the backward
compatibility with (some, it is to be said) TOS programs, and never was
intended as a main mode of MiNT operation. Therefore it is not officially
documented, and if you decide to use an undocumented feature, or rely on
it, you always do it at your own risk.

For example, people think that it is a guaranteed system feature, when no
task switches occur in Supervisor mode. Here even Julian was once trapped
in it, I also think that e.g. N.AES relies on it somehow (instead of
putting code, that can't be interrupted, in scope of a
semaphore). However, when you read the docs, you actually see that they
explicitly say even a contrary thing: supervisor blocks multitasking,
yes, but don't rely on it, this feature will go away! In other words, if a
program relies on that, is it a reason to not expand the MiNT kernel some
day so that it would multitask even in supervisor mode? Or rather a reason
to fix the broken program?

IMHO, the fact that actually so many people have the mp disabled, and that
new developments are not compatible with memory protection relying on the
fact that "you can always disable this in MiNT", it is a misuse of that
feature. The basic MiNT operation is and always has been the protected
mode, just because it is so. AFAIK, nobody complains that Linux protects
the memory. Nobody should complain the same on MiNT.

Notice that so far I only spoke about the memory protection itself, not
the way it can be disabled. This one (the way) is even less documented, if
anything can be less documented than undocumented ;) There are two reasons
why mintnp.prg is ignored.

First, it is my personal opinion, which says, that setting system options
by renaming the kernel binary is a completely broken and brain damaged
idea. Over years, I got completely bored & tired messing in the auto
folder whenever I wanted to change that setting, mostly just for a while
and for test purposes. Not to mention that such a way (rename) of setting
options is rather limited, and complicates things in an unnecessary
way. For things I mean the code in init.c. An additional settings file was
an obvious replacement. The same for changing settings via the menu
(nb. reading the command line options went away off the kernel code a year
ago, or earlier, and nobody noticed this fact :)). It may be an isolated
opinion, but I think that this is much more convenient and elegant way.
 
> Also note that lots of people use bootmenus themselves, such as XBoot, Stoop
> etc, to configure their system, and you have added an extra thing that
> cannot be configured externally via legacy apps such as these with existing
> setups.

I personally don't use boot managers, however, I had XBoot, and I am
pretty sure that at least this one can be configured to handle this
flawlessly (you can maintain different copies of config files, and
instruct XBoot to copy them to proper locations at bootup, right? So same
can be done with mint.in, one copy says "mp: yes", the other says
"mp: no"; in case your XBoot is out of free entries for config files, I
can tell you it (the XBoot) also can execute manually written commands,
saved in a sort of a script file). In other words, it is not so bad. And
obviously I don't think that a MiNT extension should be cancelled just
because a boot manager is too primitive to be accommodated to that.
 
> What it all boils down to, is... Is there actually a good reason for
> removing this functionality? (a boot menu default could be based upon the NP
> name?) If there is a sound technical reason, then fine, but if its personal
> preference, then IMO a "dont fix what isnt broken" attitude is wise.

The other reason is: this makes things less complex. I had difficulties
to decide, which setting would be more important: the one read from
mint.ini or the one read after the kernel's name. Since I didn't think it
was important at all (see above XBoot section), and additionally
considered setting options by renaming the kernel a lame idea, I disabled
this. However, strictly speaking, there are no other technical reasons for
this except the kernel's name recognition inside the kernel is rather a
hack.

It is always possible to restore this.

Nevertheless I would be for trying to accommodate to the new behaviour. I
am sure it will turn over, that there is no real need for 'mintnp.prg',
other than conservative thinking.

PS. Martin-Eric, for me, you may say anything, or move to Madagaskar. I am
very sorry, but I really don't care on your opinion, whether you justify
your statements to anything or not. Semicolon.

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