fault-injection-developer Mailing List for Fault Injection Test Harness (Page 13)
Status: Alpha
Brought to you by:
rustyl
Menu
▾
▴
fault-injection-developer — Developer discussions about creating a fault injection test harness.
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(13) |
Sep
(2) |
Oct
(49) |
Nov
(69) |
Dec
(70) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(64) |
Feb
(41) |
Mar
(25) |
Apr
(18) |
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2009 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2016 |
Jan
(2) |
Feb
(5) |
Mar
(2) |
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
|
From: Zhuang, L. <lou...@in...> - 2002-11-05 07:57:49
|
Dear all, we=A1=AFve updated FITH README against vanilla kernel. =20 Louis Zhuang, SW Engineer, Intel Corporation. My opinions are my own and NEVER the opinions of Intel Corporation. =20 |
|
From: Zhuang, L. <lou...@in...> - 2002-11-04 06:58:23
|
Developers have put whiter paper into CVS. Any comments are really welcome! -Louis |
|
From: Lynch, R. <rus...@in...> - 2002-10-29 00:30:30
|
Just in case somebody is waiting on me to do the PDF ==> DocBook conversion, I have the original editable documents but a priority interrupt (you know when your manager taps you on the shoulder to tackle whatever fire of the day) has kept me from making much progress yet. -rusty |
|
From: Lynch, R. <rus...@in...> - 2002-10-25 18:11:27
|
Yea, Rob walked over and let me know that it might not be such a
simple translation. If you send me your editable documents then
I will take care of it. At the very least it would be a good way
for me to perform a critical analysis of the design papers.
-rusty
-----Original Message-----
From: Zhuang, Louis
Sent: Friday, October 25, 2002 12:39 AM
To: Lynch, Rusty; Zhuang, Louis;
'fau...@so...'
Subject: RE: [Fault-injection-developer] Initial design documents are
here!
Oho, The DocBook is really hard... Rusty, could you possibly help
conversion? :-)
> -----Original Message-----
> From: Lynch, Rusty
> Sent: Friday, October 25, 2002 3:33 AM
> To: Zhuang, Louis; 'fau...@so...'
> Subject: RE: [Fault-injection-developer] Initial design
> documents are here!
>
>
> It would probably be a good idea to move this
> documentation to DocBook format.
> If you are not familiar with DocBook, it is an XML schema
> for writing documentation.
> Most open source projects are moving towards using
> DocBook for documentation,
> where part of the build process converts the xml files to
> other formats (like PDF
> or HTML.)
>
> If you would like, I can do the conversion. Just send me
> your editable documents
> (I am assuming they are MS Word documents) and I will
> port then to DocBook.
>
> -rusty
>
> -----Original Message-----
> From: Zhuang, Louis [mailto:lou...@in...]
> Sent: Thursday, October 24, 2002 2:38 AM
> To: 'fau...@so...'
> Subject: [Fault-injection-developer] Initial design
> documents are here!
>
>
> Hi,
> I've submitted initial design documents. Any comments
> are welcome!
> :)
> Louis Zhuang, SW Engineer, Intel Corporation.
> My opinions are my own and NEVER the opinions of Intel
> Corporation.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future
> of Java(TM) technology. Join the Java Community
> Process(SM) (JCP(SM)) program now.
> http://ad.doubleclick.net/clk;4729346;7592162;s?http://www
.sun.com/javavote
_______________________________________________
Fault-injection-developer mailing list
Fau...@li...
https://lists.sourceforge.net/lists/listinfo/fault-injection-developer
|
|
From: Zhuang, L. <lou...@in...> - 2002-10-25 07:40:55
|
Oho, The DocBook is really hard... Rusty, could you possibly help
conversion? :-)
> -----Original Message-----
> From: Lynch, Rusty
> Sent: Friday, October 25, 2002 3:33 AM
> To: Zhuang, Louis; 'fau...@so...'
> Subject: RE: [Fault-injection-developer] Initial design
> documents are here!
>
>
> It would probably be a good idea to move this
> documentation to DocBook format.
> If you are not familiar with DocBook, it is an XML schema
> for writing documentation.
> Most open source projects are moving towards using
> DocBook for documentation,
> where part of the build process converts the xml files to
> other formats (like PDF
> or HTML.)
>
> If you would like, I can do the conversion. Just send me
> your editable documents
> (I am assuming they are MS Word documents) and I will
> port then to DocBook.
>
> -rusty
>
> -----Original Message-----
> From: Zhuang, Louis [mailto:lou...@in...]
> Sent: Thursday, October 24, 2002 2:38 AM
> To: 'fau...@so...'
> Subject: [Fault-injection-developer] Initial design
> documents are here!
>
>
> Hi,
> I've submitted initial design documents. Any comments
> are welcome!
> :)
> Louis Zhuang, SW Engineer, Intel Corporation.
> My opinions are my own and NEVER the opinions of Intel
> Corporation.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future
> of Java(TM) technology. Join the Java Community
> Process(SM) (JCP(SM)) program now.
> http://ad.doubleclick.net/clk;4729346;7592162;s?http://www
.sun.com/javavote
_______________________________________________
Fault-injection-developer mailing list
Fau...@li...
https://lists.sourceforge.net/lists/listinfo/fault-injection-developer
|
|
From: Wang, S. <sta...@in...> - 2002-10-25 02:10:09
|
Please check my comments :)
And you can get more information from "FITH/doc/interceptor_lld.pdf".
> -----Original Message-----
> From: Lynch, Rusty=20
> Sent: 2002=E5=B9=B410=E6=9C=8825=E6=97=A5 2:35
> To: Wang, Stanley; Lynch, Rusty
> Cc: 'fau...@so...'
> Subject: RE: [Fault-injection-developer] How is the patched=20
> insmod making module_list available
>=20
>=20
> yea, I've done a good job of confusing people. :-> Let me explain...
>=20
> (NOTE: The explanation is really long, so stay with me. At least =
this
> will give me a forum for expressing my thoughts while looking=20
> through the code base.)
>=20
> When I start examining a project, I tend to take a bottom's=20
> up approach where:
> 1. I immediately start greping through the source code to get=20
> a feel for the design
> 2. I then start attempting to build the project
> 3. I then start hacking at the source to prove or disprove my=20
> understanding
> 4. After all of this I start reading design documents.
>=20
> For people who tend to approach problems from a higher level=20
> looking down, this=20
> will seem very backwards. All of the above is just an=20
> explanation for why I am
> doing what I am doing... you could say it's a method to my madness.
>=20
> So... I'm looking through the FITH cvs tree, trying to get a=20
> feel for how things
> are laid out. I observer that:
>=20
> * There is a user space utility called ficl, that is rooted=20
> in FITH/src/ficl/.
> I can see that it is communicating with some FITH kernel=20
> module via ictl() on
> a character device. For now that is all I care to know=20
> about ficl since I=20
> believe our immediate work is in implementing the kernel=20
> side code in such a=20
> way that the Linux kernel hacker community will accept.
>=20
> * There is a kernel character device called fith_dm.o that is=20
> rooted in=20
> FITH/src/dm/. After poking around some I can see:
> - this is a device that houses the kernel side logic used=20
> by other kernel=20
> side fault injection
> - the "dm" in the name means "Decision Maker". I note to=20
> myself that
> maybe fi_logic or something on those lines would make a=20
> better name,
> but I feel that I should think about it some more.
> - all communication seems to be over ictl() calls
>=20
> * There is another kernel character device called=20
> fith_fakeirq.o that is=20
> rooted in FITH/src/fakeirq. After poking around some I can see:
> - The only thing this module does is export a function=20
> called "fith_getirq"
> which is a replacement for "request_irq" function call.
The "fith_getirq" is only used when you want to inject fault into =
module
during it is initializing.
Fakeirq will search the "irq_desc" directly when you want to replace a
running module's interrupt handler :)
>=20
> * There are a bunch of other kernel modules in their own=20
> directories rooted
> under FITH/src/intcpt/. After some searching I figure out=20
> that "intcpt" means
> "interceptor", and that each of the directories under=20
> intcpt implement some kind
> of kernel side code for intercepting the normal operation=20
> of kernel code in order
> to insert a fault.
> - There is a module named "fith_aslt.o" rooted in=20
> FITH/src/intcpt/aslt/. =20
> + I manage to find a translation for "aslt" and the=20
> promptly loose it, and make=20
> a mental note to find a better name.
> + The module seems to just export a function called=20
> "fith_ioremap" that is a=20
> replacement for "__ioremap".
Acturally, aslt is a agent for pf. Hence you can even register a WP =
that
watch
an unmapped address.
> - There is a module named "fith_dbp.o" rooted in=20
> FITH/src/intcpt/dbp/.
> + I find that "dbp" means "Dynamic Binary Patch", and=20
> imediately start
> looking for functionality the duplicates existing=20
> projects (like dprobes.)
> + The only thing the module appears to do is register a=20
> bunch of exit functions
> using the "hooks.c" implementation (otherwise known as=20
> "Kernel Hooks".)=20
> + I make a mental note to myself that this is where FITH=20
> is dependant on
> dprobes (or at least this is where FITH is dependent on=20
> deprobes dependencies),=20
> and that this will be an immediate blocker to getting=20
> FITH to compile on=20
> 2.5.x since I'm pretty sure the hooks.c implementation=20
> has changed=20
> dramatically (or just doesn't exist) in 2.5.x kernels.
> - There is a module named "fith_dr.o" that is rooted in=20
> FITH/src/intcpt/dr/
> + It looks like this module does something like=20
> "fith_dbp", but it's
> not obvious what the purpose of this module is at first glance.
> + This module has the same hook.c dependencies as fith_dbp.o.
> - There is a module named "fith_ovr.o" that is rooted in=20
> FITH/src/intcpt/override/
> + It appears to implement replacements for the normal=20
> input/output functions
> like inb/outb and such. The functions do not seem to=20
> be exported so I'm=20
> not sure how they are used. I'm also confused by the=20
> fact that all of the
> standard input/output functions are either macros are=20
> inline functions, so
> I'm not sure how a loadable kernel module could replace=20
> these functions.
We use fith_ovr no longer :)
Fith_ovr is only used in the initial version of FITH. (Version A)
If you want to use this interceptor, you must recompile your module =
with a
special
header file:) you can find a example in "FITH/test/src".=20
> - There is a module named "fith_pf.o" that is rooted in=20
> FITH/src/intcpt/pt/
> + It looks like this module implements a kernel hook for=20
> page faults, but
> I only casually glanced at the code.
> + I'm pretty sure dpobes does the same thing, and wonder=20
> if this isn't something
> that could be done using dprobes.
>=20
> * There is a patched version of insmod rooted in FITH/fith_insmod/
> + After poking around I figure out that this is the entire
> modutils v2.4.6 package, and that the only file that has been=20
> touched (other then a bunch of CVS symbols that were changed
> because we imported the source to our own cvs tree) was
> FITH/fith_insmod/insmod/insmod.c
> + I get a good feel for what the hacked up version of=20
> insmod is doing, and how
> it is using the kernel modules that I already discovered.
Our patch for insmod didn't impact its main workflow. We just
replace some instructions ("in/out") and two symbols ("ioremap" and
"request_irq").=20
Nothing else :)
>=20
>=20
> Ok, now I have some kind of a clue as to what this whole FITH source
> tree is trying to do. I compile the source on a RH7.3 system=20
> by following
> the instructions in the README and don't run into any=20
> problems. Now I start
> attempting to build on a RH8.0 system where I have been=20
> playing with a=20
> 2.5.44 kernel.
>=20
> The first thing I trip on is the lack of a kernel hook=20
> implementation, so
> I do a little research and find the whole kprobes vrs.=20
> dprobes discussion
> happening on lkml.=20
>=20
> I then start trying to build fith_fakeirq.o=20
> (FITH/src/fakeirq/) and run into
> all kinds of problems with hard coded assumptions in the FITH=20
> build scripts.
> Since I have already convinced myself that all of the FITH=20
> kernel could should
> build inside the Linux kernel tree, I move over fakeirq.c and=20
> the fith header
> files to the 2.5.44 kernel tree and do not give a second=20
> thought as to why
> I was seeing all the strange compile problems when building=20
> within the FITH
> source tree.
>=20
> The fakeirq.c code doesn't have the kernel hook dependencies=20
> as some of the
> other modules, so it seems like a good starting point. I'm=20
> able to build
> just fine, but have some symbol resolution problems. A=20
> couple of these=20
> are the symbols that the patch discussed in an earlier thread=20
> exports. I
> just hack the fith header file that depends on the both of=20
> these symbols
> and now the only unresolved symbol is "module_list".
>=20
> It takes me a while to figure out where module_list is coming=20
> from. None of
> the FITH code implements module_list, so it's not a=20
> dependency on one of the=20
> other FITH kernel modules. Then I notice that a symbol named=20
> module_list is
> used in the insmod utility. I suspect that maybe the hacked=20
> version of insmod
> provides the symbol so I try to load fakeirq.o with a patched insmod.
>=20
The "module_list" is introduced by "__MOD_INC_USE_COUNT". This Marco
is used in fith_lock_module, and this function is defined in
"FITH/include/linux/fith/fith_internal.h".
The "module_list" is not a exported symbol in vanilla kernel, and it =
will be
exported by Dprobes.
I've add some comments for this symbol in README.
> insmod fails because it can not open "/dev/fith", so I check=20
> out insmod.c
> and verify that if insmod.c can open /dev/fith, it will=20
> continue with loading
> the kernel module. insmod.c will attempt to do some dirty=20
> tricks on the module
> with the help of /dev/fith, but even if /dev/fith was really=20
> /dev/null insmod
> will still completely load the module and just print an error=20
> message about not
> being able to insert a fault set. So I trick insmod by=20
> making a /dev/fith node
> with major and minor numbers for /dev/null, and I convince=20
> myself that I am able=20
> to load fakeirq.o without running into problems with=20
> unresolved symbols.=20
>=20
> After looking into this some more this morning I realized=20
> that I was wrong, and=20
> that the patched insmod was not able to load the module, so I=20
> still do not know
> now module_list was supposed to be resolved. Maybe this was=20
> a symbol that existed
> in 2.4.x?
"module_list" exists in 2.5 also. It is defined in kernel/modules.c
So many thanks for your great and hard work :)
=20
Stanley
>=20
> What a long, lingering email.... if you made it this far the=20
> I must apologize for
> this horribly crafted email. :-(
>=20
> -rusty
>=20
>=20
> -----Original Message-----
> From: Wang, Stanley=20
> Sent: Thursday, October 24, 2002 12:56 AM
> To: Lynch, Rusty
> Cc: 'fau...@so...'
> Subject: RE: [Fault-injection-developer] How is the patched insmod
> making module_list available
>=20
>=20
> I've been totally confused.
> As I know, the fith_insmod depends on fith_dm, and fith_dm=20
> depends on all interceptors (includeing fith_fakeirq).
> So fith_insmod will return an error unless all FITH's modules=20
> have been loaded into kernel.
> Can you give me more information about the error you encounted, =
Rusty?
>=20
> Thanks :)
> Stanley
> -----Original Message-----
> From: Lynch, Rusty [mailto:rus...@in...]
> Sent: 2002?10?24? 10:52
> To: 'fau...@so...'
> Subject: RE: [Fault-injection-developer] How is the patched=20
> insmod making module_list available
>=20
>=20
> Actually, it's fakeirq.o, not fith_fakeirq. (hmm... maybe the=20
> build script that I tossed out the window is moving fakeirq.o=20
> to fith_fakeirq.o? It doesn't matter... I'm just getting a feel
> for the code.)
>=20
> * NOTE: Keep in mind I hacked out the need for the symbols your
> kernel patch was depending on.
>=20
> [rusty@penguin2 rusty]$ sudo /sbin/insmod fakeirq
> Using
> /lib/modules/2.5.44-ac2/kernel/drivers/faultinjection/fakeirq/
> fakeirq.o
> /lib/modules/2.5.44-ac2/kernel/drivers/faultinjection/fakeirq/
> fakeirq.o:
> unresolved symbol module_list
>=20
> I can add all kinds of unresolved symbols to a module and fith_insmod =
> is happy to install the module.
>=20
> -rusty
>=20
> -----Original Message-----
> From: Zhuang, Louis=20
> Sent: Wednesday, October 23, 2002 7:37 PM
> To: Lynch, Rusty
> Subject: RE: [Fault-injection-developer] How is the patched insmod
> making module_list available
>=20
>=20
> Rusty,
> Did you mean you can not insert fith_fakeirq by normal insmod?
>=20
> > -----Original Message-----
> > From: Lynch, Rusty=20
> > Sent: Thursday, October 24, 2002 10:17 AM
> > To: Zhuang, Louis; Lynch, Rusty
> > Subject: RE: [Fault-injection-developer] How is the=20
> > patched insmod making module_list available
> >=20
> >=20
> > What's there to log? /sbin/insmod fails because of an=20
> > undefined symbol, module_list.
> >=20
> > Although it looks like it has nothing to do with 2.5.44. =20
> > I think the patched insmod=20
> > just doesn't catch the fact that module_list is not=20
> > defined. Kind of a side effect?
> >=20
> > -rusty
> >=20
> > -----Original Message-----
> > From: Zhuang, Louis=20
> > Sent: Wednesday, October 23, 2002 7:11 PM
> > To: Lynch, Rusty
> > Subject: RE: [Fault-injection-developer] How is the=20
> patched insmod
> > making module_list available
> >=20
> >=20
> > We have not a try for 2.5.44... could you give us your=20
> error log?
> >=20
> > > -----Original Message-----
> > > From: Lynch, Rusty [mailto:rus...@in...]
> > > Sent: Thursday, October 24, 2002 10:02 AM
> > > To: 'fau...@so...'
> > > Subject: [Fault-injection-developer] How is the patched=20
> > > insmod making module_list available
> > >=20
> > >=20
> > > I'm checking out the code and trying to get fakeirq.c to=20
> > > compile with the
> > > 2.5.44 kernel, but have an unresolved symbol for=20
> > > "module_list" unless I use
> > > the patched insmod.
> > >=20
> > > What's up with that? It looks like all that was changed=20
> > > in the insmod
> > > source tree was insmod.c, and I don't see anything having =
> > > to do with
> > > "module_list".
> > >=20
> > > -rusty=20
> > >=20
> > >=20
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by: Influence the future=20
> > > of Java(TM) technology. Join the Java Community=20
> > > Process(SM) (JCP(SM)) program now.=20
> > > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
> > >=20
> > > _______________________________________________
> > > Fault-injection-developer mailing list
> > > Fau...@li...
> > > =
https://lists.sourceforge.net/lists/listinfo/fault-injecti
> > on-developer
> >=20
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future=20
> of Java(TM) technology. Join the Java Community=20
> Process(SM) (JCP(SM)) program now.=20
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
>=20
> _______________________________________________
> Fault-injection-developer mailing list
> Fau...@li...
> =
https://lists.sourceforge.net/lists/listinfo/fault-injection-developer
>=20
|
|
From: Zhuang, L. <lou...@in...> - 2002-10-25 00:42:27
|
Good point! We'll change them into 'die-hard' DocBook :) Louis Zhuang, SW Engineer, Intel Corporation. My opinions are my own and NEVER the opinions of Intel Corporation. -----Original Message----- From: Rob Rhoads [mailto:err...@li...] Sent: Friday, October 25, 2002 3:52 AM To: Rusty Lynch Cc: Zhuang, Louis; 'fau...@so...' Subject: RE: [Fault-injection-developer] Initial design documents are here ! On Thu, 2002-10-24 at 12:32, Lynch, Rusty wrote: > It would probably be a good idea to move this documentation to DocBook > format. > If you are not familiar with DocBook, it is an XML schema for writing > documentation. > Most open source projects are moving towards using DocBook for > documentation, > where part of the build process converts the xml files to other formats > (like PDF > or HTML.) > > If you would like, I can do the conversion. Just send me your editable > documents > (I am assuming they are MS Word documents) and I will port then to DocBook. > > -rusty If you're really a die-hard & interested in learning all about DocBook there's an on-line book at the following: http://www.oreilly.com/catalog/docbook/chapter/book/docbook.html -- Rob Rhoads mailto:err...@li... Telecom Software Platforms office: 503-677-5498 Intel Communications Group <disclaimer value="pointless"> This email message solely contains my own personal views, and not necessarily those of my employer. </disclaimer> ------------------------------------------------------- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en _______________________________________________ Fault-injection-developer mailing list Fau...@li... https://lists.sourceforge.net/lists/listinfo/fault-injection-developer |
|
From: Lynch, R. <rus...@in...> - 2002-10-24 22:47:51
|
Fault Injection Test Harness Status Report
Date: October 24, 2002
As a result of feedback from the Linux Kernel Mailing List (LKML) for a
general need for a fault injection tool to aid kernel developers in finding
bugs in the kernel, this project has experienced a boost over the last
couple
of weeks. A large part of this increase in activity has been a review of
the
source code uploaded by Louis, Stanley, and Frank.
Several discussions have been sparked with the following changes agreed on:
* Kernel and user space code needs to be separated into two trees
- It makes it much harder to follow when the two types of code are mixed
- It makes it much harder to get our code reviewed by kernel developers
- The kernel code needs to be ported to the 2.5 kernel
- In general Linux kernel development is happening on the 2.5 kernel.
If we hope to make a real contribution to Linux we need to be were the
development is happening.
- We need to rethink our naming scheme
- There is a proposal to make 'fith' only refer to the user space
utilities
that take advantage of fault injection features in the kernel
- For kernel level code, a suggestion was made to use 'fi' to indicate
'fault injection'. Some examples of where this would be used are:
* 'fi_interceptor' to indicate kernel module that intercepts a specific
type of kernel action in order to inject a fault.
* We believe that the current state of the project would not be well
received
by LKML, so we looking over everything we have so far and targeting an
LKML
announcement by Christmas.
----------------------------------------------------------------------------
Rusty Lynch
Staff Software Engineer, Intel Corporation
rus...@in...
* This email message solely contains my own personal views, and not
necessarily those of my employer
|
|
From: Rob R. <err...@li...> - 2002-10-24 19:52:20
|
On Thu, 2002-10-24 at 12:32, Lynch, Rusty wrote: > It would probably be a good idea to move this documentation to DocBook > format. > If you are not familiar with DocBook, it is an XML schema for writing > documentation. > Most open source projects are moving towards using DocBook for > documentation, > where part of the build process converts the xml files to other formats > (like PDF > or HTML.) > > If you would like, I can do the conversion. Just send me your editable > documents > (I am assuming they are MS Word documents) and I will port then to DocBook. > > -rusty If you're really a die-hard & interested in learning all about DocBook there's an on-line book at the following: http://www.oreilly.com/catalog/docbook/chapter/book/docbook.html -- Rob Rhoads mailto:err...@li... Telecom Software Platforms office: 503-677-5498 Intel Communications Group <disclaimer value="pointless"> This email message solely contains my own personal views, and not necessarily those of my employer. </disclaimer> |
|
From: Lynch, R. <rus...@in...> - 2002-10-24 19:32:41
|
It would probably be a good idea to move this documentation to DocBook format. If you are not familiar with DocBook, it is an XML schema for writing documentation. Most open source projects are moving towards using DocBook for documentation, where part of the build process converts the xml files to other formats (like PDF or HTML.) If you would like, I can do the conversion. Just send me your editable documents (I am assuming they are MS Word documents) and I will port then to DocBook. -rusty -----Original Message----- From: Zhuang, Louis [mailto:lou...@in...] Sent: Thursday, October 24, 2002 2:38 AM To: 'fau...@so...' Subject: [Fault-injection-developer] Initial design documents are here! Hi, I've submitted initial design documents. Any comments are welcome! :) Louis Zhuang, SW Engineer, Intel Corporation. My opinions are my own and NEVER the opinions of Intel Corporation. ------------------------------------------------------- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4729346;7592162;s?http://www.sun.com/javavote _______________________________________________ Fault-injection-developer mailing list Fau...@li... https://lists.sourceforge.net/lists/listinfo/fault-injection-developer |
|
From: Lynch, R. <rus...@in...> - 2002-10-24 18:35:25
|
yea, I've done a good job of confusing people. :-> Let me explain...
(NOTE: The explanation is really long, so stay with me. At least this
will give me a forum for expressing my thoughts while looking=20
through the code base.)
When I start examining a project, I tend to take a bottom's up approach
where:
1. I immediately start greping through the source code to get a feel for =
the
design
2. I then start attempting to build the project
3. I then start hacking at the source to prove or disprove my understandi=
ng
4. After all of this I start reading design documents.
For people who tend to approach problems from a higher level looking down=
,
this=20
will seem very backwards. All of the above is just an explanation for wh=
y I
am
doing what I am doing... you could say it's a method to my madness.
So... I'm looking through the FITH cvs tree, trying to get a feel for how
things
are laid out. I observer that:
* There is a user space utility called ficl, that is rooted in
FITH/src/ficl/.
I can see that it is communicating with some FITH kernel module via ict=
l()
on
a character device. For now that is all I care to know about ficl sinc=
e I
believe our immediate work is in implementing the kernel side code in s=
uch
a=20
way that the Linux kernel hacker community will accept.
* There is a kernel character device called fith_dm.o that is rooted in=20
FITH/src/dm/. After poking around some I can see:
- this is a device that houses the kernel side logic used by other kern=
el=20
side fault injection
- the "dm" in the name means "Decision Maker". I note to myself that
maybe fi_logic or something on those lines would make a better name,
but I feel that I should think about it some more.
- all communication seems to be over ictl() calls
* There is another kernel character device called fith_fakeirq.o that is=20
rooted in FITH/src/fakeirq. After poking around some I can see:
- The only thing this module does is export a function called
"fith_getirq"
which is a replacement for "request_irq" function call.
* There are a bunch of other kernel modules in their own directories root=
ed
under FITH/src/intcpt/. After some searching I figure out that "intcpt=
"
means
"interceptor", and that each of the directories under intcpt implement
some kind
of kernel side code for intercepting the normal operation of kernel cod=
e
in order
to insert a fault.
- There is a module named "fith_aslt.o" rooted in FITH/src/intcpt/aslt/=
. =20
+ I manage to find a translation for "aslt" and the promptly loose it=
,
and make=20
a mental note to find a better name.
+ The module seems to just export a function called "fith_ioremap" th=
at
is a=20
replacement for "__ioremap".
- There is a module named "fith_dbp.o" rooted in FITH/src/intcpt/dbp/.
+ I find that "dbp" means "Dynamic Binary Patch", and imediately star=
t
looking for functionality the duplicates existing projects (like
dprobes.)
+ The only thing the module appears to do is register a bunch of exit
functions
using the "hooks.c" implementation (otherwise known as "Kernel
Hooks".)=20
+ I make a mental note to myself that this is where FITH is dependant=
on
dprobes (or at least this is where FITH is dependent on deprobes
dependencies),=20
and that this will be an immediate blocker to getting FITH to compi=
le
on=20
2.5.x since I'm pretty sure the hooks.c implementation has changed=20
dramatically (or just doesn't exist) in 2.5.x kernels.
- There is a module named "fith_dr.o" that is rooted in
FITH/src/intcpt/dr/
+ It looks like this module does something like "fith_dbp", but it's
not obvious what the purpose of this module is at first glance.
+ This module has the same hook.c dependencies as fith_dbp.o.
- There is a module named "fith_ovr.o" that is rooted in
FITH/src/intcpt/override/
+ It appears to implement replacements for the normal input/output
functions
like inb/outb and such. The functions do not seem to be exported s=
o
I'm=20
not sure how they are used. I'm also confused by the fact that all=
of
the
standard input/output functions are either macros are inline
functions, so
I'm not sure how a loadable kernel module could replace these
functions.
- There is a module named "fith_pf.o" that is rooted in
FITH/src/intcpt/pt/
+ It looks like this module implements a kernel hook for page faults,
but
I only casually glanced at the code.
+ I'm pretty sure dpobes does the same thing, and wonder if this isn'=
t
something
that could be done using dprobes.
* There is a patched version of insmod rooted in FITH/fith_insmod/
+ After poking around I figure out that this is the entire
modutils v2.4.6 package, and that the only file that has been=20
touched (other then a bunch of CVS symbols that were changed
because we imported the source to our own cvs tree) was
FITH/fith_insmod/insmod/insmod.c
+ I get a good feel for what the hacked up version of insmod is doing,
and how
it is using the kernel modules that I already discovered.
Ok, now I have some kind of a clue as to what this whole FITH source
tree is trying to do. I compile the source on a RH7.3 system by followin=
g
the instructions in the README and don't run into any problems. Now I st=
art
attempting to build on a RH8.0 system where I have been playing with a=20
2.5.44 kernel.
The first thing I trip on is the lack of a kernel hook implementation, so
I do a little research and find the whole kprobes vrs. dprobes discussion
happening on lkml.=20
I then start trying to build fith_fakeirq.o (FITH/src/fakeirq/) and run i=
nto
all kinds of problems with hard coded assumptions in the FITH build scrip=
ts.
Since I have already convinced myself that all of the FITH kernel could
should
build inside the Linux kernel tree, I move over fakeirq.c and the fith
header
files to the 2.5.44 kernel tree and do not give a second thought as to wh=
y
I was seeing all the strange compile problems when building within the FI=
TH
source tree.
The fakeirq.c code doesn't have the kernel hook dependencies as some of t=
he
other modules, so it seems like a good starting point. I'm able to build
just fine, but have some symbol resolution problems. A couple of these=20
are the symbols that the patch discussed in an earlier thread exports. I
just hack the fith header file that depends on the both of these symbols
and now the only unresolved symbol is "module_list".
It takes me a while to figure out where module_list is coming from. None=
of
the FITH code implements module_list, so it's not a dependency on one of =
the
other FITH kernel modules. Then I notice that a symbol named module_list=
is
used in the insmod utility. I suspect that maybe the hacked version of
insmod
provides the symbol so I try to load fakeirq.o with a patched insmod.
insmod fails because it can not open "/dev/fith", so I check out insmod.c
and verify that if insmod.c can open /dev/fith, it will continue with
loading
the kernel module. insmod.c will attempt to do some dirty tricks on the
module
with the help of /dev/fith, but even if /dev/fith was really /dev/null
insmod
will still completely load the module and just print an error message abo=
ut
not
being able to insert a fault set. So I trick insmod by making a /dev/fit=
h
node
with major and minor numbers for /dev/null, and I convince myself that I =
am
able=20
to load fakeirq.o without running into problems with unresolved symbols.=20
After looking into this some more this morning I realized that I was wron=
g,
and=20
that the patched insmod was not able to load the module, so I still do no=
t
know
now module_list was supposed to be resolved. Maybe this was a symbol tha=
t
existed
in 2.4.x?
What a long, lingering email.... if you made it this far the I must
apologize for
this horribly crafted email. :-(
-rusty
-----Original Message-----
From: Wang, Stanley=20
Sent: Thursday, October 24, 2002 12:56 AM
To: Lynch, Rusty
Cc: 'fau...@so...'
Subject: RE: [Fault-injection-developer] How is the patched insmod
making module_list available
I've been totally confused.
As I know, the fith_insmod depends on fith_dm, and fith_dm depends on all
interceptors (includeing fith_fakeirq).
So fith_insmod will return an error unless all FITH's modules have been
loaded into kernel.
Can you give me more information about the error you encounted, Rusty?
Thanks :)
Stanley
-----Original Message-----
From: Lynch, Rusty [mailto:rus...@in...]
Sent: 2002=E5=B9=B410=E6=9C=8824=E6=97=A5 10:52
To: 'fau...@so...'
Subject: RE: [Fault-injection-developer] How is the patched insmod making
module_list available
Actually, it's fakeirq.o, not fith_fakeirq. (hmm... maybe the=20
build script that I tossed out the window is moving fakeirq.o=20
to fith_fakeirq.o? It doesn't matter... I'm just getting a feel
for the code.)
* NOTE: Keep in mind I hacked out the need for the symbols your
kernel patch was depending on.
[rusty@penguin2 rusty]$ sudo /sbin/insmod fakeirq
Using
/lib/modules/2.5.44-ac2/kernel/drivers/faultinjection/fakeirq/fakeirq.o
/lib/modules/2.5.44-ac2/kernel/drivers/faultinjection/fakeirq/fakeirq.o:
unresolved symbol module_list
I can add all kinds of unresolved symbols to a module and fith_insmod=20
is happy to install the module.
-rusty
-----Original Message-----
From: Zhuang, Louis=20
Sent: Wednesday, October 23, 2002 7:37 PM
To: Lynch, Rusty
Subject: RE: [Fault-injection-developer] How is the patched insmod
making module_list available
Rusty,
Did you mean you can not insert fith_fakeirq by normal insmod?
> -----Original Message-----
> From: Lynch, Rusty=20
> Sent: Thursday, October 24, 2002 10:17 AM
> To: Zhuang, Louis; Lynch, Rusty
> Subject: RE: [Fault-injection-developer] How is the=20
> patched insmod making module_list available
>=20
>=20
> What's there to log? /sbin/insmod fails because of an=20
> undefined symbol, module_list.
>=20
> Although it looks like it has nothing to do with 2.5.44. =20
> I think the patched insmod=20
> just doesn't catch the fact that module_list is not=20
> defined. Kind of a side effect?
>=20
> -rusty
>=20
> -----Original Message-----
> From: Zhuang, Louis=20
> Sent: Wednesday, October 23, 2002 7:11 PM
> To: Lynch, Rusty
> Subject: RE: [Fault-injection-developer] How is the patched insmod
> making module_list available
>=20
>=20
> We have not a try for 2.5.44... could you give us your error log?
>=20
> > -----Original Message-----
> > From: Lynch, Rusty [mailto:rus...@in...]
> > Sent: Thursday, October 24, 2002 10:02 AM
> > To: 'fau...@so...'
> > Subject: [Fault-injection-developer] How is the patched=20
> > insmod making module_list available
> >=20
> >=20
> > I'm checking out the code and trying to get fakeirq.c to=20
> > compile with the
> > 2.5.44 kernel, but have an unresolved symbol for=20
> > "module_list" unless I use
> > the patched insmod.
> >=20
> > What's up with that? It looks like all that was changed=20
> > in the insmod
> > source tree was insmod.c, and I don't see anything having=20
> > to do with
> > "module_list".
> >=20
> > -rusty=20
> >=20
> >=20
> > -------------------------------------------------------
> > This sf.net email is sponsored by: Influence the future=20
> > of Java(TM) technology. Join the Java Community=20
> > Process(SM) (JCP(SM)) program now.=20
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
> >=20
> > _______________________________________________
> > Fault-injection-developer mailing list
> > Fau...@li...
> > https://lists.sourceforge.net/lists/listinfo/fault-injecti
> on-developer
>=20
-------------------------------------------------------
This sf.net email is sponsored by: Influence the future=20
of Java(TM) technology. Join the Java Community=20
Process(SM) (JCP(SM)) program now.=20
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
_______________________________________________
Fault-injection-developer mailing list
Fau...@li...
https://lists.sourceforge.net/lists/listinfo/fault-injection-developer
|
|
From: Zhuang, L. <lou...@in...> - 2002-10-24 09:40:25
|
Hi, I've submitted initial design documents. Any comments are welcome! :) Louis Zhuang, SW Engineer, Intel Corporation. My opinions are my own and NEVER the opinions of Intel Corporation. |
|
From: Wang, S. <sta...@in...> - 2002-10-24 07:57:59
|
I've been totally confused.
As I know, the fith_insmod depends on fith_dm, and fith_dm depends on =
all
interceptors (includeing fith_fakeirq).
So fith_insmod will return an error unless all FITH's modules have been
loaded into kernel.
Can you give me more information about the error you encounted, Rusty?
Thanks :)
Stanley
-----Original Message-----
From: Lynch, Rusty [mailto:rus...@in...]
Sent: 2002=E5=B9=B410=E6=9C=8824=E6=97=A5 10:52
To: 'fau...@so...'
Subject: RE: [Fault-injection-developer] How is the patched insmod =
making
module_list available
Actually, it's fakeirq.o, not fith_fakeirq. (hmm... maybe the=20
build script that I tossed out the window is moving fakeirq.o=20
to fith_fakeirq.o? It doesn't matter... I'm just getting a feel
for the code.)
* NOTE: Keep in mind I hacked out the need for the symbols your
kernel patch was depending on.
[rusty@penguin2 rusty]$ sudo /sbin/insmod fakeirq
Using
/lib/modules/2.5.44-ac2/kernel/drivers/faultinjection/fakeirq/fakeirq.o
/lib/modules/2.5.44-ac2/kernel/drivers/faultinjection/fakeirq/fakeirq.o:=
unresolved symbol module_list
I can add all kinds of unresolved symbols to a module and fith_insmod=20
is happy to install the module.
-rusty
-----Original Message-----
From: Zhuang, Louis=20
Sent: Wednesday, October 23, 2002 7:37 PM
To: Lynch, Rusty
Subject: RE: [Fault-injection-developer] How is the patched insmod
making module_list available
Rusty,
Did you mean you can not insert fith_fakeirq by normal insmod?
> -----Original Message-----
> From: Lynch, Rusty=20
> Sent: Thursday, October 24, 2002 10:17 AM
> To: Zhuang, Louis; Lynch, Rusty
> Subject: RE: [Fault-injection-developer] How is the=20
> patched insmod making module_list available
>=20
>=20
> What's there to log? /sbin/insmod fails because of an=20
> undefined symbol, module_list.
>=20
> Although it looks like it has nothing to do with 2.5.44. =20
> I think the patched insmod=20
> just doesn't catch the fact that module_list is not=20
> defined. Kind of a side effect?
>=20
> -rusty
>=20
> -----Original Message-----
> From: Zhuang, Louis=20
> Sent: Wednesday, October 23, 2002 7:11 PM
> To: Lynch, Rusty
> Subject: RE: [Fault-injection-developer] How is the patched =
insmod
> making module_list available
>=20
>=20
> We have not a try for 2.5.44... could you give us your error log?
>=20
> > -----Original Message-----
> > From: Lynch, Rusty [mailto:rus...@in...]
> > Sent: Thursday, October 24, 2002 10:02 AM
> > To: 'fau...@so...'
> > Subject: [Fault-injection-developer] How is the patched=20
> > insmod making module_list available
> >=20
> >=20
> > I'm checking out the code and trying to get fakeirq.c to=20
> > compile with the
> > 2.5.44 kernel, but have an unresolved symbol for=20
> > "module_list" unless I use
> > the patched insmod.
> >=20
> > What's up with that? It looks like all that was changed=20
> > in the insmod
> > source tree was insmod.c, and I don't see anything having=20
> > to do with
> > "module_list".
> >=20
> > -rusty=20
> >=20
> >=20
> > -------------------------------------------------------
> > This sf.net email is sponsored by: Influence the future=20
> > of Java(TM) technology. Join the Java Community=20
> > Process(SM) (JCP(SM)) program now.=20
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
> >=20
> > _______________________________________________
> > Fault-injection-developer mailing list
> > Fau...@li...
> > https://lists.sourceforge.net/lists/listinfo/fault-injecti
> on-developer
>=20
-------------------------------------------------------
This sf.net email is sponsored by: Influence the future=20
of Java(TM) technology. Join the Java Community=20
Process(SM) (JCP(SM)) program now.=20
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
_______________________________________________
Fault-injection-developer mailing list
Fau...@li...
https://lists.sourceforge.net/lists/listinfo/fault-injection-developer
|
|
From: Zhuang, L. <lou...@in...> - 2002-10-24 03:30:09
|
Good ideas! We'll separate FITH into two parts, one is user level, the other
is patch and kernel module... About name convention... let's do some
change...
P.S. ASLT is an Address Translator. We stolen the name from XSLT. Sorry for
my odd naming :-)
> -----Original Message-----
> From: Lynch, Rusty [mailto:rus...@in...]
> Sent: Thursday, October 24, 2002 10:53 AM
> To: 'fau...@so...'
> Subject: [Fault-injection-developer] naming used for
> kernel components
>
>
> I'm not sure if anyone else is having this problem, but
> the naming of the
> files is really throwing me for a loop. It seems that
> every time I look at
> one of the file names or directory names I have to think
> hard about what is
> inside instead of it being obvious from the name.
>
> For example, I don't remember what in the world
> aslt/aslt.c was supposed to
> be, but I know I ran across some documentation in some
> file, but I lost it.
> Typically the names of 'c' files in the kernel tree give
> you a pretty good
> clue about what you are looking at.
>
> What if we took a slightly different approach to this:
> * since we need to separate the kernel code from the user
> space code, why
> not use the term "fith" to just refer to the user space
> tools that take
> advantage of the fault injection functionality in the kernel.
> * if you buy into the above argument, then we could start
> using the letters
> "fi" to indicate fault injection in a naming schema used
> for kernel code.
> From most of my searching for fault injection technology
> on the net, "fi" is
> a really common abbreviation for "fault injection".
> * instead of intcpt, we could use "fi_interceptor" which
> is still fairly
> short (well kinda) but is much more descriptive.
>
> I noticed some others by they escape me for now... I'll
> come back with a
> better list.
>
> -rusty
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future
> of Java(TM) technology. Join the Java Community
> Process(SM) (JCP(SM)) program now.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
>
> _______________________________________________
> Fault-injection-developer mailing list
> Fau...@li...
> https://lists.sourceforge.net/lists/listinfo/fault-injecti
on-developer
|
|
From: Lynch, R. <rus...@in...> - 2002-10-24 02:53:11
|
I'm not sure if anyone else is having this problem, but the naming of the files is really throwing me for a loop. It seems that every time I look at one of the file names or directory names I have to think hard about what is inside instead of it being obvious from the name. For example, I don't remember what in the world aslt/aslt.c was supposed to be, but I know I ran across some documentation in some file, but I lost it. Typically the names of 'c' files in the kernel tree give you a pretty good clue about what you are looking at. What if we took a slightly different approach to this: * since we need to separate the kernel code from the user space code, why not use the term "fith" to just refer to the user space tools that take advantage of the fault injection functionality in the kernel. * if you buy into the above argument, then we could start using the letters "fi" to indicate fault injection in a naming schema used for kernel code. From most of my searching for fault injection technology on the net, "fi" is a really common abbreviation for "fault injection". * instead of intcpt, we could use "fi_interceptor" which is still fairly short (well kinda) but is much more descriptive. I noticed some others by they escape me for now... I'll come back with a better list. -rusty |
|
From: Lynch, R. <rus...@in...> - 2002-10-24 02:51:34
|
Actually, it's fakeirq.o, not fith_fakeirq. (hmm... maybe the
build script that I tossed out the window is moving fakeirq.o
to fith_fakeirq.o? It doesn't matter... I'm just getting a feel
for the code.)
* NOTE: Keep in mind I hacked out the need for the symbols your
kernel patch was depending on.
[rusty@penguin2 rusty]$ sudo /sbin/insmod fakeirq
Using
/lib/modules/2.5.44-ac2/kernel/drivers/faultinjection/fakeirq/fakeirq.o
/lib/modules/2.5.44-ac2/kernel/drivers/faultinjection/fakeirq/fakeirq.o:
unresolved symbol module_list
I can add all kinds of unresolved symbols to a module and fith_insmod
is happy to install the module.
-rusty
-----Original Message-----
From: Zhuang, Louis
Sent: Wednesday, October 23, 2002 7:37 PM
To: Lynch, Rusty
Subject: RE: [Fault-injection-developer] How is the patched insmod
making module_list available
Rusty,
Did you mean you can not insert fith_fakeirq by normal insmod?
> -----Original Message-----
> From: Lynch, Rusty
> Sent: Thursday, October 24, 2002 10:17 AM
> To: Zhuang, Louis; Lynch, Rusty
> Subject: RE: [Fault-injection-developer] How is the
> patched insmod making module_list available
>
>
> What's there to log? /sbin/insmod fails because of an
> undefined symbol, module_list.
>
> Although it looks like it has nothing to do with 2.5.44.
> I think the patched insmod
> just doesn't catch the fact that module_list is not
> defined. Kind of a side effect?
>
> -rusty
>
> -----Original Message-----
> From: Zhuang, Louis
> Sent: Wednesday, October 23, 2002 7:11 PM
> To: Lynch, Rusty
> Subject: RE: [Fault-injection-developer] How is the patched insmod
> making module_list available
>
>
> We have not a try for 2.5.44... could you give us your error log?
>
> > -----Original Message-----
> > From: Lynch, Rusty [mailto:rus...@in...]
> > Sent: Thursday, October 24, 2002 10:02 AM
> > To: 'fau...@so...'
> > Subject: [Fault-injection-developer] How is the patched
> > insmod making module_list available
> >
> >
> > I'm checking out the code and trying to get fakeirq.c to
> > compile with the
> > 2.5.44 kernel, but have an unresolved symbol for
> > "module_list" unless I use
> > the patched insmod.
> >
> > What's up with that? It looks like all that was changed
> > in the insmod
> > source tree was insmod.c, and I don't see anything having
> > to do with
> > "module_list".
> >
> > -rusty
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: Influence the future
> > of Java(TM) technology. Join the Java Community
> > Process(SM) (JCP(SM)) program now.
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
> >
> > _______________________________________________
> > Fault-injection-developer mailing list
> > Fau...@li...
> > https://lists.sourceforge.net/lists/listinfo/fault-injecti
> on-developer
>
|
|
From: Lynch, R. <rus...@in...> - 2002-10-24 02:17:59
|
-----Original Message-----
From: Lynch, Rusty
Sent: Wednesday, October 23, 2002 7:17 PM
To: Zhuang, Louis; Lynch, Rusty
Subject: RE: [Fault-injection-developer] How is the patched insmod
making module_list available
What's there to log? /sbin/insmod fails because of an undefined symbol,
module_list.
Although it looks like it has nothing to do with 2.5.44. I think the
patched insmod
just doesn't catch the fact that module_list is not defined. Kind of a side
effect?
-rusty
-----Original Message-----
From: Zhuang, Louis
Sent: Wednesday, October 23, 2002 7:11 PM
To: Lynch, Rusty
Subject: RE: [Fault-injection-developer] How is the patched insmod
making module_list available
We have not a try for 2.5.44... could you give us your error log?
> -----Original Message-----
> From: Lynch, Rusty [mailto:rus...@in...]
> Sent: Thursday, October 24, 2002 10:02 AM
> To: 'fau...@so...'
> Subject: [Fault-injection-developer] How is the patched
> insmod making module_list available
>
>
> I'm checking out the code and trying to get fakeirq.c to
> compile with the
> 2.5.44 kernel, but have an unresolved symbol for
> "module_list" unless I use
> the patched insmod.
>
> What's up with that? It looks like all that was changed
> in the insmod
> source tree was insmod.c, and I don't see anything having
> to do with
> "module_list".
>
> -rusty
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future
> of Java(TM) technology. Join the Java Community
> Process(SM) (JCP(SM)) program now.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
>
> _______________________________________________
> Fault-injection-developer mailing list
> Fau...@li...
> https://lists.sourceforge.net/lists/listinfo/fault-injecti
on-developer
|
|
From: Lynch, R. <rus...@in...> - 2002-10-24 02:02:32
|
I'm checking out the code and trying to get fakeirq.c to compile with the 2.5.44 kernel, but have an unresolved symbol for "module_list" unless I use the patched insmod. What's up with that? It looks like all that was changed in the insmod source tree was insmod.c, and I don't see anything having to do with "module_list". -rusty |
|
From: Lynch, R. <rus...@in...> - 2002-10-24 01:15:55
|
I think we would have to have a pretty damn good reason for adding more
namespace pollution to the kernel. There has got to be a better way to
do this.
-rusty
-----Original Message-----
From: Zhuang, Louis
Sent: Wednesday, October 23, 2002 6:06 PM
To: 'Rob Rhoads'; Lynch, Rusty
Cc: fau...@li...
Subject: RE: [Fault-injection-developer] We need to get up to speed with
the kprobes proposal on lkml
> -----Original Message-----
> From: Rob Rhoads [mailto:err...@li...]
> Sent: Thursday, October 24, 2002 2:03 AM
> To: Lynch, Rusty
> Cc: fau...@li...
> Subject: Re: [Fault-injection-developer] We need to get
> up to speed with the kprobes proposal on lkml
>
>
> On Wed, 2002-10-23 at 10:49, Lynch, Rusty wrote:
> > The dprobes guys are working with a strategy where all
> of the infrastructure
> > for attaching probe points, kernel hooks, and dealing
> with architecture
> > specific debug registers is covered by a kprobes patch,
> and then dprobes
> > would just be one of many consumers of kprobes.
> >
> > The debates are happening right now, with kprobes
> patches posted for 2.5.44.
> > We need to get a good understanding of these patches
> since I suspect we
> > could at least be a consumer of kprobes (if not of
> dprobes which will depend
> > on kprobes.)
>
> Yeah, that was my thinking as well. Which is why I forwarded that
> previous email from the lkml on kprobes vs. dprobes.
>
Yes, FITH is a customer of kprobes indeed. There is little FITH patch
against kernel. In fact, the patch only exports two symbols of kernel
(irq_desc and mmu_cr4_features). According to Rob's comments, should we only
discuss following patch in kernel mail list, not FITH itself? How can we
find a altisonant reason to have Linus applied this aptch? ;-p
--- ksyms.c.old Tue May 28 10:39:32 2002
+++ ksyms.c Tue May 28 10:41:20 2002
@@ -48,6 +48,7 @@
#include <linux/completion.h>
#include <linux/seq_file.h>
#include <asm/checksum.h>
+#include <linux/irq.h>
#if defined(CONFIG_PROC_FS)
#include <linux/proc_fs.h>
@@ -357,6 +358,8 @@
#if !defined(CONFIG_ARCH_S390)
EXPORT_SYMBOL(irq_stat); /* No separate irq_stat for s390, it is part
of PSA */
#endif
+EXPORT_SYMBOL(irq_desc);
+EXPORT_SYMBOL(mmu_cr4_features);
/* waitqueue handling */
EXPORT_SYMBOL(add_wait_queue);
> >
> > Also, depending on how successful dprobes is at this
> approach, we could
> > model our involvement with the kernel after dprobes.
> >
> > -rusty
> >
>
> --
> Rob Rhoads mailto:err...@li...
> Telecom Software Platforms office: 503-677-5498
> Intel Communications Group
>
> <disclaimer value="pointless">
> This email message solely contains my own personal views,
> and not necessarily those of my employer.
> </disclaimer>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future
> of Java(TM) technology. Join the Java Community
> Process(SM) (JCP(SM)) program now.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
>
> _______________________________________________
> Fault-injection-developer mailing list
> Fau...@li...
> https://lists.sourceforge.net/lists/listinfo/fault-injecti
on-developer
|
|
From: Zhuang, L. <lou...@in...> - 2002-10-24 01:14:15
|
> -----Original Message-----
> From: Rob Rhoads [mailto:err...@li...]
> Sent: Thursday, October 24, 2002 2:03 AM
> To: Lynch, Rusty
> Cc: fau...@li...
> Subject: Re: [Fault-injection-developer] We need to get
> up to speed with the kprobes proposal on lkml
>
>
> On Wed, 2002-10-23 at 10:49, Lynch, Rusty wrote:
> > The dprobes guys are working with a strategy where all
> of the infrastructure
> > for attaching probe points, kernel hooks, and dealing
> with architecture
> > specific debug registers is covered by a kprobes patch,
> and then dprobes
> > would just be one of many consumers of kprobes.
> >
> > The debates are happening right now, with kprobes
> patches posted for 2.5.44.
> > We need to get a good understanding of these patches
> since I suspect we
> > could at least be a consumer of kprobes (if not of
> dprobes which will depend
> > on kprobes.)
>
> Yeah, that was my thinking as well. Which is why I forwarded that
> previous email from the lkml on kprobes vs. dprobes.
>
Yes, FITH is a customer of kprobes indeed. There is little FITH patch
against kernel. In fact, the patch only exports two symbols of kernel
(irq_desc and mmu_cr4_features). According to Rob's comments, should we only
discuss following patch in kernel mail list, not FITH itself? How can we
find a altisonant reason to have Linus applied this aptch? ;-p
--- ksyms.c.old Tue May 28 10:39:32 2002
+++ ksyms.c Tue May 28 10:41:20 2002
@@ -48,6 +48,7 @@
#include <linux/completion.h>
#include <linux/seq_file.h>
#include <asm/checksum.h>
+#include <linux/irq.h>
#if defined(CONFIG_PROC_FS)
#include <linux/proc_fs.h>
@@ -357,6 +358,8 @@
#if !defined(CONFIG_ARCH_S390)
EXPORT_SYMBOL(irq_stat); /* No separate irq_stat for s390, it is part
of PSA */
#endif
+EXPORT_SYMBOL(irq_desc);
+EXPORT_SYMBOL(mmu_cr4_features);
/* waitqueue handling */
EXPORT_SYMBOL(add_wait_queue);
> >
> > Also, depending on how successful dprobes is at this
> approach, we could
> > model our involvement with the kernel after dprobes.
> >
> > -rusty
> >
>
> --
> Rob Rhoads mailto:err...@li...
> Telecom Software Platforms office: 503-677-5498
> Intel Communications Group
>
> <disclaimer value="pointless">
> This email message solely contains my own personal views,
> and not necessarily those of my employer.
> </disclaimer>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future
> of Java(TM) technology. Join the Java Community
> Process(SM) (JCP(SM)) program now.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
>
> _______________________________________________
> Fault-injection-developer mailing list
> Fau...@li...
> https://lists.sourceforge.net/lists/listinfo/fault-injecti
on-developer
|
|
From: Rob R. <err...@li...> - 2002-10-23 18:10:08
|
To save you all the trouble of finding this in the lkml traffic, here is a response from one of the kprobes guys on lkml. It contains a link to the kprobes patch set. -----Forwarded Message----- From: Vamsi Krishna S . <va...@in...> To: Jeff Garzik <jg...@po...> Cc: la...@tr..., Guillaume Boissiere <boi...@ad...>, lin...@vg... Subject: Re: Son of crunch time: the list v1.2. Date: 23 Oct 2002 15:58:53 +0530 On Tue, Oct 22, 2002 at 02:06:29AM +0000, Jeff Garzik wrote: > > > 7) Dynamic Probes (dprobes team) > > http://oss.software.ibm.com/developerworks/opensource/linux/projects/dprobes > > why does this need to be the mainline kernel? this is another type of > thing that can live as a patch, IMO... > We are not proposing the entire dprobes patch to be in kernel. It doesn't have to be. We are proposing for inclusion the "kprobes" patchset at http://www-124.ibm.com/linux/patches/?project_id=141 which provides the basic infrastructure in the kernel for setting up and handling breakpoints automatically in kernel space. Once this small piece is in, we can implement comprehensive tools like dynamic probes as external kernel modules without having to patch the kernel. -- Vamsi Krishna S. Linux Technology Center, IBM Software Lab, Bangalore. Ph: +91 80 5044959 Internet: va...@in... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to maj...@vg... More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |
|
From: Rob R. <err...@li...> - 2002-10-23 18:03:18
|
On Wed, 2002-10-23 at 10:49, Lynch, Rusty wrote: > The dprobes guys are working with a strategy where all of the infrastructure > for attaching probe points, kernel hooks, and dealing with architecture > specific debug registers is covered by a kprobes patch, and then dprobes > would just be one of many consumers of kprobes. > > The debates are happening right now, with kprobes patches posted for 2.5.44. > We need to get a good understanding of these patches since I suspect we > could at least be a consumer of kprobes (if not of dprobes which will depend > on kprobes.) Yeah, that was my thinking as well. Which is why I forwarded that previous email from the lkml on kprobes vs. dprobes. > > Also, depending on how successful dprobes is at this approach, we could > model our involvement with the kernel after dprobes. > > -rusty > -- Rob Rhoads mailto:err...@li... Telecom Software Platforms office: 503-677-5498 Intel Communications Group <disclaimer value="pointless"> This email message solely contains my own personal views, and not necessarily those of my employer. </disclaimer> |
|
From: Lynch, R. <rus...@in...> - 2002-10-23 17:50:04
|
The dprobes guys are working with a strategy where all of the infrastructure for attaching probe points, kernel hooks, and dealing with architecture specific debug registers is covered by a kprobes patch, and then dprobes would just be one of many consumers of kprobes. The debates are happening right now, with kprobes patches posted for 2.5.44. We need to get a good understanding of these patches since I suspect we could at least be a consumer of kprobes (if not of dprobes which will depend on kprobes.) Also, depending on how successful dprobes is at this approach, we could model our involvement with the kernel after dprobes. -rusty |
|
From: Lynch, R. <rus...@in...> - 2002-10-22 19:05:34
|
Yes, dprobes allows probe points to be inserted into a running kernel. There are a couple of exceptions that are artifacts of how dprobes works... I believe one is that you can not insert a probe in the page fault handler (or was it the exception handler). -rusty -----Original Message----- From: Rob Rhoads [mailto:err...@li...] Sent: Tuesday, October 22, 2002 12:00 PM To: Lynch, Rusty Cc: Wang, Stanley; fau...@li...; Perez-Gonzalez, Inaky Subject: RE: [Fault-injection-developer] Couple of issues downloading and building the FITH source code On Tue, 2002-10-22 at 11:22, Lynch, Rusty wrote: > I think we need to be a little more clear on the terms we are using. I > think that when Rob refers to "extending dprobes", he means patching dprobes > to enable some additional features, not taking advantage of various kernel > hooks that the dprobes patch adds to the kernel. > > For example, a very small tweak to dprobes could enable an extra instruction > in the probe rpn files that allows arbitrary exit points to be called from > the rpn file. This could enable something like: > 1. Some user space tool analysis a driver module and then and generates a > rpn file that would insert probe points for each of the in/out operations > where each probe point calls an exit function in a FITH loadable kernel > module > 2. Once the exit function in the FITH module has been called then the rest > of the design for FITH would be the same > > -rusty > Yes, that was similar to what I was thinking. It would be nice though, if the user-space tool could also work on more than just modules though. Does dprobes allow you to insert anywhere in the kernel (i.e. not just kernel modules)? It would be nice to be able to insert probe points for compiled in drivers as well. This could be tricky, but you could use the tool to run through the kernel System.map and vmlinux (uncompressed compiled kernel ELF file) to figure out where to insert probe points in the rpn file for a running kernel. Just a thought... -- Rob Rhoads mailto:err...@li... Telecom Software Platforms office: 503-677-5498 Intel Communications Group <disclaimer value="pointless"> This email message solely contains my own personal views, and not necessarily those of my employer. </disclaimer> |
25 messages has been excluded from this view by a project administrator.
