RE: Kernel Module tracing.

RE: Kernel Module tracing.

[Michael Nguyen]

>I've recently been laboring over a kernel module that allows other
>kernel modules to send messages and tracing statements.  If anyone 
>has any input on whether this would be a usefull thing or not
>please let me know. Here is a quick breakdown on how it works.

Here is one raised hand.
>From your description, I can see that this could be use as a 
Monitoring tool (heart beat, status, progress, etc..). I would 
appreciate any additional info.

Thanks in advance,
Michael.

Re: Kernel Module tracing.

[Richard J Moore]

I missed your original post. If you want some form or generic tracing in
the kernel then DProbes with LTT might help.

With these tools you can build tracepoints without modifying the source.
You could use system.map to generate simple tracepoint definitions (having
written yourself a small program to parse the map output).

Richard

Richard Moore -  RAS Project Lead - Linux Technology Centre (ATS-PIC).
http://oss.software.ibm.com/developerworks/opensource/linux
Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183
IBM UK Ltd,  MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK


Constantin Loizides <Constantin.Loizides@isg.de> on 05/07/2001 16:38:26

Please respond to Constantin Loizides <Constantin.Loizides@isg.de>

To:   Tom spaziani <digiphaze@deming-os.org>
cc:   linux-kernel <linux-kernel@vger.kernel.org>
Subject:  Re: Kernel Module tracing.


> I want this.  I've been thinking about it since your original post, and
I also would be very much interested in having such a great
tool by hand.
Please mail me any information, or code to try, thanx!

>
> Perhaps you should also think about a non-devfs way of doing this, I
don't
> know, it's a matter of taste.  Here's a Rube Goldbergesque way: when the
> client registers, export a dynamically allocated major number through
proc
> and let the user mknod a device with that major.

Yes I think, that would be a great alternative, using good old /proc.

Constantin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Module tracing.

[Constantin Loizides]

> I want this.  I've been thinking about it since your original post, and
I also would be very much interested in having such a great
tool by hand.
Please mail me any information, or code to try, thanx!

> 
> Perhaps you should also think about a non-devfs way of doing this, I don't
> know, it's a matter of taste.  Here's a Rube Goldbergesque way: when the
> client registers, export a dynamically allocated major number through proc
> and let the user mknod a device with that major.

Yes I think, that would be a great alternative, using good old /proc.

Constantin

Re: Kernel Module tracing.

[Daniel Phillips]

On Friday 29 June 2001 23:37, Tom spaziani wrote:
> I've recently been laboring over a kernel module that allows other
> kernel modules to send messages
> and tracing statements.  If anyone has any input on whether this would
> be a usefull thing or not
> please let me know. Here is a quick breakdown on how it works.
>
> Beware, this is only a BRIEF explaination.. I'll follow up with more
> details if anyone is intereasted.
>
> trace.o  <- Tracing module
> mymodule .o  <-  Client module
>
> 1: Load tracing module
> 2: Load a module that uses the tracing modules for reporting.
>     a. the client module requests a certain number of reporting levels.
>     b. the trace module creates a devFS entry for each of the requested
> reporting levels.
>                     ( /dev/trace/mymodule/mymodule0
>                                                           mymodule1 ...
> )
> 3. Now the client module can send messages with a specific severity
> rating and have it set
>     to the appropriate character file.
> 4. User space programs listening on each of the character files can do
> whatever, log the messages
>     or perform tasks depending on the message.
> 5. When a client module is unloaded the devFS entries are removed and
> the user programs are also
>     told to close the file.
>
> I am using the devFS filesystem because of the abilities to easily
> dynamically create new entries and
> remove them..  Currently devFS does not recycle Major and Minor numbers,
> but a co-worker of mine
> has created a patch to fix that.

I want this.  I've been thinking about it since your original post, and 
having just gone through a round of development involving massive amounts of 
kprint output (real time performance monitoring) I can say I'd prefer a more 
flexible way to do it, not to mention more efficient.  I'd like to have the 
option of leaving tracing code in some of my development projects all the 
time, just disabled until I say the magic word, then have it routed to a 
device as you describe.  Presumably you intend to use a ring buffer as printk 
does, simplified by the fact that you don't have to parse "level" information 
out of the string.  This will all be a lot more useful if it works from 
interrupts etc.

Perhaps you should also think about a non-devfs way of doing this, I don't 
know, it's a matter of taste.  Here's a Rube Goldbergesque way: when the 
client registers, export a dynamically allocated major number through proc 
and let the user mknod a device with that major.

Please cc me when you have something to try.

--
Daniel

Kernel Module tracing.

[Tom spaziani]

I've recently been laboring over a kernel module that allows other
kernel modules to send messages
and tracing statements.  If anyone has any input on whether this would
be a usefull thing or not
please let me know. Here is a quick breakdown on how it works.

Beware, this is only a BRIEF explaination.. I'll follow up with more
details if anyone is intereasted.

trace.o  <- Tracing module
mymodule .o  <-  Client module

1: Load tracing module
2: Load a module that uses the tracing modules for reporting.
    a. the client module requests a certain number of reporting levels.
    b. the trace module creates a devFS entry for each of the requested
reporting levels.
                    ( /dev/trace/mymodule/mymodule0
                                                          mymodule1 ...
)
3. Now the client module can send messages with a specific severity
rating and have it set
    to the appropriate character file.
4. User space programs listening on each of the character files can do
whatever, log the messages
    or perform tasks depending on the message.
5. When a client module is unloaded the devFS entries are removed and
the user programs are also
    told to close the file.

I am using the devFS filesystem because of the abilities to easily
dynamically create new entries and
remove them..  Currently devFS does not recycle Major and Minor numbers,
but a co-worker of mine
has created a patch to fix that.