opentnf-dev Mailing List for OpenTNF Tracing System
Status: Alpha
Brought to you by:
kaelin
You can subscribe to this list here.
2001 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: mayu <coc...@ya...> - 2008-05-30 17:52:47
|
私は逆援助サイトの管理人をしている高杉と申します。 http://livewin.Jkub.com/lovemailmb/ 不躾で非常に失礼な質問をさせて頂きます。 今お金に困っていませんか?? 困っていない方不信感をいだいているかたは何もしていただかなくても全然大丈夫です。 もし困っているかたがいたら是非当サイトをお使いいただけませんか?? 今男性会員様の人数が大変不足していて困っております。 是非今この時期に登録していただいてあなた様だけのお相手を作ってみてはいかがでしょうか?? お粗末ですが、もしよければよろしくお願いします。こちらこらどうぞ↓http://livewin.Jkub.com/lovemailmb/配信拒否はこちらhai...@ya... |
From: Shriman G. <sh...@ve...> - 2002-08-23 17:57:00
|
I hope this list is still being read - looked a bit quiet on SourceForge... I have a 2.4 kernel (2.4.18-10 - this is RH7.3 x86) and I'm trying to get opentnf to play along. I've hacked about with autoconf and friends and added a new configure option --with-mod-includes, so that I can put in the correct include files (ie /lib/modules/2.4.18-10/build/include). Maybe I should just uname -r for this but I thought it better to be a little flexible. I've tweaked a few files to take account of slight differences between 2.2 and 2.4 (eg PF_PTRACED now seems to be PT_PTRACED in sched.h) So, at this point I can build the module but I am having trouble with insmod. It boils down the the interface modules use to register themselves with the kernel: in 2.2 people used proc_register and in 2.4 they have to use proc_create_entry. I am not at all familiar with these interfaces so I don't understand how to migrate the existing code to the new interface. Can anyone help? TIA shriman |
From: Kaelin C. <ka...@ac...> - 2001-01-23 00:57:28
|
See attached message. |
From: Kaelin C. <ka...@ev...> - 2001-01-22 23:58:41
|
The latest depot version of the tnf kernel module supports auto-loading of the module via `modprobe'. The installation procedure now creates several device files: [kaelin@vanguard opentnf]$ ll /dev/tnf total 0 cr--r--r-- 1 root root 213, 0 Jan 22 15:27 t0 cr--r--r-- 1 root root 213, 1 Jan 22 15:27 t1 cr--r--r-- 1 root root 213, 2 Jan 22 15:27 t2 cr--r--r-- 1 root root 213, 3 Jan 22 15:27 t3 c-w--w--w- 1 root root 213, 130 Jan 22 15:27 trace As you can see, I've appropriated char major 213 as a device number for the driver. [This is subject to change pending approval from the maintainer of the device number registry for Linux.] With these device entries in place, all that is necessary to enable auto-loading of the tnf kernel module is an update to modules.conf (or conf.modules, depending on your distribution): [kaelin@vanguard opentnf]$ cat /etc/conf.modules alias eth0 eepro100 alias scsi_hostadapter ncr53c8xx alias parport_lowlevel parport_pc alias char-major-213 tnf path[tnf]=/lib/modules/`uname -r`/tnf The last two lines above are the ones we care about. After adding them, invoke the command `/sbin/depmod -a' as root. This updates the module dependancy database used by modprobe. With these steps out of the way, all that remains is to invoke `trex' and verify that the module is loaded automatically. [kaelin@vanguard opentnf]$ trex trex (opentnf) 0.3.1 Trace 0 started [kaelin@vanguard opentnf]$ exit exit Trace 0 stopped [tnfdump output snipped] And in `/var/log/messages': Jan 22 15:35:39 vanguard kernel: tnf module 0.3.1 installed [...] Note that since the module is loaded automatically it may be unloaded automatically too... The details seem to be specific to different distributions, but in general don't be distressed if /proc/tnf suddenly dissappears when the system is not in use. :-) -- Kaelin |
From: Kaelin C. <ka...@ev...> - 2001-01-17 07:59:27
|
OpenTNF at SourceForge: <http://sourceforge.net/projects/opentnf/> >From the README: OpenTNF is a system-level tracing facility for capturing and presenting diagnostic information and performance metrics. To use OpenTNF, a developer first instruments one or more of the programs in a system with ``probes''. The system is then run under the control of the `trex' (TRace EXecution) command. Under trex control, data from the embedded probes is captured by the OpenTNF kernel subsystem. The `tnfdump' command may then be used to extract the captured data into a TNF (Trace Normal Form) file for subsequent analysis. OpenTNF is currently available for the following platform: Linux/Intel (kernel 2.2.x) The OpenTNF project is seeking developers for ports to other platforms. Note that some expertise in kernel module or device driver development for the target platform is required. The current release of OpenTNF includes the following components: tnf.o loadable kernel module for trace buffering subsystem, accessed via /proc/tnf/... tnfdump extracts trace events from the kernel buffers and outputs them to stdout in Trace Normal Form trex TRace EXecution is a command-line tool for controlling trace generation twrite reads stdin one line at a time and writes each line to an active trace buffer Support for adding probes to programs written in various languages is available in the `packages' subdirectory. See the package-specific `README' files for details. acl Allegro Common Lisp java Java lispworks Xanalys Lispworks See the file `INSTALL' for installation instructions. See the file `NEWS' for a list of major changes in the current release. A Word of Caution ================= This is an Alpha release of OpenTNF for Intel-based Linux systems. OpenTNF includes a kernel subsystem as a loadable kernel module. This module has to date seen only limited use in a relatively controlled development environment. While there are presently no known kernel hangs or crashes, it is important to be aware that any bugs in this module have the potential to seriously destabilize the operating system. For this reason, installation of this OpenTNF release should be restricted to development and QA machines. -- Kaelin Colclasure <ka...@ac...> 2001.01.13 |