Re: [MiNT] Kernel tests

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

>> These questions are for the list owner, not for me. IMHO saying
>> "this does not make sense" about something that you just don't
>> understand, is rather a peculiar way of expressing opinions.
>
> Draco, you are a little bit to aggressive in your argumentation now I
> think (at least your first answer explained all things very clearly
> and I had the impression Gokmase understand).

I like to answer to specific questions. I don't like, when one comes and
immediately starts with "no sense", "how to exclude" etc. not even trying to
understand the concept.

> To be back to the topic, not starting the TOS-AES is a good idea as
> this
> was always buggy. But we can maybe add such an option to the builtin
> shell with an 'at your own risk' statement.

I don't think that's necessary. Of course, this depends how do you define
the statement about the ROM AES. I'd vote for "no support from the MiNT
side". Introducing code to the shell (or anywhere else) that would allow to
start the ROM AES directly would mean that the support is back.

I don't think it is really needed, as long as the 'execgem' program exists,
as Maurits pointed out. At last, the program can be added to the
freemint/tools directory, but this would mean some support for the ROM AES
as well.

In such a case I'd rather rename the program to "exectos" or something
similar. Current name is confusing.

Including the execgem would also demand including the nohog.acc, and update
its documentation (the program was written before AES 4.0).

Also, adding such a command to the shell wouldn't help much if the kernel is
compiled without the shell.

> About the configuration files, the idea to specify anything in the cnf
> file isn't so bad. At least it's more logical and easier to edit the
> cnf file instead renaming or moving files.

If you refer to the internal shell and/or the "external" shell, their
purpose is to be launched when there is no config file, or the config file
is skrewed. In such a case the kernel must (and it does) assume some
defaults. The "sh.tos" is the default for the INIT=. The file is being
searched for in the sysdir, because the sysdir is the only certain place in
such a situation. The same with the internal shell. Cnf options are useless
for such stuff.

If you refer to the *.tbl files, the situation is different. These are, as I
see it, parts of the kernel, exactly like the modules. Since the modules
ain't defined in any config file, but just reside in the sysdir and are
loaded automatically, I don't see why the tables couldn't, and where is the
better place to keep them. Automatic load is simpler, the cnf parser is
shorter, and it is not a big deal for a boot manager to rename, delete or
copy a single file, even if someone changes keyboards and unicode mappings
several times a day.

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