Re: Kernel Module tracing.
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 <[EMAIL PROTECTED]> on 05/07/2001 16:38:26 Please respond to Constantin Loizides <[EMAIL PROTECTED]> To: Tom spaziani <[EMAIL PROTECTED]> cc: linux-kernel <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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.
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 [EMAIL PROTECTED] on 05/07/2001 16:38:26 Please respond to Constantin Loizides [EMAIL PROTECTED] To: Tom spaziani [EMAIL PROTECTED] cc: linux-kernel [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
> 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 [EMAIL PROTECTED] 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.
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 [EMAIL PROTECTED] 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.
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 [EMAIL PROTECTED] 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.
>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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel Module tracing.
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel Module tracing.
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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.
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
