Re: Kernel Module tracing.

[Daniel Phillips <phillips@bonn-fries.net>]

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