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

Re: [MiNT] Kernel tests



>> Firstly, it seems like MiNT kernel starts looking for a sh.tos in
>> c:/mint/ (IIRC that was the path), and when this is not found, some
>> "internal shell" is launched right at the end of the
>> boot process. The effectively hinders the built-in AES from being
>> used.
>
>This is the purpose (to prevent the ROM AES from being launched).

Yikes, didn't see that one coming....

>> Why does the kernel try to launch a sh.tos that I have not added any
>> paths to, automatically?
>
>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?
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.

>> When this fails, why will an internal shell be launched?
>
>To prevent system halt. But if you prefer just "System halted" message, see
>below.

>> What is the
>> purpose? How can it be shut off?
>
>By compiling the kernel without the -DBUILTIN_SHELL flag.

Sounds like a good default setting for the kernel. Just need to find someone to compile such a binary for me then. Unless you are suggesting that this setting still doesn't allow possibility to load built-in AES?

>> Furthermore, I noticed that the keernel now looks for keyboard and
>> unicode tables in /mint folder at startup. Wouldn't it make sense to
>> let MINT.CNF decide whether or not external files should be loaded?
>
>These are not loaded, if they don't exist, and they are loaded, when they do
>exist. I don't see any necessity for additional cnf options for that.

Just a minor detail, 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. (But if they really do need to be called directly from kernel, it would be nicer not to get error messages if they are not present I think)


Regards,

Joakim