Kernel Tracking Question.. regarding kernel and boot files
dteske at vicor.com
Sun Apr 10 07:29:04 UTC 2011
On Apr 9, 2011, at 9:46 PM, Julian Elischer <julian at freebsd.org> wrote:
> On 4/9/11 2:51 PM, Chris Richardson wrote:
>> On Sat, Apr 9, 2011 at 10:34 PM, Chuck Swiger<cswiger at mac.com> wrote:
>>> Hi, Chris--
>>> [ ...Reply-to: set to direct towards the most appropriate list... ]
>>> On Apr 9, 2011, at 8:31 AM, Chris Richardson wrote:
>>>> I am totally new to FreeBSD. I was involved within project which will
>>>> trace the kernel. I used ktrace but I could not get appropriate results
>>>> about the files being opened. I don't see any of the boot files boot0-1
>>> or 2
>>>> in the ktrace.out file. Where did they go?
>>> The bootstrap loader stages are what loads and runs the kernel.
>>> ktrace isn't available until afterwards, when the kernel is running.
>>>> Is ktrace the best "trace suite" for freebsd kernel?
>>> Kinda depends on what you are doing. Setting up good logging and making
>>> interfaces for getting to useful information (cf vmstat, ps, iostat, etc)
>>> more likely to be useful over the longer run.
>> What about if I wanna see the interaction between boot process and kernel
> either you run it under an emulator that allows you to single step it.
> or you just add a lot of printf() to the boot loader.
> (some parts are required to fit in small code sizes to adding prints will cause overflow..)
> best to read the docs and then the sources. then it wil become apparent to you
> what you want to find out.
You also have the option of writing Forth modules for the boot-loader. Even dropping to the "ok" prompt is enough to give you full access to the built-in Forth interpreter. You can query the variables that are set in the "environment" (which are different depending whether you've booted via pxeboot, cdboot, or other method). You can even do some limited device poking and file-io (both read and write).
The benefit of the forth modules is that you can use it to produce the necessary debug output whilst avoiding the overflow issue. That is to say, that one technique I've used is to add code to the loader to export some string or value of interest to a variable in the environment that I would then add something like 'echo "debug == $debug"' to loader.rc. Keeps the loader small and the human fluff off to the interpreter.
>>>> What about going through source code .. Is it better to
>>>> use Combination of Ecllipse/Qemu and FreeBSD Source tree?
>>> Eclipse is an editor. If you like it in particular, free free to use it,
>>> otherwise pick something else you'd prefer to use for C code.
I use a combination of vim (as my editor) and CVSweb (URL is in the handbook) for historical research as necessary.
Just my "tuppence."
>>>> Does this method will provide us with someway to see how booting process
>>>> the kernel to memory ? Any help will be appreciated.
>>> You're asking about the process here:
>>> ...? Frankly, none of these are especially big, start by reviewing the
>>> code for 'em.
>> Yeah. this file provides me with the stages in theoretical way. How about
>> implementing it using qemu to emulate livecd to see what is going on boot0.
>> Do you have an idea about that ?
>> Good Luck,
>> freebsd-current at freebsd.org mailing list
>> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
> freebsd-hackers at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
More information about the freebsd-current