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

Re: [MiNT] Kernel tests



>> Because you haven't defined any INIT= or GEM= line in your mint.cnf.
>
> Why not make the starting of a shell to an option in the INIT= line?

Because the internal shell is being launched when there is no INIT= line
defined.

> I don't know if I am the only one interested in the option to use
> built-in AES, but I find it very
> convenient when testing XaAES. Reason is, that XaAES then
> automatically get correct video setting, set by screenblaster. Plus I
> can close/restart the AES from built-in desktop.

The real problem is that the ROM AES is not written to be used with MiNT.
The ROM AES never sleeps, it uses polling to interrogate mouse/keyboard
events. Thus it makes the system load always high, being always ready to
run. The ROM AES likes to run in supervisor mode, thus blocking the
multitasking. The ROM AES, finally, can never be shutdown properly, and this
makes a danger, that the filesystem caches will not be flushed back to the
media before the power goes off.

Also, the possibility of launching ROM AES directly by MiNT was not
introduced to MiNT with the AES of TOS 1/2/3 or 4 in mind, simply because of
the reasons above. The possibility was done for the TOS 5.0, and its
multitasking AES, which (the TOS) never came officially out. The feature is
thus: a) useless, b) dangerous, c) confusing.

I explain the latter: an user comes and downloads the kernel. The user is
like everybody in this world, and never reads any documentation before
running into severe problems. He unpacks the kernel, puts into the AUTO,
reboots. The MiNT kernel (w/o mint.cnf) launches the ROM AES. It is slow,
clumsy, bad, features almost no multitasking. If the user ever manages to
install mintnet on top of that, the mintnet is also slow, clumsy, bad etc.,
because it need flawless multitasking to run flawlessly (I mean e.g. the SLD
daemon). But it generally somehow works.

Of course, the user thinks that all that should be so: he has an Atari OS
kernel, that has launched the Atari GUI and Desktop, right? So the user
finally comes to a newsgroup and loudly claims, that MiNT is a shit, and
MiNT-Net is even shitter.

This is why there is the internal shell, and there is no option to use the
ROM AES.

You can of course launch the XaAES directly from the shell (hoping that it
manages to set the resolution properly, and reset it back later).

You can also write a small program, that launches your ROM AES, name the
program sh.tos, and put it inside your mint/ folder on the boot drive. This
is the best option, because doing so you use the ROM AES on your own risk
and responsibility, not ours.

>> By compiling the kernel without the -DBUILTIN_SHELL flag.
>
> Unless you are
> suggesting that this setting still doesn't allow possibility to load
> built-in AES?

Indeed. This only excludes the internal shell, if someone particularly hated
it.

> Just a minor detail,

Yes.

> but in general it is neater if the kernel
> doesn't take too much for granted, regarding
> certain files being in a specific location IMO.

These are not "in a specific location". They are simply in the same folder,
as mint.cnf is, exactly like XDD/XFS modules. Also, the kernel doesn't
really take them as granted, since these are not required to boot the
system. These files are *optional*, although you may be right, that error
messages ("error -33") during the boot process are to be avoided, because
this usually confuses picky users.

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

** Ea natura multitudinis est, aut seruit humiliter, aut superbe dominatur.
** Taka to juz natura pospólstwa, albo sluzalczo sie plaszczy,
** albo bezczelnie sie panoszy. (T. Liuius XXIV, 25).