resource monitoring
Joel Sherrill
joel.sherrill at OARcorp.com
Wed Jan 30 17:58:34 UTC 2002
Jan.Suchotzki at de.abb.com wrote:
>
> Hi Joel,
>
> I found the follwoing mail in the archive:
>
> >Peter Mueller wrote:
> >>
> >> Hi all,
> >>
> >> I like to monitor execution of an rtems application. I saw that the
> necessary OS hooks are already there to get e.g. task switching et cetera.
> My plan is to log >>such system events in a large ring buffer. The buffer
> could be displayed later on.
> >
> >If you are going to add any more system log events than can be done via
> adding
> >an extension,
> >I would HIGHLY recommend doing something a bit more general and adding
> some
> >macros that
> >can be dropped anywhere in the executive source and conditionally enabled.
> >Getting the
> >infrastructure in place to handle this is one thing. Starting to
> instrument
> >RTEMS is another.
> >I would like to see some instrumentation in place.
>
> What do you mean with doing something a bit more general?
There are only a handful of user extension points. I would really like
to be able to generate a log of when system calls are made, resources
obtained, etc.
> There is a tool
> for monitoring the Linux Kernel (Linux Trace Toolkit).
> Do you mean something like this?
>From my understanding of what that is, yes. I have seen Spyker (is
that right?) and that looks good but the trick it uses to grab the
information won't work with RTEMS. SInce Linux uses a trap to get
to the OS, it can insert a "wedge" between user space and the
kernel and note when any system call is made. RTEMS is link-in
so this is not possible.
> Is there already something in progress?
Not as far as I know. I have started to write up some requirements
if you want them.
My vision is that there would be macros which logged to a ring buffer.
There would be BSP plug-in points to decide what to do when the buffer
reached a high-water mark and overflows. There could be generic support
to reset the ring buffer on overflow, send a TCP/IP packet somewhere
at high-water mark, etc.
But we need some general infrastructure for writing those macros
and a structure for the messages. We can add message types as
we go on once the infrastrcture is in place.
> regards
>
> Jan Suchotzki
--
Joel Sherrill, Ph.D. Director of Research & Development
joel at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
More information about the users
mailing list