lkml.org 
[lkml]   [2001]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Kernel Module tracing.
Date
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

-
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/

\
 
 \ /
  Last update: 2005-03-22 12:56    [W:0.034 / U:1.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site