Re: The case for a standard kernel debugger
[EMAIL PROTECTED] wrote: One big argument against RAS of any sort is that it bloats the kernel and not every one wants it (until they have a problem). A further argument with Linux is that you may have to do quite a bit of hard work to get the subset of RAS you need to co-exist, if it exists at all. Something we're working on which may help resolve this, and will be made available with the next drop of Dynamic Probes is Generalised Kernel Hooks Interface (GKHI). The idea here is to make all our RAS function the option of being dynamically loadable kernel modules. In most cases we don't need to modify kernel function, just get control at the right time. So we place hooks in kernel source, which remain dormant until activated by the GKHI when a RAS module asks it to. Maybe this will provide a way out of the difficulty. Sorry for catching this a bit late, but I would like to point out that there already is a generalized kernel hooks interface, that does exactly what is described above, as part of the Linux Trace Toolkit. The hooks inserted in the kernel source don't modify the kernel's behavior, though they can trigger callback functions. To hook onto an event, the following function is used: int trace_register_callback(tracer_call pmTraceFunction, uint8_t pmEventID) Once this is called, the occurrence of the given event will generate a call to the given callback function. Hence the inserted hooks are dormant until used. On top of this callback interface, I am currently in the process of completing a state machine engine that would enable it's user to specify event driven state machines. What does this mean? Well, as Alan had suggested, this could be used to test a driver's actual behavior with the state-machine that models it's theoretical behavior. Furthermore, and I think this is a field open with a lot of very interesting opportunities, state machines could be developed that model intrusions and attacks. Hence, the state machine engine could be used as the basis of a very powerful intrusion detection system. The basic example of this is stack overflows. A lot of very cleaver schemes have been developed in order to detect these types of hacks. Yet, with a state-machine that models the types of attacks being conducted, it wouldn't matter which stack overflowed or who did what since the state machine would catch any unauthorized event sequence and, possibly, kill the culprit process, suspend it or warn the sysadmin. That said, I do think that dynamically inserted probes are useful. As Richard has pointed out, there are situations where this makes a big difference. In a sense, Dprobes could use the architecture already put forward by LTT to log custom events in a system trace and could use the trace hooking mechanism already available to implement whatever RAS function comes on top. For a full discussion on the performance and architecture issues regarding LTT, I invite the interested reader to take a look at the paper I presented last June at the annual Usenix technical conference: http://www.opersys.com/LTT/ltt-usenix.ps.gz And LTT can be found at: http://www.opersys.com/LTT/ Cheers === Karim Yaghmour [EMAIL PROTECTED] Operating System Consultant (Linux kernel, real-time and distributed systems) === - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: I/O statistics per process?
Try the Linux Trace Toolkit. This should provide you with most I/O information you need. www.opersys.com/LTT Hope it helps. Samuli Kaski wrote: > > I know about sar which can deliver what I want for disks and/or > partitions. What about if I want to know how much I/O is caused by > userspace programs? > > Looking at the proc-interface in 2.2.xx the necessary bits aren't > available. The BSD process accounting doesn't provide them either, the > I/O fields are always 0 the way I read it. Looking at the task_struct, I > can't see anything related there. > > Is I/O caused by userspace processes accounted somewhere? And if it > isn't is this intentional or are folks just waiting for someone to > submit a patch? Thanks. > > Samuli > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ -- === Karim Yaghmour [EMAIL PROTECTED] Operating System Consultant (Linux kernel, real-time and distributed systems) === - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: I/O statistics per process?
Try the Linux Trace Toolkit. This should provide you with most I/O
information you need.
www.opersys.com/LTT
Hope it helps.
Samuli Kaski wrote:
I know about sar which can deliver what I want for disks and/or
partitions. What about if I want to know how much I/O is caused by
userspace programs?
Looking at the proc-interface in 2.2.xx the necessary bits aren't
available. The BSD process accounting doesn't provide them either, the
I/O fields are always 0 the way I read it. Looking at the task_struct, I
can't see anything related there.
Is I/O caused by userspace processes accounted somewhere? And if it
isn't is this intentional or are folks just waiting for someone to
submit a patch? Thanks.
Samuli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
--
===
Karim Yaghmour
[EMAIL PROTECTED]
Operating System Consultant
(Linux kernel, real-time and distributed systems)
===
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[UPDATE] LTT now supports real-time tracing
For some time now, the Linux Trace Toolkit has enabled it's users to trace the Linux kernel. This capability included being able to view and analyze the collected traces. With the latest release, LTT supports tracing the RTAI (http://www.rtai.org) real-time linux extension. This means that you can view graphically how the real-time core and the real-time tasks interact with Linux. This includes analysis made on the real-time performance of tasks and their behavior. I personally believe that this is an important step in the adoption of Linux as a legitimate real-time/embedded platform since it provides system designers with an easy to view representation of the dynamic behavior of their system. This had previously been lacking for any real- time Linux extension. Apart from the great PR this does to real-time in Linux, I think that RT designers all around will appreciate having this around. If nothing else, the source is out there. That said, I've also generalized the way LTT deals with traces. Rather than having a single way to interpret traces, it now recognizes that there are different trace types. Each having different ways of being viewed and analyzed. This opens the door for other OSs than Linux to be traced and analyzed. There is interest in the Hurd camp and the question about BSD has been asked. If someone out there is interested drop me an e-mail. I'd like to thank Lineo, and more specifically Lineo ISG, for having sponsored this work. Their help in developing this project even further is very much appreciated. Also, the paper I had presented at the last Usenix on LTT, how it works and how it impacts on the traced system is now available online. It's all on the project's web site: http://www.opersys.com/LTT Cheers Karim === Karim Yaghmour [EMAIL PROTECTED] Operating System Consultant (Linux kernel, real-time and distributed systems) === - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[UPDATE] LTT now supports real-time tracing
For some time now, the Linux Trace Toolkit has enabled it's users to trace the Linux kernel. This capability included being able to view and analyze the collected traces. With the latest release, LTT supports tracing the RTAI (http://www.rtai.org) real-time linux extension. This means that you can view graphically how the real-time core and the real-time tasks interact with Linux. This includes analysis made on the real-time performance of tasks and their behavior. I personally believe that this is an important step in the adoption of Linux as a legitimate real-time/embedded platform since it provides system designers with an easy to view representation of the dynamic behavior of their system. This had previously been lacking for any real- time Linux extension. Apart from the great PR this does to real-time in Linux, I think that RT designers all around will appreciate having this around. If nothing else, the source is out there. That said, I've also generalized the way LTT deals with traces. Rather than having a single way to interpret traces, it now recognizes that there are different trace types. Each having different ways of being viewed and analyzed. This opens the door for other OSs than Linux to be traced and analyzed. There is interest in the Hurd camp and the question about BSD has been asked. If someone out there is interested drop me an e-mail. I'd like to thank Lineo, and more specifically Lineo ISG, for having sponsored this work. Their help in developing this project even further is very much appreciated. Also, the paper I had presented at the last Usenix on LTT, how it works and how it impacts on the traced system is now available online. It's all on the project's web site: http://www.opersys.com/LTT Cheers Karim === Karim Yaghmour [EMAIL PROTECTED] Operating System Consultant (Linux kernel, real-time and distributed systems) === - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
