Re: [Crash-utility] Scripting infrastructure in crash

On May 3, 2007 02:27:02 am Sachin P. Sant wrote: Here are some thoughts/ideas about scripted dump-analysis in general, based on my practical experience. It is mostly useful in two cases: 1. Working on a specific problem you need to repeat the same steps over and over again, or you need to print some things that cannot be done by 'crash' easily. 2. Your company provides Linux support and has the related infrastructure (Response Centres). It makes sense to develop automated 'first-pass' dump-analysis scripts to be used by 1st and 2nd level of support - this saves much time for 3rd level and labs. Now for HPUX (I work in HP) we have a set of excellent automated programs for generic 1st pass and a set of programs to analyze other subsystems (NFS, FC, LAN, Streams and so on). These programs are extremely useful both for dumps and for live kernels. It is easier and safer to run these tools than to write DLKMs - especially if we need to gather data on production systems. Why Python and not C-like interpreter (e.g. SIAL)? Most people agree that for rapid prototyping/design the high-level languages (Python, Ruby, Perl) typically make it possible to obtain results 5-10 times faster than in C. Python has excellent support libraries so if needed, we can plug into expert systems or do remote calls. Linux kernel is a moving target and frequent updates of internal logic are necessary. It is much easier to maintain this in Python than in C-like language as we can use OO-tricks and Python-specific tricks. For example, instead of directly using 'struct task_struct' we declare 'Task' class and create a dynamic attribute 'last_ran' that maps to different 'struct task_struct' members for different kernel versions. Then I can use task.last_ran on any kernel and the only place to change if needed will be 'class Task'. As a result, I think that SIAL should be very good for case (1). Using C-like language makes it easier to map pieces of Linux kernel C-code to a script. But in case (2) - developing/maintaining complicated automated dump-analysis suites - using Python should be better, especially for maintenance. OO really makes maintenance much easier when internal kernel structures change frequently. The framework itself ('pykdump') is not networking-specific. But as my primary interests are in Linux TCP/IP implementation, I mainly develop programs for networking stuff. But I have already started to work on a general 1st-pass dumpanalysis program to be used by Response-Centre engineers. Regards, Alex -- ------------------------------------------------------------------ Alexandre Sidorenko email: alexs(a)hplinux.canada.hp.com Global Solutions Engineering: Unix Networking Hewlett-Packard (Canada) ------------------------------------------------------------------