Adding new option to ktrace

[Nikhil Dharashivkar]

Hi,
     I am able to backport kern_ktr.c and related files and ktrdump to
versions older than 5.0 specially 4.1
      with non-SMP configuration file kern_ktr.c file is compiled 
successfully.
But with SMP configuration file it is giving an assembly errors as follows :

cc -c -O -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline
-Wcast-qual  -fformat-extensions -ansi  -nostdinc -I- -I. -I../..
-I../../../../BSD4.1/sys -I../../../include
-I../../../../BSD4.1/include  -DNILA -D_KERNEL -DNILA -include
opt_global.h -elf  -mpreferred-stack-boundary=2  ../../kern/kern_ktr.c
../../kern/kern_ktr.c:290: warning: no previous prototype for `ktr_tracepoint'
/tmp/ccW68912.s: Assembler messages:
/tmp/ccW68912.s:218: Error: Rest of line ignored. First ignored
character is `"'.
/tmp/ccW68912.s:218: Error: Rest of line ignored. First ignored
character is `"'.


     I am not getting this error ? what is this meant ?





On 9/7/05, Robert Watson <rwatson at freebsd.org> wrote:
> 
> On Wed, 7 Sep 2005, Nikhil Dharashivkar wrote:
> 
> >    I went through the ktr and ktrdump options. I compiled the kernel
> > with options ktr. I found that ktr support is mostly for lock and
> > schedule. We can trace drivers using mask KTR_DEV and some CTR*
> > statements in dirver.
> >     But This ktr support is from freebsd 5. I am aslo using freebsd 4.10
> > and older. For this case, do I need to port KTR code for older version ?
> > or is there any other solution ?
> 
> KTR(9) was a facility added as part of the SMPng work to the 5.x branch,
> and has not been backported to the 4.x branch at this point.  It would not
> be difficult to either backport it, or to add a light-weight trace ring
> buffer of similar nature to fix, especially as 4.x doesn't have in-kernel
> parellelism.
> 
> Robert N M Watson
> 
> 
> >
> >
> > On 9/6/05, Robert Watson <rwatson at freebsd.org> wrote:
> >> On Tue, 6 Sep 2005, Nikhil Dharashivkar wrote:
> >>
> >>> Yes, it is ok if i loose data in ktrace queue when crash occurs.
> >>> Basically, I want to give an Disk IO trace support to ktrace on FreeBSD.
> >>>       So, what I am thinking to use struct dio in dastrategy routine to
> >>> trace the IO. I 'll use this struct to generate ktr_request. Throught
> >>> ktr_writerequest it will be written in ktrace.out .
> >>>      Is it possible ?
> >>
> >> Try taking a look at KTR(9) and ktrdump(8) for information on ktr, the
> >> in-kernel trace facility.  ktrace(1) is almost entirely about tracing
> >> process level system call behavior, and not structured for kernel event
> >> tracing except in that context.  I think you'll find KTR(9) is much more
> >> what you're looking for, and among other things, you can extract the
> >> results from both live kernels and kernel crash dumps.
> >>
> >> Robert N M Watson
> >>
> >>
> >>>
> >>>
> >>>
> >>> On 9/6/05, Peter Jeremy <PeterJeremy at optushome.com.au> wrote:
> >>>> On Tue, 2005-Sep-06 10:33:53 +0530, Nikhil Dharashivkar wrote:
> >>>>>     Thanks for replying me. Basically what happend, while testing
> >>>>> scsi driver on freebsd, at  some point it crashes. So, there is no way
> >>>>> to know how much IO is performed. To know the IO state just before the
> >>>>> driver fails, i selected ktrace to print IO information whatever i ll
> >>>>> get from dastrategy routine.
> >>>>
> >>>> It's not clear how ktrace is going to help here.  The ktrXXX(9)
> >>>> functions place ktr_request events in a queue.  A kernel thread then
> >>>> dumps the queue entries into a file via the normal buffer cache.  The
> >>>> data on disk is typically about 30 seconds behind real time.  If the
> >>>> system crashes, you will lose any events that are still in the buffer
> >>>> cache or ktr_todo queue.
> >>>>
> >>>> Another problem is that since ktrace generates disk I/O, it is likely
> >>>> to disturb your testing.
> >>>>
> >>>> A better approach would seem to be to build a circular buffer and
> >>>> store the I/O requests in the buffer.  When the system crashes, you
> >>>> can look at the last entries in the buffer.
> >>>>
> >>>> --
> >>>> Peter Jeremy
> >>>>
> >>>
> >>>
> >>> --
> >>> Thanks and Regards,
> >>>         Nikhil.
> >>> _______________________________________________
> >>> freebsd-hackers at freebsd.org mailing list
> >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> >>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
> >>>
> >>
> >
> >
> > --
> > Thanks and Regards,
> >         Nikhil.
> >
> 


-- 
Thanks and Regards,
         Nikhil.