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