A way to test if running the DEBUG kernel? SOLVED

In shell, is there a simple way to test if you are running the debug kernel or normal kernel?

I want to do some extra stuff in the startup-sequence but only if I'm running the debug kernel.

Is there a way?

EDIT: marking solved

@Marko
As there is no differences in the output from version from user and debug kernels (i already make a BZ for it few months ago), you still can use "strings" for example, and do check on the words which present in debug.kernel , but not in user one.

Quote:

So "mem_enable_munge" in the debug kernel only.

Or anything you make want to check to have differences, like "version", "debug", "kernel", "check" words - all of them will have new lines for the debug.kernel which is not in the user one.

Quote:

Probably just arexx line/script , which will run that line and check if there is output you need and if so do your extra-stuff

@kas1e

I can't see how running "strings" on the file sys:kickstart/kernel.debug will tell you if it was the kernel booted from?

@marko

What sort of things are you trying to do differetly when the debug kernel is booted from? Perhaps just run a setup script by hand?

@Andy
I usualy just rename kernels , so i have:

kernel.user
kernel.debug

At time i need, i rename any of it to just "kernel". And so via "strings" on "kernel" i can always know if it debug one or user one.

But that all crap of course, should be proper versioning , just something like:

Quote:

And for debug:

Quote:

Seems quite trivial to implement, and probably will broken nothing.

@Marko

Easy... use this script to change kernels:



Then in your startup-sequence:




Or:




Then in your startup-sequence:

What on earth?

Your supposed to use separate kicklayouts to choose the debug or non debug kernels! Renaming kickstart files and the fly will end up with unbootable systems if anything goes wrong.

Hence Markos problem.

@broadblues

Yes I agree but unless you know a way to tell which version was loaded how else are you going to do it?

At least using a script is a lot faster than doing it manually, no chance of mistyping and killing your system and as everyone should have added an energency kicklayout configuration pointing to a complete set of backup kickstart modules it should be safe.

@kas1e



Ah nice, that's something to work with thanx


Quote:
Hopefully that gets implemented pretty soon...

@broadbluesQuote:

Nothing fancy really, just something to remind myself (like another backdrop) that I'm running the debug.kernel and perhaps starting Sashimi etc.. But I can start those thing manually too of course

But I probably end up writing a small command/tool that I can use in a script, now that I have something to work with with that stuff from kas1e :P...

@Severin

Quote:
Changing kernel was not the problem but thanks anyway..

Hmm.. Not sure I'm that keen on renaming kernels on the fly but that could work
I'm not gonna test that however ;)

The way I would do it is create some simple AREXX script to read the Kicklayout file, find the last known instance of an uncommented line referencing the kernel, then checking that kernel file to see if it's actually the debug version.

It's not the nicest way to do it, but I don't know of any other way to be absolutely sure which kernel you booted from (when it could be anyone's computer). You have to automate what a human would do, which is read the kicklayout file, and then check the kernel file itself (in case people have renamed the .debug file).

But if it's just for your own computer, then Severin's idea is on the right track. It looks like the way it is, it'd just swap from debug to user back and forth each time you reboot. Keep in mind it'd have already loaded the kernel prior to running the startup script, so the ENV variables should be taken to mean that the "kernel" file is as the variable says, although what's actually running at that moment is the opposite.

And then of course it only loads the kernel files if you did a hard-reboot. So that's another problem there, if you did soft-reboots, the ENV variables and the names of the files don't mean anything.

Here's a long shot?

IF one was running the debug kernel wouldn't there be some sort of traffic aimed at the serial device? Can this not be monitored and therefore return a 1 for true

Possible implementation
Little program starts earlier which monitors serial and sets an env that there is debug traffic
When Extra Stuff comes up you check the env and execute if apppropriate

As far as I know (since I run serial debugging alot) nothing comes across the line after CFE or similair boots into AmigaOS4.x unless you are running a debug kernel

@Slayer
Quote:

Output from user and debug kernel when you set debuglevel=0 will be the same. And increasing of debug level will make it different level by level. By default, if no debuglevel set, it uses level3 if i remember right (or 5?) , so then it will be different yep, but if level set to 0, outputs will be the same => you can fail if base your checks on that

Quote:

That probably because you have default debug level , or set it to 3/5 yourself.

@kas1e

That's true, I guess I just made an assumption that his extra bits won't want to run if there is no level of debugging

Yes I believe the default is 5; actually I'm not sure if the default is 5 since I did set the variable in CFE

eg
setenv os4_commandline "DEBUGLEVEL=5 SERIAL" ; boot -fatfs cf0:amigaboot.of

Whenever I want to change the level I always break into CFE and do it on the spot since it's usually a one off for that particular test.

Thing is since this is exclusive to his requirements, why would he wish to disable serial output and axe this solution? I'm guessing it speeds some other things up? Otherwise set it to at least 1 and then he's away

@MickJT

Parseing the kicklayout isn't going to help.


Here's way which might work.

Write a small command line tool whch creates a list, adds a node, removes the node, then chacks the value of ln_Succ in the node. If debug kernel is running this will be munged to 0xFFFFFFFF, if not it will be unchanged. Freeup resources and return WARN (5) for debug 0 for standard.

@all

Perhaps you should just bring up some very good reasons why it is necessary to distinguish the normal kernel from the debug kernel. Just reasoning "I am just curious" is too weak.

Usually user programs should not care at all which kernel is in use and run perfectly under both. If they fail, then this is most probably not a bug in the kernel.

@tbeockel

I agree, howver there are 1 or two classic programs that glitch under the debug kernel so I user might want to be aware which he is using ( users should really only use the the standard kernel unless they are trying to assist with a bug report)

I think this is more of a developer thing though. Boot into debug and lauch a set of tools for debugging (sashimi etc etc)

Personaly I would do this 'by hand' not by autodetecting the debug kernel, others may differ in thier prefered approach.

@thread
The debug kernel does not offer any extra functionailty, just debug logging and a couple of "traps" for bad programs like the remove node munging. As far as software is concerned it should behave exactly as the normal kernel and so Version should not be hacked to return 'kernel debug'.

@Andy
Quote:

Hacked ?:) Different kernels should return different result by version. That just logic. Debug kernel have more code, do more things and have different purposes for developers, it is really should be return from version on what you right now. Not because that one should or shouldnt play with them, but because different stuff should return different stuff when one do version.

There we don't talk is it good or bad that user want to know on what kernel he is. Marko just want to know it. I sometime too (because i often jump between them, for sake of tests). Other ones too. Know what version is in memory now are friendly, and helpful No need to limit users like "you don't need that or that". There is needs for , and my previous BZ and that topic show why. It is welknown for what debug kernels is used (there is bunch of articles about already), problems is that user want to know on what he right now. Reasons can be different, but any user have his reasons for, and want to know it. And its just logic and friendly to return via version that you are on debug or user kernel.

Hekk, its like we make problem from nothing. If there wasn't problem, there then wasn't my BZ and such topic. So, needs are here, and some have reasons for. Saying like "dont do that", its .. dunno. Its wrong !:)

And btw,

Quote:

Its offer : it is also slower than user one because of those traps :) and when one will do tests and benchmarks on some machine, and then one will ask him, on what kernel you do it , he will say "my kernel return that is version blabla" and that all.

It also offer handling of debug levels better. On user kernel there is only omiga1200 even if you will set debug level to 20.

@Thore

Quote:

There some reasons for , for example, sometime one just forget on what he boot, when he do milion of tests. Should he loose time and check kicklayouts, reboots, and co, instead of just running version on ? Another problem, is that there is some apps which will be never fixed , and which fail on debug kernel. And , sometime when i just want to run one or another app, i remember "right, that on crashes on debug kernel .. soo, on what i am now ? " , and so, i should again and again reboot, wait, reopen all my previous apps, etc. Its just slow things down.

And there is some other reasons, i can't remember from top of head, just there was more, and that why i make BZ few months ago about.

Even if skip all my reasons and eplains, i just didn't get, why debug kernel should't return proper info in version. For very the same reasons all nightly builds offten have in build version that is "dev" or something. So users will know on what they are. Its just friendly and easy for users and devs.

@kas1e

Far more useful would be a envvar which told which kicklayout you booted from. Though as env vars don't survive a soft reboot I'm not sure how you would do that.

Unfortunately this did not give the info needed.

Quote:
Yep, something like this, I tried it, it might work..

But I got stuck on reading the DAR value from the cpu special register :/

I tried reading it from C via asm but it turned out that this value is only readable in super-visor mode :S (if I understood it correctly, and the code did not work)

A way to read the DAR value in user-mode, or some other way, would help...