8:36 a.m.
Dave, i came across one of the Crash TODO list items about having
a scripting infrastructure in crash.
I was trying to evaluate the Alicia utility [mentioned in todo list].
Here are some of my observations about Alicia.
1] It is a wrapper on top of crash.
2] One can write perl based scripts to extract infromation from dumps.
3] It has a nice report generation functionality which presents
the data in text as well as html format.
4] Provides functions which could be used to read data from crash
dumps.
5] It is easy to use and effective too.
Attached here is a sample script which i tried using Alicia to
display block and character devices. [ I know dev command already
does this stuff .. but for the sake of trying out the Alicia i chose
to write such a script ].
Also encountered few problems while trying out Alicia.
1] On PPC64 arch came across data type overflow problem while
executing the attached script.
2] On s390/s390x architecture class function provided by Alicia
seems broken.
3] Alicia is a wrapper on top of crash.
Other dump solutions [ lkcd ] has sial scripting which is c like
and very effective. Not sure how difficult it will be to implement
something like sial in crash.
Do you have any plans of having scripting infrastructure in
crash ? If yes your thoughts on Alicia / sial / < any other stuff >
Regards
-Sachin
sub pdevices {
my ($name, $value, $maxdev, $i);
my (@chrdevlist, @sortedlist);
$maxdev = 255; # same as MAX_CHARDEV
$value = get_addr 'chrdevs';
@chrdevlist = get_mem $value,$maxdev;
@sortedlist = sort @chrdevlist;
print "Character devices:\n";
for ($i=0; $i < $maxdev; $i++) {
if ($sortedlist[$i] ne "0x00000000") {
$val = kernel($sortedlist[$i], 'char_device_struct', 'name', 'char
*' );
print "$i\t\t$val\n";
};
};
}
1;
8:44 a.m.
"Sachin P. Sant" wrote:
Dave, i came across one of the Crash TODO list items about having
a scripting infrastructure in crash.
I was trying to evaluate the Alicia utility [mentioned in todo list].
Here are some of my observations about Alicia.
1] It is a wrapper on top of crash.
2] One can write perl based scripts to extract infromation from dumps.
3] It has a nice report generation functionality which presents
the data in text as well as html format.
4] Provides functions which could be used to read data from crash
dumps.
5] It is easy to use and effective too.
Attached here is a sample script which i tried using Alicia to
display block and character devices. [ I know dev command already
does this stuff .. but for the sake of trying out the Alicia i chose
to write such a script ].
Also encountered few problems while trying out Alicia.
1] On PPC64 arch came across data type overflow problem while
executing the attached script.
2] On s390/s390x architecture class function provided by Alicia
seems broken.
3] Alicia is a wrapper on top of crash.
Other dump solutions [ lkcd ] has sial scripting which is c like
and very effective. Not sure how difficult it will be to implement
something like sial in crash.
Do you have any plans of having scripting infrastructure in
crash ? If yes your thoughts on Alicia / sial / < any other stuff >
I personally do not.
But, a few days ago, Luc Chouinard started looking into what it
would take to support sial scripting.
Dave
9:21 a.m.
On May 2, 2007 09:36:44 am Sachin P. Sant wrote:
Dave, i came across one of the Crash TODO list items about having
a scripting infrastructure in crash.
I was trying to evaluate the Alicia utility [mentioned in todo list].
Here are some of my observations about Alicia.
Hi Sachin,
I am developing a set of Python-bindings (plus scripts) that we are using in
HP,
http://sourceforge.net/projects/pykdump
To compare with Alicia:
1] It is a wrapper on top of crash.
Pykdump is an extension written in C for time-critical access plus a set of
Python libraries/scripts. Faster than Alicia 10-100 times :-)
2] One can write perl based scripts to extract infromation from
dumps.
The same - I am mainly working on 'xportshow.py' - printing nicely various
tables/structures, mostly IPv6 aware. Routing tables, TCP/UDP/IP connections
analysis, ARP-cache, Netfilter, devpack and so on.
3] It has a nice report generation functionality which presents
the data in text as well as html format.
Not done yet.
4] Provides functions which could be used to read data from crash
dumps.
The same
5] It is easy to use and effective too.
Attached here is a sample script which i tried using Alicia to
display block and character devices. [ I know dev command already
does this stuff .. but for the sake of trying out the Alicia i chose
to write such a script ].
Also encountered few problems while trying out Alicia.
1] On PPC64 arch came across data type overflow problem while
executing the attached script.
2] On s390/s390x architecture class function provided by Alicia
seems broken.
Python API ('Pykdump') at this moment works only on i686/AMD64/IA64 only. The
porting to other platforms should be trivial but I just did not look at this.
3] Alicia is a wrapper on top of crash.
Pykdump can both drive crash externally (via 'pexpect' Python module) or run
as an extension from inside 'crash' session, e.g.
crash64> epython xportshow.py --summary
Other dump solutions [ lkcd ] has sial scripting which is c like
and very effective. Not sure how difficult it will be to implement
something like sial in crash.
Do you have any plans of having scripting infrastructure in
crash ? If yes your thoughts on Alicia / sial / < any other stuff >
Regards,
Alex
--
------------------------------------------------------------------
Alexandre Sidorenko email: alexs(a)hplinux.canada.hp.com
Global Solutions Engineering: Unix Networking
Hewlett-Packard (Canada)
------------------------------------------------------------------
1:27 a.m.
Alex Sidorenko wrote:
> 1] It is a wrapper on top of crash.
>
Pykdump is an extension written in C for time-critical access plus a set of
Python libraries/scripts. Faster than Alicia 10-100 times :-)
C stuff is always simpler to understand and can easily be used. :-)
> 2] One can write perl based scripts to extract infromation from
dumps.
>
The same - I am mainly working on 'xportshow.py' - printing nicely various
tables/structures, mostly IPv6 aware. Routing tables, TCP/UDP/IP connections
analysis, ARP-cache, Netfilter, devpack and so on.
So pykdump will be used for printing TCP/IP related stuff or can be used
to extract other information as well ?
Pykdump can both drive crash externally (via 'pexpect' Python
module) or run
as an extension from inside 'crash' session, e.g.
crash64> epython xportshow.py --summary
Running extension / scripts within crash is good. But it won't harm running
the scripts/extensions externally as well.
Thanks
-Sachin
8:14 a.m.
On May 3, 2007 02:27:02 am Sachin P. Sant wrote:
> The same - I am mainly working on 'xportshow.py' -
printing nicely
> various tables/structures, mostly IPv6 aware. Routing tables, TCP/UDP/IP
> connections analysis, ARP-cache, Netfilter, devpack and so on.
>
So pykdump will be used for printing TCP/IP related stuff or can be used
to extract other information as well ?
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)
------------------------------------------------------------------
11:06 a.m.
Alex Sidorenko wrote:
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.
Hi Alex,
Thanks for the detailed mail. I agree with you on the utility of automated
scripts / programs in dump / live system analysis.
The reason behind starting this discussion on crash mailing list was to
get different ideas about having scripting infrastructure in crash.
Such an infrastructure in crash would really be useful [ writing scripts
on the fly or using already existing scripts packaged with crash ]
to extract information from a dump / live system.
I am not advocating for any one particular solution. I am open to any useful
solution. Eventually it's dave's call on which scripting infrastructure
( if any ) would go in crash :-)
Working with changing kernel code the requirement is the ability to easily
change the crash commands to reflect kernel changes. New analysis requirements
arise often, so the ability to quickly write new scripts is also needed.
Thanks
-Sachin
9:35 a.m.
On May 2, 2007 09:36:44 am Sachin P. Sant wrote:
Dave, i came across one of the Crash TODO list items about having
a scripting infrastructure in crash.
I was trying to evaluate the Alicia utility [mentioned in todo list].
Here are some of my observations about Alicia.
Hi Sachin,
I am developing a set of Python-bindings (plus scripts) that we are using in
HP,
http://sourceforge.net/projects/pykdump
To compare with Alicia:
1] It is a wrapper on top of crash.
Pykdump is an extension written in C for time-critical access plus a set of
Python libraries/scripts. Faster than Alicia 10-100 times :-)
2] One can write perl based scripts to extract infromation from
dumps.
The same - I am mainly working on 'xportshow.py' - printing nicely various
tables/structures, mostly IPv6 aware. Routing tables, TCP/UDP/IP connections
analysis, ARP-cache, Netfilter, devpack and so on.
3] It has a nice report generation functionality which presents
the data in text as well as html format.
Not done yet.
4] Provides functions which could be used to read data from crash
dumps.
The same
5] It is easy to use and effective too.
Attached here is a sample script which i tried using Alicia to
display block and character devices. [ I know dev command already
does this stuff .. but for the sake of trying out the Alicia i chose
to write such a script ].
Also encountered few problems while trying out Alicia.
1] On PPC64 arch came across data type overflow problem while
executing the attached script.
2] On s390/s390x architecture class function provided by Alicia
seems broken.
Python API ('Pykdump') at this moment works only on i686/AMD64/IA64 only. The
porting to other platforms should be trivial but I just did not look at this.
3] Alicia is a wrapper on top of crash.
Pykdump can both drive crash externally (via 'pexpect' Python module) or run
as an extension from inside 'crash' session, e.g.
crash64> epython xportshow.py --summary
Other dump solutions [ lkcd ] has sial scripting which is c like
and very effective. Not sure how difficult it will be to implement
something like sial in crash.
Do you have any plans of having scripting infrastructure in
crash ? If yes your thoughts on Alicia / sial / < any other stuff >
Regards,
Alex
--
------------------------------------------------------------------
Alexandre Sidorenko email: alexs(a)hplinux.canada.hp.com
Global Solutions Engineering: Unix Networking
Hewlett-Packard (Canada)
------------------------------------------------------------------
6264
days inactive
6270
days old
devel@lists.crash-utility.osci.io
6 comments
4 participants
participants (4)
-
Alex Sidorenko -
Alex Sidorenko -
Dave Anderson -
Sachin P. Sant