fault-injection-developer — Developer discussions about creating a fault injection test harness.

[Fault-injection-developer] Who is working on what

[Rusty L. <ru...@li...>]

Anybody can work on any part of the code base they 
want, but as more people join the effort we really need 
some place to document who is working on what and 
probably who owns what sections.

So far I know:
* GOTO Yasunori (welcome aboard!) would like to 
   work on either a a PCI configuration interceptor or a 
   code segment caller
* Louis have been volunteering to publish snapshots

... there is a lot more going on.  How about people 
respond to this email and I will compile a list to either 
post on the website or periodically send to this list 
(since it will be a very dynamic list)

Note: I once had a discussion with Alan Robertson
about how he running the Linux-HA project, and he
had practical view of what his role in the project was.
Basically he was responsible for doing all the work
that needed to be done, but wasn't all that fun (and
therefore nobody volunteered to do the work)

        -rustyl 

[Fault-injection-developer] fith-mini-13 is out

[Zhuang, L. <lou...@in...>]

Fix 'dark X' bug... Any comments?

RE: [Fault-injection-developer] [ANNOUNCE] Fault-Injection Test H arnessProject

[Lynch, R. <rus...@in...>]

We currently have some infrastructure and a MMIO interceptor implemented so
an interceptor for PCI configuration data is fare game.

Join the mailing list at
http://lists.sourceforge.net/lists/listinfo/fault-injection-developer
and start hacking. :->

  -rusty 

> -----Original Message-----
> From: y-...@jp... [mailto:y-...@jp...]
> Sent: Thursday, December 12, 2002 11:26 PM
> To: ru...@li...
> Cc: lin...@vg...; 
> fau...@so...; 
> lcl...@co...; ac...@co...; 
> ol...@co...; ri...@co...
> Subject: Re: [Fault-injection-developer] [ANNOUNCE] 
> Fault-Injection Test HarnessProject
> 
> 
> Hello Rusty and all.
> 
> I was a developer of LKST, and I know about GKHI's implementation.
> 
> rusty> Fault-Injection Test Harness Project
> rusty> -------------------------------------
> 
> Now, I am interested in your project, and I read white paper for 
> investigation.
> I think that following development items haven't been completed yet.
> Is it correct?
> - Interceptor of PCI configuration. 
> - Caller of Code Segment.
> If these aren't completed yet, I want to develop it.
> 
> Best Regards.
> 
> ---------------五島康文 (GOTO Yasunori)-------------------
> 富士通(株)BCCプロジェクト推進部
> e-mail: y-...@jp...
> tel 0559-24-6178(7551-5725) fax 0559-24-6195(7551-6547)
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility 
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Fault-injection-developer mailing list
> Fau...@li...
> https://lists.sourceforge.net/lists/listinfo/fault-injection-developer
> 

Re: [Fault-injection-developer] [ANNOUNCE] Fault-Injection Test HarnessProject

[<y-...@jp...>]

Hello Rusty and all.

I was a developer of LKST, and I know about GKHI's implementation.

rusty> Fault-Injection Test Harness Project
rusty> -------------------------------------

Now, I am interested in your project, and I read white paper for 
investigation.
I think that following development items haven't been completed yet.
Is it correct?
- Interceptor of PCI configuration. 
- Caller of Code Segment.
If these aren't completed yet, I want to develop it.

Best Regards.

---------------五島康文 (GOTO Yasunori)-------------------
富士通(株)BCCプロジェクト推進部
e-mail: y-...@jp...
tel 0559-24-6178(7551-5725) fax 0559-24-6195(7551-6547)

[Fault-injection-developer] [ANNOUNCE] Fault-Injection Test Harness Project

[Rusty L. <ru...@li...>]

Fault-Injection Test Harness Project
-------------------------------------

I am pleased to announce the formation of a new project for developing a
test harness for inserting faults into a running kernel.  The project is
based at http://fault-injection.sf.net, with a bitkeeper tree hosted at
http://fault-injection.bkbits.net:8080/linux-2.5/, and an IRC channel named
#fi on 206.103.61.170. (The DNS entry for the IRC address is about to
change, but the number should stay the same.)

The project started out to try to validate that a kernel driver was
acceptable for a carrier environment (the "mystical" hardened driver) :).
Now, it has morphed to building a general tool for inserting faults into
any part of the kernel to see if the kernel reacts in a way the test
developer expects.  We have kind of straw man design with some
_very_ early prototype work, but for the most part things are just 
now getting started. I know there are some people on this list that 
have some considerable experience in fault injection on other Unix's, 
and some of you have hinted to me in emails that you might be 
interested in creating some kind of fault injection tool for Linux.  
I just hope I can entice you into joining our efforts (even if you 
only want to give us some directional guidance.)

As mentioned we are developing off of a clone of the 2.5 tree that we
periodically sync.  A CVS tree and snapshots are available from the
sourceforge site for those that do not use bitkeeper, but they will always
lag behind.

        -rustyl

[Fault-injection-developer] Website Updated

[Rusty L. <ru...@li...>]

I updated the site for our current work, with a pointer to the bk tree and all.  Send any comments to me and I will update the site.

    -rusty

[Fault-injection-developer] IRC server

[Rusty L. <ru...@li...>]

I have started sitting on channel #fi at the developer.osdl.org IRC
server.  I'm not sure how long that server will be available, but since 
I was able to get my IT guys to create a proxy for it then it is easy to 
get to from home or work.

    -rusty

[Fault-injection-developer] fith-mini-12 is released!

[Zhuang, L. <lou...@in...>]

Download in http://prdownloads.sourceforge.net/fault-injection/fith-mini-12.
tar.gz?download
Any comments?

[Fault-injection-developer] Clean&Clear minimal fith package is released (fith-mini-11)

[Zhuang, L. <lou...@in...>]

Any comments?

[Fault-injection-developer] Module Refcount and Stuff mini-FAQ

[Wang, S. <sta...@in...>]

FYI.


Patch: Module Refcount and Stuff mini-FAQ 

From:   Rusty Russell <ru...@ru...> 
To:   lin...@vg... 
Subject:   Module Refcount & Stuff mini-FAQ 
Date:   Tue, 19 Nov 2002 09:58:56 +1100 
Cc:   Doug Ledford <dle...@re...>, Alexander Viro <vi...@ma...>



[ Suggestions welcome ]

Golden Rule: If you are calling though a function pointer into a
(different) module, you must hold a reference to that module.
Otherwise you risk sleeping in the module while it is unloaded.

Q: How do I get a reference to a module?
A: Usually, a successful call to try_module_get(owner).  You don't
   need to check for owner != NULL, BTW.

Q: When does try_module_get(owner) fail?
A: When the module is not ready to be entered (ie. still in
   init_module) or it is being removed.  It fails to prevent you
   entering the module as it is being discarded (init might fail, or
   it's being removed).

Q: But modules call my register() routine which wants to call back
   into one of the function pointers immediately, and so
   try_module_get() fails!
A: You're being called from the module, so someone already has a
   reference (unless there's a bug), so you don't need a
   try_module_get().

   This does mean that if you were to register a structure for
   *another* module (does anyone do this?) you'd need to have a
   reference to it.

Q: How do I put the reference back?
A: Using module_put(owner) (owner == NULL is OK).

Q: Do I really need to put try_module_get() before every function ptr
   call?
A: If the function does not sleep (any cannot be preempted) ie. is
   called in softirq or hardirq context, you can omit this step, since
   you obviously won't sleep inside the module.

   Also, most structs have clear "start" and "stop" functions
   (eg. mount/umount), so you only need one try_module_get()
   on start, and module_put() on stop.

Q: Is it safe to call try_module_get() and module_put() from an
   interrtupt / softirq?
A: Yes.

Q: My code use "MOD_INC_USE_COUNT".  Do I still need to adjust my
   module count when someone calls one of my functions?
A: No, you never need to adjust your own module count.  There are five
   ways a function in your module can get called: firstly, it could be
   your module_init() function, in which case the module code holds a
   reference.  It could be another module using one of your
   EXPORT_SYMBOL'ed functions, in which case you cannot be removed
   since they would have to be removed first.  It could be a module
   which found an EXPORT_SYMBOL'ed function using symbol_get(), in
   which case they hold a reference count.  It could be through a
   function pointer which your module gave out previously, which is
   discussed above.  Finally, it could be from within your own module,
   in which case someone must already hold a reference.

Q: My code uses "__MOD_INC_USE_COUNT(reg->owner)", but now I get a
   warning at runtime that it is unsafe.  What do I need to do?
A: You need to use try_module_get(), and not call into the module if
   it fails (act as if it hasn't registered yet).  Note that you no
   longer need to check for NULL yourself, try_module_get() does that.

Q: My code used "GET_USE_COUNT(module)" to get the reference count.
A: Don't do that.  If module unloading is disabled, there is no
   reference count, and there is never a single value you can assign
   to.

Q: My code used "try_inc_mod_count(module)" to get the reference
   count.  Should I change it?
A: No hurry.  try_module_get() is exactly the same: the new name
   reflects that this is now the only way to get a reference.

Q: How does the code in try_module_get() work?
A: It disables preemption for a moment, checks the live flag, and then
   increments a per-cpu counter if the module is live.  This is even
   lighter-weight (in icache and cycles) than using a brlock, but has
   the same effect.  If CONFIG_MODULE_UNLOAD=n, it just becomes a
   check that the module is live.

Q: How does the module remove code work?
A: It stops the machine by scheduling threads for every other CPU,
   then they all disable interrupts.  At this stage we know that noone
   is in try_module_get(), so we can reliably read the counter.  If
   zero, or the rmmod user specified --wait, we set the live flag to
   false.  After this, the reference count should not increase, and
   each module_put() will wake us up, so we can check the counter
   again.

Q: Are these changes all so you could implement an in-kernel module
   linker?
A: No, they were to prevent load and unload races without altering
   every module, nor introducing drastic new requirements.

Q: Doesn't putting linking code into the kernel just add bloat?
A: The total linking code is about 200 generic lines, 100
   x86-specific lines.  The ia64 linking code is about 500 lines (it's
   the most complex).  Richard Henderson has a great suggestion for
   simplifying it furthur, which I'm implementing now.  "insmod" is
   now a single portable system call, meaning insmod can be written in
   about 20 lines of code.

   The previous code required to implement the two module loading
   system call, the module querying system call, and the /proc/ksyms
   output, required a little more code than the current x86 linker.

Q: Why not just fix the old code?
A: Because having something so intimate with the kernel in userspace
   greatly restricts what changes the kernel can make.  Moving into
   the kernel means I have implemented modversions, typesafe
   extensible module parameters and kallsyms without altering
   userspace in any way.  Future extensions won't have to worry about
   the modversions problem.

Q: Why not implement two-stage insert / two-stage delete?
A: Because I implemented it first and it sucked.  And because this
   *is* two-stage insert and two-stage delete, without exposing it to
   the modules using it, with the added advantage that the second
   stage is atomic (activation/deactivation is simply changing
   mod->live, modulo locking implementation magic detailed above).
   This prevents the race between deactivating the module and finding
   that someone has starting using it as you are deactivating it.

Hope that helps?
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-
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/


 


Your Sincerely,
Stanley Wang 

SW Engineer, Intel Corporation.
Intel China Software Lab. 
Tel: 021-52574545 ext. 1171 
iNet: 8-752-1171 
 
Opinions expressed are those of the author and do not represent Intel
Corporation

[Fault-injection-developer] RE: [BUG] [2.5.49] symbol_get doesn't work

[Wang, S. <sta...@in...>]

Hi, Rusty
I get it now :)

Thanks,
Stanley

> -----Original Message-----
> From: Rusty Russell [mailto:ru...@ru...]
> Sent: 2002=E5=B9=B411=E6=9C=8829=E6=97=A5 8:02
> To: Wang, Stanley
> Cc: 'lin...@vg...'; dw...@tw...
> Subject: Re: [BUG] [2.5.49] symbol_get doesn't work=20
>=20
>=20
> In message=20
> <957...@pd...> you
>  write:
> > Hi, Rusty
> > Thanks for your respondence.
> > You means that the purpose of using symbols_get() is just adding =
=3D
> > module's
> > reference count, right?
> > If so, I think we don't need a pointer to be returned by=20
> symbol_get(). =3D
> > We
> > could use the symbols desired
> > directly after we called symbol_get().=3D20
> > How do you think about it ?
>=20
> Hi Wang,
>=20
> 	No, you do *not* normally need to use symbol_get(): you just
> use the symbol like normal and the loader will make sure reference
> counts are adjusted etc.
>=20
> 	Here's an example of use, from my (completely untested) "make
> mtd use symbol_get()" patch, which allows mtd to look for support for
> a given command set at runtime (rather than forcing all command set
> modules to be present to load at all):
>=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> typedef struct mtd_info *cfi_cmdset_fn_t(struct map_info *, int);
> =20
> static struct mtd_info *unknown_cmdset(struct map_info *map,=20
> int primary)
> {
> 	struct cfi_private *cfi =3D map->fldrv_priv;
> 	__u16 type =3D primary?cfi->cfiq->P_ID:cfi->cfiq->A_ID;
>=20
> 	printk(KERN_NOTICE "Support for command set %04X not present\n",
> 	       type);
> 	return NULL;
> }
>=20
> /* when we are built without module support, so we still link */
> cfi_cmdset_fn_t cfi_cmdset_0001 __attribute__((weak,=20
> alias("unknown_cmdset")));
> cfi_cmdset_fn_t cfi_cmdset_0002 __attribute__((weak,=20
> alias("unknown_cmdset")));
> cfi_cmdset_fn_t cfi_cmdset_0003 __attribute__((weak,=20
> alias("unknown_cmdset")));
>=20
> static inline struct mtd_info *cfi_cmdset_unknown(struct=20
> map_info *map,=20
> 						  int primary)
> {
> 	struct cfi_private *cfi =3D map->fldrv_priv;
> 	__u16 type =3D primary?cfi->cfiq->P_ID:cfi->cfiq->A_ID;
> 	cfi_cmdset_fn_t *probe_function =3D NULL;
>=20
> 	switch (type) {
> 	case 1:
> 		probe_function =3D symbol_get(cfi_cmdset_0001);
> 		break;
> 	case 2:
> 		probe_function =3D symbol_get(cfi_cmdset_0002);
> 		break;
> 	case 3:
> 		probe_function =3D symbol_get(cfi_cmdset_0003);
> 		break;
> 	}
> 	if (probe_function) {
>  		struct mtd_info *mtd;
> =20
>  		mtd =3D (*probe_function)(map, primary);
>  		return mtd;
>  	}
> 	return unknown_cmdset(map, primary);
>  }
> =20
> --
>   Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
>=20

[Fault-injection-developer] Re:[PATCH] 47-kp2-fi2-dm3 features

[Zhuang, L. <lou...@in...>]

Rusty, Thank you for your great comments! We are revising code under your
suggestion. :-)  - Louis

[Fault-injection-developer] Re:[PATCH] 47-kp2-fi2-dm3 features

[Rusty L. <ru...@li...>]

> diff -Nur -X /home/louis/dontdiff 47-kp-fi/arch/i386/Kconfig 47-kp-fi-dm/arch/i386/Kconfig
> --- 47-kp-fi/arch/i386/Kconfig	Mon Nov 25 15:15:40 2002
> +++ 47-kp-fi-dm/arch/i386/Kconfig	Tue Nov 26 13:44:03 2002
> @@ -1577,6 +1577,13 @@
>  	  Say Y here if you want to enable Fault Injection (FI) mechanism. 
>  	  The FI can monitor MMIO/IO access in kernel.
>  
> +config FI_DM
> +	tristate "Fault Injection Decision Maker"
> +	depends on FI
> +	help
> +	  Only support M here. It is a bug to be fixed. Decision Maker is to
> +	  control interceptors how/what to inject.
> +

If you want the choices to be module or nothing, then just code it that way.

Also please add a more descriptive comment for this component.  Keep 
in mind that the world will be stumbling across this option while
trying to configure a kernel, and would like to know something more then
the name of the module.

> 
>  config DEBUG_STACKOVERFLOW
>  	bool "Check for stack overflows"
>  	depends on DEBUG_KERNEL
> diff -Nur -X /home/louis/dontdiff 47-kp-fi/include/linux/fi/fi.h 47-kp-fi-dm/include/linux/fi/fi.h
> --- 47-kp-fi/include/linux/fi/fi.h	Thu Jan  1 08:00:00 1970
> +++ 47-kp-fi-dm/include/linux/fi/fi.h	Tue Nov 26 13:44:53 2002
> @@ -0,0 +1,189 @@
> +/******************************************************************************
> + *  Fault Injection Test harness (FI)
> + *  Copyright (C) Intel Crop.
> + *
> + *  This program is free software; you can redistribute it and/or
> + *  modify it under the terms of the GNU General Public License
> + *  as published by the Free Software Foundation; either version 2
> + *  of the License, or (at your option) any later version.
> + *
> + *  This program is distributed in the hope that it will be useful,
> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *  GNU General Public License for more details.
> + *
> + *  You should have received a copy of the GNU General Public License
> + *  along with this program; if not, write to the Free Software
> + *  Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
> + *
> + ******************************************************************************
> + */
> +
> +/*  $Id: fi.h,v 1.3 2002/11/15 03:05:04 brlock Exp $
> + *  Copyright by Intel Crop., 2002
> + *  Louis Zhuang (lou...@in...)
> + *
> + */
> +
> +/** @file fi.h
> + *  Fault Injection Test Harness Head File
> + *  This file defines common data struct/type used by fi modules and command line tools.
> + */
> +#ifndef __FI_H
> +#define __FI_H
> +#define FI_VERSION "$Id: fi.h,v 1.3 2002/11/15 03:05:04 brlock Exp $"
> +
> +#include <asm/types.h>
> +#include <asm/atomic.h>
> +
> +/**
> + * define uniform watchpoint structure.
> + */
> +#define FI_WPTYPE_MMIO 4
> +#define FI_WPTYPE_READ 8
> +#define FI_WPTYPE_WRITE 16
> +#define FI_WPTYPE_EXEC 32
> +
> +#define FI_WPTYPE_LEN_MASK 3
> +#define FI_WPTYPE_ALL_MASK 	( FI_WPTYPE_MMIO \
> +				| FI_WPTYPE_READ \
> +				| FI_WPTYPE_WRITE \
> +				| FI_WPTYPE_EXEC \
> +				| FI_WPTYPE_LEN_MASK \
> +				)
> +
> +struct watchpoint{
> +	/*address intercepted.*/
> +	unsigned long addr;
> +	/**
> +	 * intercepted type. 
> +	 * 	bit 0-1	2^N bytes leng.
> +	 * 	bit 2	IO-space IO/MMIO
> +	 * 	bit 3	Read
> +	 * 	bit 4	Write
> +	 * 	bit 5	Execute(not implementation yet) 
> +	 * XXX: you can not register the same address with IO and MMIO, 
> +	 * but MMIO seldom uses low 64k space, so it is not a problem in fact.*/
> +	unsigned int type;
> +};

Use 8-char indents (see Documentation/CodingStyle)

ditto on the rest of the file.

> +
> +#define WP_LEN(wp) (1<<((unsigned long)(wp.type)&3))
> +
> +#if 0
> +/**
> + * Define utitlty watchpoint inline function.
> + */
> +inline struct watchpoint WP(void *addr, int type) { 
> +	struct watchpoint wp;
> +	wp.addr = addr;
> +	wp.type =type;
> +	return wp;
> +};
> +#endif
> +

Get rid of personal hacks.

> +
> +/** max number of triggers */
> +#define MAX_OP_PER_TRIGGER 4
> +#define MAX_TRIGGER_PER_FAULTSET  16
> +#define MAX_FAULTSET 16
> +struct fi_trigger{
> +    /**
> +     * This part contains properties of the trigger. It is seldom changed after initialization.
> +     */
> +    /**watchpoint which can trigger*/
> +    struct watchpoint wp;
> +
> +    /**bitmask for which you really care. 0-unmasked; 1-masked*/
> +    __u32 bitmask;
> +
> +    /**baseline you want to trigger after masked*/
> +    int min;
> +
> +    /**topline you want to trigger after masked
> +     * XXX: it is CLOSED region. min<=val<=max*/
> +    int max;
> +	
> +    /**trigger can start to work after skip times*/
> +    int skip;
> +    
> +    /**trigger can stop after work stop times*/
> +    int stop;
> +    
> +    /**bitmask for protection*/
> +    int protection;
> +
> +    /**HZ for random error*/
> +    int hertz;
> +	
> +    /***/
> +    struct {
> +	/**0 - nothing; 1 - SET; 2 - AND; 3 - OR; 4 - NOT; 5 - XOR*/
> +	enum{ FI_NOTHING=0, FI_SET=1, FI_AND=2, FI_OR=3, FI_NOT=4, FI_XOR=5, FI_NAND =6, FI_NOR=7, FI_ADD=8, FI_SUB=9,
> +	}opcode;
> +	int operand;
> +    }ops[MAX_OP_PER_TRIGGER];
> +
> +	
> +    /**
> +     * This part is statistic of the trigger. It should reflect the status of the trigger.
> +     */
> +    /*Whether the trigger is registerd*/
> +    int registered;
> +    /**times that is triggered*/
> +    atomic_t count;
> +};
> +
> +
> +struct fi_faultset{
> +    /***/
> +    struct fi_trigger trigger_tb[MAX_TRIGGER_PER_FAULTSET];
> +    
> +    /**status: 0 - noused; 1 - enable; 2 - disable*/
> +    enum {
> +	NOUSED=0, ENABLED=1, DISABLED=2
> +    }stat;
> +
> +    char modname[256];
> +
> +    /**more...*/
> +};
> +
> +struct fi_irq_faultset{
> + int irq_spurious_hertz;//0 means never do this
> + int irq_delay_hertz;
> + int irq_delay_time;//0 means lost
> + int num;
> + char devname[80];
> + char modname[256];
> + void *id;
> +};
> +
> +struct fi_ins_record {
> +	unsigned char *addr;	/* Instruction's virtual address */
> +	unsigned char opcode;	/* The original opcode */
> +};
> +
> +struct fi_ins_record_header {
> +	char modname[256];
> +	int counter;
> +	struct fi_ins_record inst[0];
> +};
> +
> +/*Define IOCTL number*/
> +#define FI_IOCTL_BASE			'F'
> +#define FIIOC_INSERT			_IOW(FI_IOCTL_BASE, 0, struct fi_faultset)
> +#define FIIOC_REMOVE			_IOW(FI_IOCTL_BASE, 1, int)
> +#define FIIOC_ENABLE			_IOW(FI_IOCTL_BASE, 2, int)
> +#define FIIOC_DISABLE			_IOW(FI_IOCTL_BASE, 3, int)
> +#define FIIOC_SET_IRQ_FAULTSET 	_IOW(FI_IOCTL_BASE, 4, struct fi_irq_faultset)
> +#define FIIOC_CLEAR_IRQ_FAULTSET 	_IO(FI_IOCTL_BASE, 5)
> +#define FIIOC_QUERY_PHYADDR		_IOWR(FI_IOCTL_BASE, 6, unsigned long)
> +#define FIIOC_TRANS_INST		_IOW(FI_IOCTL_BASE, 7, struct fi_ins_record_header)
> +#define FIIOC_QUERY_INTCPT		_IO(FI_IOCTL_BASE, 8)
> +
> +#if 0
> +/** this is switch for fi*/
> +extern int g_fiIsEnabled;
> +#endif
> +
> +#endif/*__FI_H*/
> diff -Nur -X /home/louis/dontdiff 47-kp-fi/include/linux/fi/fi_interface.h 47-kp-fi-dm/include/linux/fi/fi_interface.h
> --- 47-kp-fi/include/linux/fi/fi_interface.h	Thu Jan  1 08:00:00 1970
> +++ 47-kp-fi-dm/include/linux/fi/fi_interface.h	Tue Nov 26 13:44:53 2002
> @@ -0,0 +1,160 @@
> +/******************************************************************************
> + *  Fault Injection Test harness (FI)
> + *  Copyright (C) Intel Crop.
> + *
> + *  This program is free software; you can redistribute it and/or
> + *  modify it under the terms of the GNU General Public License
> + *  as published by the Free Software Foundation; either version 2
> + *  of the License, or (at your option) any later version.
> + *
> + *  This program is distributed in the hope that it will be useful,
> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *  GNU General Public License for more details.
> + *
> + *  You should have received a copy of the GNU General Public License
> + *  along with this program; if not, write to the Free Software
> + *  Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
> + *
> + ******************************************************************************
> + */
> +
> +/*  $Id: fi_interface.h,v 1.1.1.1 2002/11/12 05:56:30 brlock Exp $
> + *  Copyright by Intel Crop., 2002
> + *  Louis Zhuang (lou...@in...)
> + *
> + */
> +
> +/** 
> + *  @file interfaces.h
> + *  This file defines interfaces among components.
> + */
> +#ifndef __FI_INTERFACE_H
> +#define __FI_INTERFACE_H
> +
> +#include <linux/fi/fi.h>
> +
> +
> +/**
> + * A interface exports to another component for callback.
> + */
> +struct iInterceptHook{
> +	/**
> +	 * trigger a process of IO access interceptor
> +	 * @param wp	the watchpoint which triggers the callback.
> +	 * @param len	the length of resource access
> +	 * @param type	0 read, 1 write
> +	 * @param data	XXX:context of the trigger. 
> +	 * 		impl of trigger must send it back in corrput interface.
> +	 */
> +	void	(*trigger)	(int id, __u32 val, int len, int type, void *data);
> +};
> +

Ahh! dOntDoThat! Follow the Documentation/CodingStyle for nameing 
of things.  As soon as lkml sees a name like iInterceptHook
the result will be

windows code ==> /dev/null


> +
> +/** 
> + * A interface between Interceptor and DM components in order to 
> + * intercept resource accesses.
> + */
> +struct iIntercept{
> +	/**
> +	 * Register a watchpoint which will be triggered when access based on this address.
> +	 * @param wp	the intercepted watchpoint
> +	 * @param id	calling should assign a id to this wp.
> +	 * @param hook	ptr can be used to call back process function.
> +	 * @param return 	0 successful; 
> +	 * 			-EFI_INVALID if wp is invaild; 
> +	 * 			-EFI_REGISTERED if wp has been registered
> +	 * 			-EFI_TABFULL if wp table is full
> +	 */
> +	int	(*wp_register)	(struct watchpoint wp, 
> +				int id,
> +				struct iInterceptHook *hook,
> +				char *modname);
> +
> +	/** 
> +	 * Unregister a watchpoint
> +	 * @param return	0 successful
> +	 * 			-EFI_NOTFOUND there is not the id.
> +	 */
> +	int	(*wp_unregister)(int id, char *modname);
> +
> +	/**
> +	 * corrput access in requirement
> +	 */
> +	int	(*corrupt)	(int id, __u32 dirty, void *data);
> +};
> +
> +
> +/**
> + * trigger a process of IRQ interceptor
> + */
> +struct iIRQHook{
> +	/**
> +	 * callback for IRQ interceptor
> +	 */
> +	void (*event)	(int num, void *id, void *regs);
> +};
> +
> +
> +/**
> + * A interface to intercept IRQ
> + * 
> + * any snatched IRQ event will be called into hook interface. And hook 
> + * interface should in turn call dispatch event to invoke real driver's
> + * IRQ handler.
> + *
> + * And DM can also hook on other IRQ source and dispatch event into driver's
> + * handler in order to implement suprious IRQ event.
> + */
> +struct iIRQ{
> +	/**
> +	 * Snatch a IRQ handler from IRQ chain.
> +	 * @param hook	hook interface for this IRQ handler
> +	 * @param num	IRQ number
> +	 * @param id	id for shared IRQ device
> +	 */
> +	int (*irq_snatch)	(struct iIRQHook *hook, int num, char *devname, void** dev_id, char *modname);
> +	int (*irq_unload)	(int num, char *devname);
> +	/**
> +	 * dispatch a fake IRQ event into handler
> +	 */
> +	int (*dispatch)		(int num, void *id, void *regs);
> +};
> +
> +/** 
> + * A interface between fi_dbp and DM components in order to 
> + * transfer information.
> + */
> +struct iGetinfo{
> +	/**
> +	 * Transfer all information of the replaced IO instructions to fi_dbp.
> +	 * @param header	data structure header of all the IO instructions.
> +	 * @param return 	0 successful; 
> +	 * 			-ENOMEM if kmalloc failed
> +	 * 			-EFI_TABFULL if wp table is full
> +	 */
> +	int	(*getinfo)	(struct fi_ins_record_header *header);
> +};
> +
> +/** 
> + * A interface for translating address between linear address and physical address. 
> + */
> +struct iAslt{
> +	/**
> +	 * Translate address bwteen linear address and physical address.
> +	 * @param header	data structure header of all the IO instructions.
> +	 * @param return 	0 failed; 
> +	 * 			phy_addr if found.
> +	 */
> +	unsigned long 	(*fi_line_to_phy)	(unsigned long line_addr);
> +
> +	/**
> +	 * Check if the wp is pending.
> +	 * @param wp		the intercepted watchpoin.
> +	 * @param return 	0 enable;
> +	 * 			1 pending.
> +	 */
> +	int		(*check_wp)		(struct watchpoint wp);
> +};
> +
> +#endif/*__FI_INTERFACE_H*/
> diff -Nur -X /home/louis/dontdiff 47-kp-fi/include/linux/fi/fi_internal.h 47-kp-fi-dm/include/linux/fi/fi_internal.h
> --- 47-kp-fi/include/linux/fi/fi_internal.h	Thu Jan  1 08:00:00 1970
> +++ 47-kp-fi-dm/include/linux/fi/fi_internal.h	Tue Nov 26 13:44:53 2002
> @@ -0,0 +1,126 @@
> +/******************************************************************************
> + *  Fault Injection Test harness (FI)
> + *  Copyright (C) Intel Crop.
> + *
> + *  This program is free software; you can redistribute it and/or
> + *  modify it under the terms of the GNU General Public License
> + *  as published by the Free Software Foundation; either version 2
> + *  of the License, or (at your option) any later version.
> + *
> + *  This program is distributed in the hope that it will be useful,
> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *  GNU General Public License for more details.
> + *
> + *  You should have received a copy of the GNU General Public License
> + *  along with this program; if not, write to the Free Software
> + *  Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
> + *
> + ******************************************************************************
> + */
> +
> +/*  $Id: fi_internal.h,v 1.1.1.1 2002/11/12 05:56:30 brlock Exp $
> + *  Copyright by Intel Crop., 2002
> + *  Louis Zhuang (lou...@in...)
> + *
> + */
> +
> +/** @file fi_internal.h
> + *  This is a FI internal header file to define some internal utilities.
> + */
> +#ifndef __FI_INTERNAL_H
> +#define __FI_INTERNAL_H
> +
> +#ifndef PREFIX_NAME
> +#define PREFIX_NAME "FI_DEFAULT"
> +#endif
> +extern long globalcounter;
> +
> +/*define help macro to debug */
> +/*XXX there should use eventlog in future */
> +#ifdef FI_DEBUG
> +#  ifdef __KERNEL__
> +#    define PDEBUG(fmt, args...) printk(KERN_DEBUG PREFIX_NAME ": %ld :cpu[%d] " __func__ ": " fmt, globalcounter++, smp_processor_id(), ##args)
> +#  else
> +#    define PDEBUG(fmt, args...) fprintf(stderr, fmt, ##args)
> +#  endif
> +#else
> +#  define PDEBUG(fmt, args...)
> +#endif
> +
> +#ifdef __KERNEL__
> +#  define PINFO(fmt, args...) printk(KERN_INFO PREFIX_NAME ": %ld :%s:" fmt, globalcounter++, __func__, ##args)
> +#else
> +#  define PINFO(fmt, args...) fprintf(stderr, fmt, ##args)
> +#endif
> +
> +#ifdef __KERNEL__
> +#  define PERROR(fmt, args...) printk(KERN_ERR PREFIX_NAME ": %ld :%s:" fmt, globalcounter++, __func__, ##args)
> +#else
> +#  define PERROR(fmt, args...) fprintf(stderr, fmt, ##args)
> +#endif
> +
> +/*define some macros*/
> +#define FI_MAJOR 0
> +
> +#define FI_ID(fs_num, tri_num) (fs_num<<16|tri_num)
> +#define FI_FS_NUM(id) (id>>16)
> +#define FI_TRI_NUM(id) (id&0xffff)
> +
> +/*define macros for error code.*/
> +#define EFI_SUCCESS		0
> +#define EFI_INVALID		1
> +#define	EFI_REGISTERED	2
> +#define EFI_TABFULL		3
> +#define	EFI_NOTFOUND		4
> +
> +/*define macros for WP type*/
> +inline static int is_MMIO(int type)	{ return (type&0x04)?1:0; };
> +inline static int is_IO(int type)	{ return (type&0x04)?0:1; };
> +inline static int is_read(int type)	{ return (type&0x08)?1:0; };
> +inline static int is_write(int type)	{ return (type&0x10)?1:0; };
> +inline static int is_execute(int type)	{ return (type&0x20)?1:0; };
> +inline static int access_len(int type)	{ return 1UL<<(type&0x03);};
> +
> +/*Some functions for find and lock specific kernel module*/
> +extern struct module *module_list;
> +static inline struct module *find_module(const char *name)
> +{
> +	struct module *mod;
> +
> +	for (mod = module_list; mod ; mod = mod->next) {
> +		if (mod->flags & MOD_DELETED)
> +			continue;
> +		if (!strcmp(mod->name, name))
> +			break;
> +	}
> +
> +	return mod;
> +}
> +
> +static inline int fi_lock_module(char *modname)
> +{
> +	struct module *mod;
> +
> +	mod = find_module(modname);
> +	if (mod == NULL)
> +		return -EEXIST;
> +	__MOD_INC_USE_COUNT(mod);
> +	PDEBUG("Lock module:%s! @%s\n", modname, __FILE__);
> +	return EFI_SUCCESS;
> +}
> +
> +static inline int fi_unlock_module(char *modname)
> +{
> +	struct module *mod;
> +
> +	mod = find_module(modname);
> +	if (mod == NULL)
> +		return -EEXIST;
> +	PDEBUG("Unlock module:%s! @%s\n", modname, __FILE__);
> +	__MOD_DEC_USE_COUNT(mod);
> +	return EFI_SUCCESS;
> +}
> +
> +
> +#endif/*__FI_INTERNAL_H*/
> diff -Nur -X /home/louis/dontdiff 47-kp-fi/kernel/Makefile 47-kp-fi-dm/kernel/Makefile
> --- 47-kp-fi/kernel/Makefile	Mon Nov 25 15:16:27 2002
> +++ 47-kp-fi-dm/kernel/Makefile	Mon Nov 25 15:40:23 2002
> @@ -22,6 +22,7 @@
>  obj-$(CONFIG_BSD_PROCESS_ACCT) += acct.o
>  obj-$(CONFIG_SOFTWARE_SUSPEND) += suspend.o
>  obj-$(CONFIG_KPROBES) += kprobes.o
> +obj-$(CONFIG_FI_DM) += fi_dm.o
>  
>  ifneq ($(CONFIG_IA64),y)
>  # According to Alan Modra <al...@li...>, the -fno-omit-frame-pointer is
> diff -Nur -X /home/louis/dontdiff 47-kp-fi/kernel/fi_dm.c 47-kp-fi-dm/kernel/fi_dm.c
> --- 47-kp-fi/kernel/fi_dm.c	Thu Jan  1 08:00:00 1970
> +++ 47-kp-fi-dm/kernel/fi_dm.c	Tue Nov 26 13:44:54 2002
> @@ -0,0 +1,594 @@
> +/******************************************************************************
> + *  Fault Injection Test harness (FI)
> + *  Copyright (C) Intel Crop.
> + *
> + *  This program is free software; you can redistribute it and/or
> + *  modify it under the terms of the GNU General Public License
> + *  as published by the Free Software Foundation; either version 2
> + *  of the License, or (at your option) any later version.
> + *
> + *  This program is distributed in the hope that it will be useful,
> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *  GNU General Public License for more details.
> + *
> + *  You should have received a copy of the GNU General Public License
> + *  along with this program; if not, write to the Free Software
> + *  Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
> + *
> + ******************************************************************************
> + */
> +
> +/*  $Id: dm_core.c,v 1.3 2002/11/14 07:11:37 brlock Exp $
> + *  Copyright by Intel Crop., 2002
> + *  Louis Zhuang (lou...@in...)
> + */
> +/**
> + * @file dm_core.c
> + */
> +
> +#include <linux/config.h>
> +#include <linux/version.h>
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/version.h>
> +#include <asm/system.h>
> +#include <asm/uaccess.h>
> +#include <asm/io.h>
> +#include <asm/atomic.h>
> +#include <asm/debugreg.h>
> +#include <asm/desc.h>
> +#include <linux/ioport.h>
> +#include <asm/page.h>
> +#include <asm/pgtable.h>
> +#include <asm/pgalloc.h>
> +#include <linux/sched.h>
> +#include <asm/system.h>
> +#include <linux/vmalloc.h>
> +#include <linux/proc_fs.h>
> +#include <linux/random.h>
> +#include <linux/highmem.h>
> +#include <linux/kprobes.h>
> +
> +#define PREFIX_NAME "FI"
> +#include <linux/fi/fi.h>
> +#include <linux/fi/fi_internal.h>
> +#include <linux/fi/fi_interface.h>
> +
> +#define MAX_MOD 16
> +
> +#define MODULE_NAME "fi_dm"
> +#define MODULE_VERSION "0.1"
> +
> +static int insert_faultset(struct fi_faultset *fs);
> +static int remove_faultset(int index);
> +static int enable_faultset(int index);
> +static int disable_faultset(int index);
> +
> +
> +long globalcounter=0;
> +static struct fi_faultset fs_tb[MAX_FAULTSET];
> +static struct iIntercept *intcpt = NULL;
> +
> +#define ASLT_INTERFACE "fi.interceptor.aslt.iIntercept"
> +#define ASLT_MODULE "fi_aslt"
> +
> +void dm_trigger(int id, __u32 val, int len, int type, void *data){
> +	int fs_num= FI_FS_NUM(id);
> +	int tri_num=FI_TRI_NUM(id);
> +	int tmp=0, i=0;
> +	struct fi_trigger *tri = NULL;
> +	__u32 old = val;
> +
> +	PDEBUG("entry, id=%#x, val=%#x, len=%d, type=%d, data=%#x\n",
> +	       id, val, len, type, data);
> +	if (fs_num>=MAX_FAULTSET || fs_num<0
> +	    || tri_num>=MAX_TRIGGER_PER_FAULTSET || tri_num<0){
> +		PERROR(":error id number %d\n", id);
> +		goto exit;
> +	}
> +
> +	tri = &fs_tb[fs_num].trigger_tb[tri_num];
> +
> +	if (!tri->registered){
> +		PERROR("Should not trigger an unregistered wp %d!?\n", id);
> +	}
> +
> +
> +	get_random_bytes(&tmp, sizeof(tmp));
> +	if (tri->hertz==0) {tri->hertz=1;};//divid is not 0!
> +	if (tmp >= 0xFFFFFFFF/tri->hertz){
> +		PDEBUG("rnd=%d, HERZ=%d\n", tmp, tri->hertz);
> +		goto exit;
> +	}
> +
> +	tmp = val & (~tri->bitmask);
> +	if (tri->min>tmp || tmp>=tri->max){
> +		PDEBUG("min=%d, max=%d, val=%d\n", tri->min, tri->max, val);
> +		if(!(tri->min==0 && tri->max==0))
> +			goto exit;
> +	}
> +
> +	// Increase count only when passing all conditions
> +	atomic_inc(&tri->count);
> +
> +	if (tri->skip >= atomic_read(&tri->count)){
> +		PDEBUG("count=%d, skip=%d\n", atomic_read(&tri->count), tri->skip);
> +		goto exit;
> +	}
> +
> +	if ( tri->stop!=0 && (tri->stop < (atomic_read(&tri->count)-tri->skip)) ) {
> +		PDEBUG("count=%d, stop=%d\n", atomic_read(&tri->count), tri->stop);
> +		goto exit;
> +	}
> +
> +	PDEBUG("count=%d, skip=%d, min=%d, max=%d, val=%d\n",
> +	       atomic_read(&tri->count), tri->skip, tri->min, tri->max, val);
> +	tmp = val;
> +	for (i=0; i<MAX_OP_PER_TRIGGER; i++) {
> +		switch (tri->ops[i].opcode){
> +		case FI_NOTHING:
> +			goto exit_for;
> +		case FI_SET:
> +			tmp = tri->ops[i].operand;
> +			break;
> +		case FI_AND:
> +			tmp &= tri->ops[i].operand;
> +			break;
> +		case FI_OR:
> +			tmp |= tri->ops[i].operand;
> +			break;
> +		case FI_NOT:
> +			tmp = ~tmp;
> +			break;
> +		case FI_XOR:
> +			tmp ^= tri->ops[i].operand;
> +			break;
> +		case FI_NAND:
> +			tmp = ~(tmp & tri->ops[i].operand);
> +			break;
> +		case FI_NOR:
> +			tmp = ~(tmp | tri->ops[i].operand);
> +			break;
> +		case FI_ADD:
> +			tmp = tmp + tri->ops[i].operand;
> +			break;
> +		case FI_SUB:
> +			tmp = tmp - tri->ops[i].operand;
> +			break;
> +		default:
> +			PERROR("Not recognized opcode%d\n", tri->ops[i].opcode);
> +			break;
> +		}
> +	}
> + exit_for:
> +	val = (val & (tri->protection)) | (tmp & (~tri->protection));
> +
> + exit:
> +
> +	PINFO("id=%#x, val=%#x, old=%#x, len=%d, type=%d, data=%p\n",
> +	      id, val, old, len, type, data);
> +	intcpt->corrupt(id, val, data);
> +	return;
> +}
> +
> +static struct iInterceptHook intcpt_hook[1] = {
> +	{
> +		trigger: dm_trigger
> +	}    
> +};
> +
> +
> +/*manipulate fault set*/
> +static int insert_faultset(struct fi_faultset *fs){
> +	int rv=0;
> +	int i=0;
> +
> +	for (i=0; i<MAX_FAULTSET; i++) {
> +		if (fs_tb[i].stat == NOUSED) break;
> +	}
> +	if (i < MAX_FAULTSET) {
> +		int rv1;
> +		copy_from_user(&fs_tb[i], fs, sizeof(fs_tb[i]));
> +		fs_tb[i].stat = DISABLED;
> +		rv = i;
> +		PDEBUG("modname: %s\n", fs_tb[i].modname);
> +		PINFO("insert #%d fs\n", i);
> +		rv1 = enable_faultset(i);
> +		if(rv1<0) {
> +			PERROR("can not enable faultset# %d\n", i);
> +		}
> +	}else{
> +		rv = -ENOSPC;
> +	}
> +	return rv;
> +}
> +
> +static int remove_faultset(int index){
> +	int rv=0;
> +
> +	if (index<0 || index>=MAX_FAULTSET || fs_tb[index].stat == NOUSED) {
> +		rv = -EPERM;
> +		goto exit1;
> +	}
> +
> +	if (index>=0 && index<MAX_FAULTSET && fs_tb[index].stat == ENABLED) {
> +		disable_faultset(index);
> +	}
> +    
> +	if (index<0 || index>=MAX_FAULTSET || fs_tb[index].stat == ENABLED) {
> +		PERROR("can not remove #%d fs when it is enabled\n", index);
> +		rv = -EPERM;
> +	}else{
> +		fs_tb[index].stat = NOUSED;
> +	}
> +	PINFO("remove #%d fs\n", index);
> + exit1:
> +	return rv;
> +}
> +
> +static int enable_faultset(int index){
> +	int rv=0;
> +	int i=0;
> +	int id_high;
> +	struct fi_faultset *fs;
> +
> +	PDEBUG("trying to enable faultset# %d\n", index);
> +    
> +	if (index<0 || index>= MAX_FAULTSET || fs_tb[index].stat != DISABLED) {
> +		rv = -EINVAL;
> +		goto exit;
> +	}
> +    
> +	id_high = index<<16;
> +	fs = &fs_tb[index];
> +	/*register all wp into interceptor component*/
> +	for (i=0; i<MAX_TRIGGER_PER_FAULTSET && (fs->trigger_tb[i].wp.addr); i++){
> +		PDEBUG("register WP, id=%d, hook=%p\n", id_high+i, intcpt_hook);
> +		atomic_set(&fs->trigger_tb[i].count, 0);
> +		fs->trigger_tb[i].registered = 1;
> +		rv = intcpt->wp_register(fs->trigger_tb[i].wp, id_high+i, intcpt_hook, fs->modname);
> +	
> +		if (rv<0) {
> +			fs->trigger_tb[i].registered = 0;
> +			PERROR("can not register WP, id = %d\n", id_high+i);
> +			continue; //goto exit;//XXX: I should remove registered trigger
> +		}
> +		fs->stat = ENABLED;
> +	}
> +	if (fs->stat == DISABLED) {
> +		PERROR("none of trigger can be active, enable faultset failed!\n");
> +		goto exit;
> +	}
> +	PINFO("enable #%d fs\n", index);
> +	rv = 0;
> + exit:
> +	return rv;
> +}
> +
> +static int disable_faultset(int index){
> +	int rv=0;
> +	int i=0;
> +	int id_high=0;
> +	struct fi_faultset *fs;
> +    
> +	PDEBUG("trying to disable faultset# %d\n", index);
> +	if(index<0 || index>MAX_FAULTSET || fs_tb[index].stat!=ENABLED) {
> +		rv=-EINVAL;
> +		goto exit;
> +	}
> +
> +	id_high=index<<16;
> +	fs = &fs_tb[index];
> +    
> +	for (i=0; i<MAX_TRIGGER_PER_FAULTSET && (fs->trigger_tb[i].wp.addr); i++){
> +		rv = intcpt->wp_unregister(id_high+i, fs->modname);
> +		if (rv>=0) {
> +			fs->trigger_tb[i].registered = 0;
> +		}else{
> +			PERROR("can not unregister wp, id=%d\n", id_high+i); 
> +		}
> +	}
> +	fs->stat = DISABLED;
> +	PINFO("disable #%d fs\n", index);
> +	rv = 0;
> + exit:
> +	return rv;
> +}
> +/*END OF fault set functions*/
> +
> +
> +static int fi_ioctl(struct inode *inode, struct file *file, 
> +		    unsigned int cmd, unsigned long arg){
> +	int rv=0;
> +	int i=0;
> +	unsigned long addr;
> +	struct iGetinfo *p = NULL;
> +	struct iAslt *q = NULL;
> +    
> +	switch (cmd){
> +	default:
> +		rv = -ENOTTY;
> +		break;
> +	case FIIOC_INSERT:
> +		rv = insert_faultset((struct fi_faultset *)arg);
> +		break;
> +	case FIIOC_REMOVE:
> +		get_user(i, (int *)arg);
> +		rv = remove_faultset(i);
> +		break;
> +	case FIIOC_ENABLE:
> +		get_user(i, (int *)arg);
> +		rv = enable_faultset(i);
> +		break;
> +	case FIIOC_DISABLE:
> +		get_user(i, (int *)arg);
> +		rv = disable_faultset(i);
> +		break;
> +	case FIIOC_QUERY_PHYADDR:
> +		q = (struct iAslt *)inter_module_get_request("fi.interceptor.aslt.iLine_to_phy", "fi_aslt");
> +		if(q != NULL) {
> +			get_user(addr, (unsigned long *)arg);
> +			addr = q->fi_line_to_phy(addr);
> +			put_user(addr, (unsigned long *)arg);
> +			inter_module_put("fi.interceptor.aslt.iLine_to_phy");
> +		}else{
> +			PERROR("Can not get fi_line_to_phy! @%s\n", __FILE__);
> +		}
> +		break;
> +	case FIIOC_TRANS_INST:
> +		rv = -1;
> +		p = (struct iGetinfo *)inter_module_get_request("fi.interceptor.dbp.iGetinfo", "fi_dbp");
> +		if(p != NULL) {
> +			rv = p->getinfo((struct fi_ins_record_header *)arg);
> +			inter_module_put("fi.interceptor.dbp.iGetinfo");
> +		} else {
> +			PERROR("Can not get fi.interceptor.dbp.iGetinfo! @%s\n", __FILE__);
> +		}
> +		break;
> +	case FIIOC_QUERY_INTCPT:
> +		rv = 0;
> +		break;
> +	};
> +	return rv;
> +};
> +
> +static spinlock_t counter_lock = SPIN_LOCK_UNLOCKED;
> +static int counter=0;
> +
> +static int fi_open(struct inode *inode, struct file *file){
> +	int rv=0;
> +    
> +	spin_lock(&counter_lock);
> +	if (counter) {
> +		rv = -1;
> +		goto out;
> +	}
> +	counter++;
> +	MOD_INC_USE_COUNT;
> + out:
> +	spin_unlock(&counter_lock);
> +	return rv;
> +}
> +
> +
> +static int fi_release(struct inode *inode, struct file *file){
> +	spin_lock(&counter_lock);
> +	counter--;
> +	MOD_DEC_USE_COUNT;
> +	spin_unlock(&counter_lock);
> +	return 0;
> +}
> +
> +static int dump_faultset(struct fi_faultset *fs, char *buf){
> +	int i=0, n=0, k=0;
> +	int rv=0;
> +	struct iAslt *q=NULL;
> +	static char *op_name[]={
> +		"NOTHING", "SET", "AND", "OR", "NOT", "XOR", "NAND", "NOR", "ADD", "SUB",
> +	};
> +   
> +	if (fs->stat == NOUSED){
> +		n += sprintf(buf+n, "This faultset is not used!\n");
> +		goto exit1;
> +	}
> +    
> +	q = (struct iAslt *)inter_module_get_request("fi.interceptor.aslt.iLine_to_phy", "fi_aslt");
> +	if(q == NULL) {
> +		PERROR("Can not get check_wp! @%s\n", __FILE__);
> +		return rv;
> +	}
> +
> +	n += sprintf( buf+n, "This will dump fault set information, stat=%d\n", 
> +		      fs->stat);
> +	n += sprintf( buf+n, "The faultset is %s\n", 
> +		      (fs->stat==ENABLED)?  "ENABLED" : 
> +		      ((fs->stat==DISABLED)?	"DISABLED":
> +		       "UNKNOWN!"));
> +	for(i=0; i<MAX_TRIGGER_PER_FAULTSET; i++){
> +		int j=0;
> +		struct fi_trigger *tri;
> +	
> +		tri = &fs->trigger_tb[i];
> +		if (tri->wp.addr==NULL) break;
> +		n += sprintf(buf+n, "watchpoint #%d phy_addr=%#lx, type=%#x, len=%d\n", 
> +			     i, tri->wp.addr, tri->wp.type, access_len(tri->wp.type));
> +		n += sprintf(buf+n, "bitmask=%#x, min=%#x, max=%#x, skip=%d, "
> +			     "stop=%d, protection=%#x, Hertz=%#x\n", 
> +			     tri->bitmask, tri->min, tri->max, tri->skip, 
> +			     tri->stop, tri->protection, tri->hertz);
> +	
> +		n += sprintf(buf+n, "ops list\n");
> +		for(j=0; j<MAX_OP_PER_TRIGGER; j++){
> +			char *name;
> +			if (tri->ops[j].opcode==FI_NOTHING) break;
> +			n += sprintf(buf+n, "opcode=%s, operand=%#x\n", 
> +				     op_name[tri->ops[j].opcode], tri->ops[j].operand);
> +		}
> +    	
> +		if (is_MMIO(tri->wp.type)) {
> +			k = q->check_wp(tri->wp);
> +			n += sprintf(buf+n, "watchpoint status:%s\n",
> +				     (tri->registered==1) ?
> +				     ((k==1) ? "PENDING" : "ENABLED") :
> +				     "DISABLED");
> +		} else {
> +			n += sprintf(buf+n, "watchpoint status:%s\n",
> +				     (tri->registered==1) ? "ENABLED" : "DISABLED");
> +		}
> +
> +		n += sprintf(buf+n, "-----------------\n");
> +	}
> +    
> +	inter_module_put("fi.interceptor.aslt.iLine_to_phy");
> +
> + exit1:
> +	n += sprintf(buf+n, "\n");
> +	rv = n;
> +	return rv;
> +}
> +
> +static int fi_proc_read( char* page, char **start, off_t off, int count, int *eof, void *data){
> +	return dump_faultset((struct fi_faultset *)data, page);
> +};
> +
> +static int fi_proc_write( struct file *file, const char *buffer, unsigned long count, void *data){
> +	return 0;//dummy now :-)
> +};
> +
> +static int fi_gc_read( char* page, char **start, off_t off, int count, int *eof, void *data) {
> +	int n=0;
> +    
> +	n = sprintf(page, "%ld", globalcounter);
> +	return ((n>0)?n:0);
> +};
> +
> +static struct file_operations fi_fops[1]={
> +	{
> +		owner: THIS_MODULE,
> +		ioctl: fi_ioctl,
> +		open: fi_open,
> +		release: fi_release
> +	}
> +};
> +
> +
> +static struct proc_dir_entry *root_entry;
> +static struct proc_dir_entry *fs_entry;
> +static struct proc_dir_entry *gc_entry;
> +static int fi_major = FI_MAJOR;
> +
> +static int __init fi_dm_init(void){
> +	int i=0 ;
> +	int rv=0;
> +    
> +	PDEBUG("FI version: %s\n", FI_VERSION);
> +
> +	/*Setup proc file*/
> +	root_entry = proc_mkdir(MODULE_NAME, NULL);
> +	if (!root_entry){
> +		PERROR("can not register proc %s\n", MODULE_NAME);
> +		rv = -ENOMEM;
> +		goto exit1;
> +	}
> +	root_entry->owner=THIS_MODULE;
> +    
> +	for (i=0; i<MAX_FAULTSET; i++){
> +		char name[20];
> +	
> +		sprintf(name, "fs%d", i);
> +		fs_entry = create_proc_entry(name, 0644, root_entry);
> +		if (!fs_entry){
> +			PERROR("can not register proc %s\n", name);
> +			rv = -ENOMEM;
> +			goto exit2;
> +		}
> +		fs_entry->owner = THIS_MODULE;
> +		fs_entry->read_proc = fi_proc_read;
> +		fs_entry->write_proc= fi_proc_write;
> +		fs_entry->data = &fs_tb[i];
> +	}
> +    
> +	gc_entry = create_proc_entry("globalcounter", 0644, root_entry);
> +	if (gc_entry==NULL) {
> +		PERROR("can not register proc %s\n", "globalcounter");
> +		rv = -ENOMEM;
> +		goto exit3;
> +	}
> +	gc_entry->owner = THIS_MODULE;
> +	gc_entry->read_proc = fi_gc_read;
> +    
> +	intcpt= (struct iIntercept *)inter_module_get_request(ASLT_INTERFACE, ASLT_MODULE);
> +	if (intcpt == NULL) {
> +		PERROR("Can not get interface : aslt @%s\n", __FILE__);
> +		rv = -1;
> +		goto exit4;
> +	}
> +
> +	rv = register_chrdev(fi_major, MODULE_NAME, fi_fops);
> +	if (rv<0){
> +		PERROR("can not register device, major=%d\n", fi_major);
> +		goto exit5;
> +	}
> +	if (fi_major==0) fi_major = rv;/*dynamic alloc major number*/
> +	PDEBUG("Setup IOCTL as char device, major=%d\n", fi_major);
> +   
> +	/*clear fs_tb */
> +	memset(fs_tb, 0, sizeof(fs_tb));
> +	EXPORT_NO_SYMBOLS;
> +	return 0;
> +
> + exit5:
> +	inter_module_put(ASLT_INTERFACE);    
> + exit4:
> +	remove_proc_entry("globalcounter", root_entry);
> + exit3:
> +    
> +	i=MAX_FAULTSET;/* error happen above 2, you must clear ALL entries*/
> + exit2:
> +	i--;
> +	for (;i>=0;i--){
> +		char name[20];
> +
> +		sprintf(name, "fs%d", i);
> +		remove_proc_entry(name, root_entry);
> +	}
> +	remove_proc_entry(MODULE_NAME, NULL);
> + exit1:
> +	return rv;
> +};
> +
> +
> +static void __exit fi_dm_cleanup(void){
> +	int i=0;
> +
> +	inter_module_put(ASLT_INTERFACE);    
> +    
> +	unregister_chrdev(fi_major, MODULE_NAME);
> +    
> +	/*unregister proc files*/
> +	remove_proc_entry("globalcounter", root_entry);
> +	for (i=MAX_FAULTSET-1;i>=0;i--){
> +		char name[20];
> +	
> +		sprintf(name, "fs%d", i);
> +		remove_proc_entry(name, root_entry);
> +	}
> +	remove_proc_entry(MODULE_NAME, NULL);
> +
> +	/* remove all faultset */
> +	for(i=0; i<MAX_FAULTSET; i++) {
> +		remove_faultset(i);
> +	}
> +    
> +};
> +
> +
> +module_init(fi_dm_init);
> +module_exit(fi_dm_cleanup);
> +MODULE_AUTHOR("Louis Zhuang");
> +MODULE_DESCRIPTION("Decision Maker component for FI");
> +MODULE_LICENSE("GPL");
> +
> Binary files 47-kp-fi/scripts/kconfig/conf and 47-kp-fi-dm/scripts/kconfig/conf differ
> 
Read over your patch before sending it out. Messages like these
should not be in the patch file.

[Fault-injection-developer] Re:[PATCH] 47-kp2-fi2 features

[Rusty L. <ru...@li...>]

> diff -Nur -X /home/louis/dontdiff 47-kp/Makefile 47-kp-fi/Makefile
> --- 47-kp/Makefile	Tue Nov 26 14:42:30 2002
> +++ 47-kp-fi/Makefile	Mon Nov 25 15:15:38 2002
> @@ -1,7 +1,7 @@
>  VERSION = 2
>  PATCHLEVEL = 5
>  SUBLEVEL = 47
> -EXTRAVERSION =
> +EXTRAVERSION =kp-fi

Why are you doing this?

>  
>  # *DOCUMENTATION*
>  # To see a list of typical targets execute "make help"
> diff -Nur -X /home/louis/dontdiff 47-kp/arch/i386/Kconfig 47-kp-fi/arch/i386/Kconfig
> --- 47-kp/arch/i386/Kconfig	Tue Nov 26 14:42:37 2002
> +++ 47-kp-fi/arch/i386/Kconfig	Mon Nov 25 15:15:40 2002
> @@ -1562,11 +1562,20 @@
>  
>  config DEBUGREG
>  	bool "Global Debug Registers"
> -	depend on DEBUG_KERNEL
> +	depends on DEBUG_KERNEL
> +	help

Hmm... fixing an error from your last patch?  How about fix the code
before making the first patch.  If your first patch only introduces
kprobes and kwatch points, then this patch should not.

>  
>  config KWATCH
>  	bool "Kwatch points"
> -	depend on DEBUGREG
> +	depends on DEBUGREG
> +	help
> +

Same comment as my last

> +config FI
> +	bool "Fault Injection"
> +	depends on KPROBES
> +	help
> +	  Say Y here if you want to enable Fault Injection (FI) mechanism. 
> +	  The FI can monitor MMIO/IO access in kernel.

If you want the choices to be module or nothing, then just code it that way.

Also please add a more descriptive comment for this component.  Keep 
in mind that the world will be stumbling across this option while
trying to configure a kernel, and would like to know something more then
the name of the module.

>  
>  config DEBUG_STACKOVERFLOW
>  	bool "Check for stack overflows"
> diff -Nur -X /home/louis/dontdiff 47-kp/arch/i386/kernel/i386_ksyms.c 47-kp-fi/arch/i386/kernel/i386_ksyms.c
> --- 47-kp/arch/i386/kernel/i386_ksyms.c	Tue Nov 26 14:42:37 2002
> +++ 47-kp-fi/arch/i386/kernel/i386_ksyms.c	Mon Nov 25 15:15:40 2002
> @@ -32,6 +32,7 @@
>  #include <asm/tlbflush.h>
>  #include <asm/nmi.h>
>  #include <asm/edd.h>
> +#include <asm/fi.h>
>  
>  extern void dump_thread(struct pt_regs *, struct user *);
>  extern spinlock_t rtc_lock;
> @@ -216,3 +217,9 @@
>  EXPORT_SYMBOL(edd);
>  EXPORT_SYMBOL(eddnr);
>  #endif
> +
> +#ifdef CONFIG_FI
> +EXPORT_SYMBOL(irq_desc);

None of your other patches even use this symbol.  If you don't have a 
good argument for why this symbol should be exported then just don't 
do it.

If something comes up in the future then fight that fight then.

> +EXPORT_SYMBOL(fi_page_fault);
> +EXPORT_SYMBOL(fi_post_page_fault);
> +#endif
> diff -Nur -X /home/louis/dontdiff 47-kp/arch/i386/kernel/traps.c 47-kp-fi/arch/i386/kernel/traps.c
> --- 47-kp/arch/i386/kernel/traps.c	Tue Nov 26 14:42:37 2002
> +++ 47-kp-fi/arch/i386/kernel/traps.c	Mon Nov 25 15:15:41 2002
> @@ -47,6 +47,7 @@
>  #include <asm/smp.h>
>  #include <asm/pgalloc.h>
>  #include <asm/arch_hooks.h>
> +#include <asm/fi.h>
>  
>  #include <linux/irq.h>
>  #include <linux/module.h>
> @@ -564,6 +565,9 @@
>  	return 0;
>  }
>  
> +int (*fi_post_page_fault) (unsigned long condition,
> +		struct pt_regs *reg);
> +
>  /*
>   * Our handling of the processor debug registers is non-trivial.
>   * We do not clear them on entry and exit from the kernel. Therefore
> @@ -599,7 +603,10 @@
>  
>  	if (kwatch_handler(condition, regs))
>  		return 1;
> -
> +#ifdef CONFIG_FI
> +	if (fi_post_page_fault && fi_post_page_fault(condition, regs))
> +		return 1;
> +#endif

I don't think this is the right way of hooking into do_debug.
Change this to the model that kprobes follows.  You don't have to 
have ugly #if/#endif wrappers (see Documentation/SubmittingPatches)
in this file, and you don't have to rely on black magic with symbol 
names.


>  	/* Interrupts not disabled for normal trap handling. */
>  	restore_interrupts(regs);
>  
> diff -Nur -X /home/louis/dontdiff 47-kp/arch/i386/mm/fault.c 47-kp-fi/arch/i386/mm/fault.c
> --- 47-kp/arch/i386/mm/fault.c	Tue Nov 26 14:42:37 2002
> +++ 47-kp-fi/arch/i386/mm/fault.c	Mon Nov 25 15:15:41 2002
> @@ -26,6 +26,7 @@
>  #include <asm/pgalloc.h>
>  #include <asm/hardirq.h>
>  #include <asm/desc.h>
> +#include <asm/fi.h>
>  
>  extern void die(const char *,struct pt_regs *,long);
>  
> @@ -139,6 +140,7 @@
>  }
>  
>  asmlinkage void do_invalid_op(struct pt_regs *, unsigned long);
> +int (*fi_page_fault) ( struct pt_regs *regs, unsigned long address);
>  
>  /*
>   * This routine handles page faults.  It determines the address,
> @@ -166,7 +168,10 @@
>  
>  	if (kprobe_running() && kprobe_fault_handler(regs, 14))
>  		return;
> -
> +#ifdef CONFIG_FI
> +	if (fi_page_fault && fi_page_fault(regs, address))
> +		return;
> +#endif

Same comment about hooking into code that I said above.

>  	/* It's safe to allow irq's after cr2 has been saved */
>  	if (regs->eflags & X86_EFLAGS_IF)
>  		local_irq_enable();
> diff -Nur -X /home/louis/dontdiff 47-kp/include/asm-i386/fi.h 47-kp-fi/include/asm-i386/fi.h
> --- 47-kp/include/asm-i386/fi.h	Thu Jan  1 08:00:00 1970
> +++ 47-kp-fi/include/asm-i386/fi.h	Mon Nov 25 15:16:18 2002
> @@ -0,0 +1,8 @@
> +#ifndef _ASM_FI_H
> +#define _ASM_FI_H
> +#ifdef CONFIG_FI
> +extern int (*fi_page_fault) ( struct pt_regs *regs, unsigned long address);
> +extern int (*fi_post_page_fault) (unsigned long condition, 
> +		struct pt_regs *reg);
> +#endif
> +#endif /* _ASM_FI_H */
> diff -Nur -X /home/louis/dontdiff 47-kp/kernel/ksyms.c 47-kp-fi/kernel/ksyms.c
> --- 47-kp/kernel/ksyms.c	Tue Nov 26 14:43:31 2002
> +++ 47-kp-fi/kernel/ksyms.c	Mon Nov 25 15:16:27 2002
> @@ -601,3 +601,7 @@
>  
>  /* debug */
>  EXPORT_SYMBOL(dump_stack);
> +
> +#ifdef CONFIG_FI
> +EXPORT_SYMBOL(module_list);

I don't think the current in-kernel linking implementation uses
module_list anymore. At least not for i386.

> +#endif
> 

Re: [Fault-injection-developer] New fith-mini-9 is released

[Rusty L. <ru...@li...>]

If you have a patch that depends on feature X, then base your work on
a tree that has feature X and create a patch for feature X and a patch
for the code that uses feature X.

If you just plan on someday using feature X, but are not using yet, then
do not base what you are doing on a tree that is polluted with that feature.

(Well, in all reality you can do what you want in your own source tree,
just do not let that code pollute patches that you submit.)

    -rusty
----- Original Message -----
From: "Zhuang, Louis" <lou...@in...>
To: "'Rusty Lynch'" <ru...@li...>; "FITHML (E-mail)"
<fau...@so...>
Sent: Tuesday, November 26, 2002 5:08 PM
Subject: RE: [Fault-injection-developer] New fith-mini-9 is released


> In minimal FITH, we'd like to show something that kprobes can not do but
> FITH can. It is page fault interceptor.
> Other not-included interceptors did use kprobes but much easier than
kprobes
> indeed. We'd like to put them into successor patches.
>
> > -----Original Message-----
> > From: Rusty Lynch [mailto:ru...@li...]
> > Sent: Wednesday, November 27, 2002 8:22 AM
> > To: Zhuang, Louis; 'Rusty Lynch'; FITHML (E-mail)
> > Subject: Re: [Fault-injection-developer] New fith-mini-9 is released
> >
> >
> > Am I missing something here?  There isn't a single kprobe or
> > kwatch call in
> > any of your code.  If you are not using kprobes or kwatch
> > then why are you
> > going through all the trouble to make your patchs apply on top of it?
> >
> >     -rusty
> >
> > ----- Original Message -----
> > From: "Zhuang, Louis" <lou...@in...>
> > To: "'Rusty Lynch'" <ru...@li...>; "FITHML (E-mail)"
> > <fau...@so...>
> > Sent: Monday, November 25, 2002 11:30 PM
> > Subject: [Fault-injection-developer] New fith-mini-9 is released
> >
> >
> > > Cut one level direction
> > > Add a simple README.
> > >
> > >     > -----Original Message-----
> > >     > From: Rusty Lynch [mailto:ru...@li...]
> > >     > Sent: Tuesday, November 26, 2002 8:54 AM
> > >     > To: Zhuang, Louis; Lynch, Rusty; 'Rusty Lynch';
> > FITHML (E-mail)
> > >     > Subject: Re: [Fault-injection-developer] RE: [PATCH 0/3]
> > >     > FITH patch against 2.5.47
> > >     >
> > >     >
> > >     > So I guess you are saying that you have something like:
> > >     > /a/a1/linux/
> > >     > /b/b1/linux/
> > >     >
> > >     > and you want to build a patch without having to make the
> > >     > rest of the world
> > >     > reproduce the directory structure you happen to be using?
> > >     >
> > >     > Why not just add a symbolic link to b/b1/linux, so:
> > >     >
> > >     > cd /a/a1
> > >     > ln -s /b/b1/linux hacked_linux
> > >     >
> > >     > and then create you patch by
> > >     > cd /a/a1/
> > >     > patch -urN linux hacked_linux
> > >     >
> > >     >     -rusty
> > >     > ----- Original Message -----
> > >     > From: "Zhuang, Louis" <lou...@in...>
> > >     > To: "Lynch, Rusty" <rus...@in...>; "'Rusty Lynch'"
> > >     > <ru...@li...>; "FITHML (E-mail)"
> > >     > <fau...@so...>
> > >     > Sent: Monday, November 25, 2002 4:40 PM
> > >     > Subject: RE: [Fault-injection-developer] RE: [PATCH 0/3]
> > >     > FITH patch against
> > >     > 2.5.47
> > >     >
> > >     >
> > >     > > Yes, it's a good convention. There are two level
> > >     > directory just because of
> > >     > > my development hierarchy. Do you have some utilities
> > >     > which can reduce the
> > >     > > level of hierarchy of patch? :-)
> > >     > >
> > >     > >     > -----Original Message-----
> > >     > >     > From: Lynch, Rusty
> > >     > >     > Sent: Tuesday, November 26, 2002 8:38 AM
> > >     > >     > To: Zhuang, Louis; 'Rusty Lynch'; FITHML (E-mail)
> > >     > >     > Subject: RE: [Fault-injection-developer] RE:
> > [PATCH 0/3]
> > >     > >     > FITH patch against 2.5.47
> > >     > >     >
> > >     > >     >
> > >     > >     > Ok, thanks.  BTW, patches should normally
> > apply from the
> > >     > >     > kernel root, not one directory above.
> > >     > >     >
> > >     > >     > In other words, if someone hands you over a
> > patch for the
> > >     > >     > kernel, you should be able to apply
> > >     > >     > the patch by:
> > >     > >     >
> > >     > >     > $ cd YOURKERNELROOT
> > >     > >     > $ patch -p1 < PATH_TO_PATCH/somepatch.diff
> > >     > >     >
> > >     > >     > -rusty
> > >     > >     >
> > >     > >     > -----Original Message-----
> > >     > >     > From: Zhuang, Louis [mailto:lou...@in...]
> > >     > >     > Sent: Monday, November 25, 2002 4:22 PM
> > >     > >     > To: 'Rusty Lynch'; Zhuang, Louis; FITHML (E-mail)
> > >     > >     > Subject: [Fault-injection-developer] RE:
> > [PATCH 0/3] FITH
> > >     > >     > patch against 2.5.47
> > >     > >     >
> > >     > >     >
> > >     > >     > All patch files are included in fith-mini-8.tgz
> > >     > >     >
> > http://prdownloads.sourceforge.net/fault-injection/fith-mi
> > >     > >     > ni-8.tgz?download
> > >     > >     >
> > >     > >     >     > -----Original Message-----
> > >     > >     >     > From: Rusty Lynch [mailto:ru...@li...]
> > >     > >     >     > Sent: Tuesday, November 26, 2002 1:41 AM
> > >     > >     >     > To: Zhuang, Louis; FITHML (E-mail)
> > >     > >     >     > Subject: Re: [Fault-injection-developer]
> > >     > [PATCH 0/3] FITH
> > >     > >     >     > patch against
> > >     > >     >     > 2.5.47
> > >     > >     >     >
> > >     > >     >     >
> > >     > >     >     > Louis, your emailer seems to have messed up the
> > >     > >     > patch files by
> > >     > >     >     > adding new lines.  Could you put them up on
> > >     > a public server
> > >     > >     >     > (like maybe the sourceforge site) if
> > you are having
> > >     > >     > problems
> > >     > >     >     > posting a patchfile that doesn't get corrupted?
> > >     > >     >     >
> > >     > >     >     >     -rustyl
> > >     > >     >     >
> > >     > >     >     > ----- Original Message -----
> > >     > >     >     > From: "Zhuang, Louis" <lou...@in...>
> > >     > >     >     > To: "FITHML (E-mail)"
> > >     > >     > <fau...@so...>
> > >     > >     >     > Sent: Monday, November 25, 2002 2:02 AM
> > >     > >     >     > Subject: [Fault-injection-developer] [PATCH
> > >     > 0/3] FITH
> > >     > >     >     > patch against 2.5.47
> > >     > >     >     >
> > >     > >     >     >
> > >     > >     >     > > Dear all,
> > >     > >     >     > > We'd like to put these patches as minimal
> > >     > as possible
> > >     > >     >     > in order to
> > >     > >     >     > > give more feedback.
> > >     > >     >     > > Any comments, especially about the addon
> > >     > patches welcome.
> > >     > >     >     > >
> > >     > >     >     > >   - Louis
> > >     > >     >     > >
> > >     > >     >     > >
> > >     > >     >     > >
> > >     > >     >     > >
> > >     > -------------------------------------------------------
> > >     > >     >     > > This sf.net email is sponsored by:ThinkGeek
> > >     > >     >     > > Welcome to geek heaven.
> > >     > >     >     > > http://thinkgeek.com/sf
> > >     > >     >     > >
> > _______________________________________________
> > >     > >     >     > > Fault-injection-developer mailing list
> > >     > >     >     > >
> > Fau...@li...
> > >     > >     >     > >
> > >     > >     >     >
> > > https://lists.sourceforge.net/lists/listinfo/fault-injecti
> > > >     >     > on-developer
> > > >     >     >
> > > >     >
> > > >     >
> > > >     > -------------------------------------------------------
> > > >     > This SF.net email is sponsored by: Get the new Palm
> > Tungsten T
> > > >     > handheld. Power & Color in a compact size!
> > > >     > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> > > >     > _______________________________________________
> > > >     > Fault-injection-developer mailing list
> > > >     > Fau...@li...
> > > >     > https://lists.sourceforge.net/lists/listinfo/fault-injecti
> > > > on-developer
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: Get the new Palm Tungsten T
> > > handheld. Power & Color in a compact size!
> > > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> > > _______________________________________________
> > > Fault-injection-developer mailing list
> > > Fau...@li...
> > >
> https://lists.sourceforge.net/lists/listinfo/fault-injection-developer

RE: [Fault-injection-developer] New fith-mini-9 is released

[Zhuang, L. <lou...@in...>]

In minimal FITH, we'd like to show something that kprobes can not do but
FITH can. It is page fault interceptor. 
Other not-included interceptors did use kprobes but much easier than kprobes
indeed. We'd like to put them into successor patches.

> -----Original Message-----
> From: Rusty Lynch [mailto:ru...@li...]
> Sent: Wednesday, November 27, 2002 8:22 AM
> To: Zhuang, Louis; 'Rusty Lynch'; FITHML (E-mail)
> Subject: Re: [Fault-injection-developer] New fith-mini-9 is released
> 
> 
> Am I missing something here?  There isn't a single kprobe or 
> kwatch call in
> any of your code.  If you are not using kprobes or kwatch 
> then why are you
> going through all the trouble to make your patchs apply on top of it?
> 
>     -rusty
> 
> ----- Original Message -----
> From: "Zhuang, Louis" <lou...@in...>
> To: "'Rusty Lynch'" <ru...@li...>; "FITHML (E-mail)"
> <fau...@so...>
> Sent: Monday, November 25, 2002 11:30 PM
> Subject: [Fault-injection-developer] New fith-mini-9 is released
> 
> 
> > Cut one level direction
> > Add a simple README.
> >
> >     > -----Original Message-----
> >     > From: Rusty Lynch [mailto:ru...@li...]
> >     > Sent: Tuesday, November 26, 2002 8:54 AM
> >     > To: Zhuang, Louis; Lynch, Rusty; 'Rusty Lynch'; 
> FITHML (E-mail)
> >     > Subject: Re: [Fault-injection-developer] RE: [PATCH 0/3]
> >     > FITH patch against 2.5.47
> >     >
> >     >
> >     > So I guess you are saying that you have something like:
> >     > /a/a1/linux/
> >     > /b/b1/linux/
> >     >
> >     > and you want to build a patch without having to make the
> >     > rest of the world
> >     > reproduce the directory structure you happen to be using?
> >     >
> >     > Why not just add a symbolic link to b/b1/linux, so:
> >     >
> >     > cd /a/a1
> >     > ln -s /b/b1/linux hacked_linux
> >     >
> >     > and then create you patch by
> >     > cd /a/a1/
> >     > patch -urN linux hacked_linux
> >     >
> >     >     -rusty
> >     > ----- Original Message -----
> >     > From: "Zhuang, Louis" <lou...@in...>
> >     > To: "Lynch, Rusty" <rus...@in...>; "'Rusty Lynch'"
> >     > <ru...@li...>; "FITHML (E-mail)"
> >     > <fau...@so...>
> >     > Sent: Monday, November 25, 2002 4:40 PM
> >     > Subject: RE: [Fault-injection-developer] RE: [PATCH 0/3]
> >     > FITH patch against
> >     > 2.5.47
> >     >
> >     >
> >     > > Yes, it's a good convention. There are two level
> >     > directory just because of
> >     > > my development hierarchy. Do you have some utilities
> >     > which can reduce the
> >     > > level of hierarchy of patch? :-)
> >     > >
> >     > >     > -----Original Message-----
> >     > >     > From: Lynch, Rusty
> >     > >     > Sent: Tuesday, November 26, 2002 8:38 AM
> >     > >     > To: Zhuang, Louis; 'Rusty Lynch'; FITHML (E-mail)
> >     > >     > Subject: RE: [Fault-injection-developer] RE: 
> [PATCH 0/3]
> >     > >     > FITH patch against 2.5.47
> >     > >     >
> >     > >     >
> >     > >     > Ok, thanks.  BTW, patches should normally 
> apply from the
> >     > >     > kernel root, not one directory above.
> >     > >     >
> >     > >     > In other words, if someone hands you over a 
> patch for the
> >     > >     > kernel, you should be able to apply
> >     > >     > the patch by:
> >     > >     >
> >     > >     > $ cd YOURKERNELROOT
> >     > >     > $ patch -p1 < PATH_TO_PATCH/somepatch.diff
> >     > >     >
> >     > >     > -rusty
> >     > >     >
> >     > >     > -----Original Message-----
> >     > >     > From: Zhuang, Louis [mailto:lou...@in...]
> >     > >     > Sent: Monday, November 25, 2002 4:22 PM
> >     > >     > To: 'Rusty Lynch'; Zhuang, Louis; FITHML (E-mail)
> >     > >     > Subject: [Fault-injection-developer] RE: 
> [PATCH 0/3] FITH
> >     > >     > patch against 2.5.47
> >     > >     >
> >     > >     >
> >     > >     > All patch files are included in fith-mini-8.tgz
> >     > >     > 
> http://prdownloads.sourceforge.net/fault-injection/fith-mi
> >     > >     > ni-8.tgz?download
> >     > >     >
> >     > >     >     > -----Original Message-----
> >     > >     >     > From: Rusty Lynch [mailto:ru...@li...]
> >     > >     >     > Sent: Tuesday, November 26, 2002 1:41 AM
> >     > >     >     > To: Zhuang, Louis; FITHML (E-mail)
> >     > >     >     > Subject: Re: [Fault-injection-developer]
> >     > [PATCH 0/3] FITH
> >     > >     >     > patch against
> >     > >     >     > 2.5.47
> >     > >     >     >
> >     > >     >     >
> >     > >     >     > Louis, your emailer seems to have messed up the
> >     > >     > patch files by
> >     > >     >     > adding new lines.  Could you put them up on
> >     > a public server
> >     > >     >     > (like maybe the sourceforge site) if 
> you are having
> >     > >     > problems
> >     > >     >     > posting a patchfile that doesn't get corrupted?
> >     > >     >     >
> >     > >     >     >     -rustyl
> >     > >     >     >
> >     > >     >     > ----- Original Message -----
> >     > >     >     > From: "Zhuang, Louis" <lou...@in...>
> >     > >     >     > To: "FITHML (E-mail)"
> >     > >     > <fau...@so...>
> >     > >     >     > Sent: Monday, November 25, 2002 2:02 AM
> >     > >     >     > Subject: [Fault-injection-developer] [PATCH
> >     > 0/3] FITH
> >     > >     >     > patch against 2.5.47
> >     > >     >     >
> >     > >     >     >
> >     > >     >     > > Dear all,
> >     > >     >     > > We'd like to put these patches as minimal
> >     > as possible
> >     > >     >     > in order to
> >     > >     >     > > give more feedback.
> >     > >     >     > > Any comments, especially about the addon
> >     > patches welcome.
> >     > >     >     > >
> >     > >     >     > >   - Louis
> >     > >     >     > >
> >     > >     >     > >
> >     > >     >     > >
> >     > >     >     > >
> >     > -------------------------------------------------------
> >     > >     >     > > This sf.net email is sponsored by:ThinkGeek
> >     > >     >     > > Welcome to geek heaven.
> >     > >     >     > > http://thinkgeek.com/sf
> >     > >     >     > > 
> _______________________________________________
> >     > >     >     > > Fault-injection-developer mailing list
> >     > >     >     > > 
> Fau...@li...
> >     > >     >     > >
> >     > >     >     >
> > https://lists.sourceforge.net/lists/listinfo/fault-injecti
> > >     >     > on-developer
> > >     >     >
> > >     >
> > >     >
> > >     > -------------------------------------------------------
> > >     > This SF.net email is sponsored by: Get the new Palm 
> Tungsten T
> > >     > handheld. Power & Color in a compact size!
> > >     > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> > >     > _______________________________________________
> > >     > Fault-injection-developer mailing list
> > >     > Fau...@li...
> > >     > https://lists.sourceforge.net/lists/listinfo/fault-injecti
> > > on-developer
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Get the new Palm Tungsten T
> > handheld. Power & Color in a compact size!
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> > _______________________________________________
> > Fault-injection-developer mailing list
> > Fau...@li...
> > 
https://lists.sourceforge.net/lists/listinfo/fault-injection-developer

RE: [Fault-injection-developer] Kernel module's implementation in 2.5.48/2.5.49

[Zhuang, L. <lou...@in...>]

I agree too. :-) But Stanley has reported this problem into LKML.
Unfortunately, nobody else cares about it and nobody else ever tries this
API. No reference in kernel against this API.

> -----Original Message-----
> From: Rusty Lynch [mailto:ru...@li...]
> Sent: Wednesday, November 27, 2002 3:58 AM
> To: Zhuang, Louis; Wang, Stanley; SourceforgeFI mail list (E-mail)
> Subject: Re: [Fault-injection-developer] Kernel module's 
> implementation
> in 2.5.48/2.5.49
> 
> 
> I disagree.  We need to be working on the front lines with the
> rest of the kernel hackers.  If in our development we find
> problems with other subsystems, then we report them and if
> possible supply a patch that fixes the problem.
> 
>     -rustyl
> 
> ----- Original Message -----
> From: "Zhuang, Louis" <lou...@in...>
> To: "Wang, Stanley" <sta...@in...>; "SourceforgeFI mail list
> (E-mail)" <fau...@li...>
> Sent: Tuesday, November 26, 2002 1:58 AM
> Subject: RE: [Fault-injection-developer] Kernel module's 
> implementation in
> 2.5.48/2.5.49
> 
> 
> > According to Stanley's investigation, I'd like to suggest delay our
> porting
> > against new module API until they are stable and compatible 
> enough. -Louis
> >
> >     > -----Original Message-----
> >     > From: Wang, Stanley [mailto:sta...@in...]
> >     > Sent: Tuesday, November 26, 2002 4:40 PM
> >     > To: SourceforgeFI mail list (E-mail)
> >     > Subject: [Fault-injection-developer] Kernel module's
> >     > implementaiton in
> >     > 2.5.48/2.5.49
> >     >
> >     >
> >     > Hello folks,
> >     > The kernel module's implementation has been changed a lot
> >     > since 2.5.48. And
> >     > some of them would
> >     > influence our development work:
> >     > 1. kernel module's name should be specified by defining
> >     > KBUILD_MODNAME
> >     > 2. The in-kernel module loader had been rewrited, the
> >     > modversions.h had been
> >     > eliminated
> >     > 3. The kernel implemented a new mechanism for get/put
> >     > symbols between
> >     > different modules:
> >     > symbol_get(const char*)/symbol_put(const char
> >     > *)/symbol_put_addr(void *).
> >     > These function
> >     > could get/put a symbol that had been exported by another
> >     > kernel module.
> >     > But there is a little bug with them, the following patch
> >     > could fix this bug:
> >     >
> >     >
> >     > diff -Naur -X dontdiff linux-2.5.49/include/linux/module.h
> >     > linux-2.5.49-bugfix/include/linux/module.h
> >     > --- linux-2.5.49/include/linux/module.h 2002-11-26
> >     > 16:06:36.000000000 +0800
> >     > +++ linux-2.5.49-bugfix/include/linux/module.h 2002-11-26
> >     > 16:01:52.000000000 +0800
> >     > @@ -86,7 +86,7 @@
> >     >  /* Get/put a kernel symbol (calls must be symmetric) */
> >     >  void *__symbol_get(const char *symbol);
> >     >  void *__symbol_get_gpl(const char *symbol);
> >     > -#define symbol_get(x) ((typeof(&x))(__symbol_get(#x)))
> >     > +#define symbol_get(x) ((typeof(&x))(__symbol_get(x)))
> >     >
> >     >  /* For every exported symbol, place a struct in the
> >     > __ksymtab section */
> >     >  #define EXPORT_SYMBOL(sym) \
> >     > @@ -166,7 +166,7 @@
> >     >  #ifdef CONFIG_MODULE_UNLOAD
> >     >
> >     >  void __symbol_put(const char *symbol);
> >     > -#define symbol_put(x) __symbol_put(#x)
> >     > +#define symbol_put(x) __symbol_put(x)
> >     >  void symbol_put_addr(void *addr);
> >     >
> >     >  /* We only need protection against local interrupts. */
> >     >
> >     >
> >     >
> >     > 4. You should get a new module utiliy to cooperate with
> >     > 2.5.48/2.5.49
> >     > (from http://ozlabs.org/~rusty/module-init-tools-0.7.tar.gz)
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Get the new Palm Tungsten T
> > handheld. Power & Color in a compact size!
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> > _______________________________________________
> > Fault-injection-developer mailing list
> > Fau...@li...
> > 
> https://lists.sourceforge.net/lists/listinfo/fault-injection-developer
> 

Re: [Fault-injection-developer] New fith-mini-9 is released

[Rusty L. <ru...@li...>]

Am I missing something here?  There isn't a single kprobe or kwatch call in
any of your code.  If you are not using kprobes or kwatch then why are you
going through all the trouble to make your patchs apply on top of it?

    -rusty

----- Original Message -----
From: "Zhuang, Louis" <lou...@in...>
To: "'Rusty Lynch'" <ru...@li...>; "FITHML (E-mail)"
<fau...@so...>
Sent: Monday, November 25, 2002 11:30 PM
Subject: [Fault-injection-developer] New fith-mini-9 is released


> Cut one level direction
> Add a simple README.
>
>     > -----Original Message-----
>     > From: Rusty Lynch [mailto:ru...@li...]
>     > Sent: Tuesday, November 26, 2002 8:54 AM
>     > To: Zhuang, Louis; Lynch, Rusty; 'Rusty Lynch'; FITHML (E-mail)
>     > Subject: Re: [Fault-injection-developer] RE: [PATCH 0/3]
>     > FITH patch against 2.5.47
>     >
>     >
>     > So I guess you are saying that you have something like:
>     > /a/a1/linux/
>     > /b/b1/linux/
>     >
>     > and you want to build a patch without having to make the
>     > rest of the world
>     > reproduce the directory structure you happen to be using?
>     >
>     > Why not just add a symbolic link to b/b1/linux, so:
>     >
>     > cd /a/a1
>     > ln -s /b/b1/linux hacked_linux
>     >
>     > and then create you patch by
>     > cd /a/a1/
>     > patch -urN linux hacked_linux
>     >
>     >     -rusty
>     > ----- Original Message -----
>     > From: "Zhuang, Louis" <lou...@in...>
>     > To: "Lynch, Rusty" <rus...@in...>; "'Rusty Lynch'"
>     > <ru...@li...>; "FITHML (E-mail)"
>     > <fau...@so...>
>     > Sent: Monday, November 25, 2002 4:40 PM
>     > Subject: RE: [Fault-injection-developer] RE: [PATCH 0/3]
>     > FITH patch against
>     > 2.5.47
>     >
>     >
>     > > Yes, it's a good convention. There are two level
>     > directory just because of
>     > > my development hierarchy. Do you have some utilities
>     > which can reduce the
>     > > level of hierarchy of patch? :-)
>     > >
>     > >     > -----Original Message-----
>     > >     > From: Lynch, Rusty
>     > >     > Sent: Tuesday, November 26, 2002 8:38 AM
>     > >     > To: Zhuang, Louis; 'Rusty Lynch'; FITHML (E-mail)
>     > >     > Subject: RE: [Fault-injection-developer] RE: [PATCH 0/3]
>     > >     > FITH patch against 2.5.47
>     > >     >
>     > >     >
>     > >     > Ok, thanks.  BTW, patches should normally apply from the
>     > >     > kernel root, not one directory above.
>     > >     >
>     > >     > In other words, if someone hands you over a patch for the
>     > >     > kernel, you should be able to apply
>     > >     > the patch by:
>     > >     >
>     > >     > $ cd YOURKERNELROOT
>     > >     > $ patch -p1 < PATH_TO_PATCH/somepatch.diff
>     > >     >
>     > >     > -rusty
>     > >     >
>     > >     > -----Original Message-----
>     > >     > From: Zhuang, Louis [mailto:lou...@in...]
>     > >     > Sent: Monday, November 25, 2002 4:22 PM
>     > >     > To: 'Rusty Lynch'; Zhuang, Louis; FITHML (E-mail)
>     > >     > Subject: [Fault-injection-developer] RE: [PATCH 0/3] FITH
>     > >     > patch against 2.5.47
>     > >     >
>     > >     >
>     > >     > All patch files are included in fith-mini-8.tgz
>     > >     > http://prdownloads.sourceforge.net/fault-injection/fith-mi
>     > >     > ni-8.tgz?download
>     > >     >
>     > >     >     > -----Original Message-----
>     > >     >     > From: Rusty Lynch [mailto:ru...@li...]
>     > >     >     > Sent: Tuesday, November 26, 2002 1:41 AM
>     > >     >     > To: Zhuang, Louis; FITHML (E-mail)
>     > >     >     > Subject: Re: [Fault-injection-developer]
>     > [PATCH 0/3] FITH
>     > >     >     > patch against
>     > >     >     > 2.5.47
>     > >     >     >
>     > >     >     >
>     > >     >     > Louis, your emailer seems to have messed up the
>     > >     > patch files by
>     > >     >     > adding new lines.  Could you put them up on
>     > a public server
>     > >     >     > (like maybe the sourceforge site) if you are having
>     > >     > problems
>     > >     >     > posting a patchfile that doesn't get corrupted?
>     > >     >     >
>     > >     >     >     -rustyl
>     > >     >     >
>     > >     >     > ----- Original Message -----
>     > >     >     > From: "Zhuang, Louis" <lou...@in...>
>     > >     >     > To: "FITHML (E-mail)"
>     > >     > <fau...@so...>
>     > >     >     > Sent: Monday, November 25, 2002 2:02 AM
>     > >     >     > Subject: [Fault-injection-developer] [PATCH
>     > 0/3] FITH
>     > >     >     > patch against 2.5.47
>     > >     >     >
>     > >     >     >
>     > >     >     > > Dear all,
>     > >     >     > > We'd like to put these patches as minimal
>     > as possible
>     > >     >     > in order to
>     > >     >     > > give more feedback.
>     > >     >     > > Any comments, especially about the addon
>     > patches welcome.
>     > >     >     > >
>     > >     >     > >   - Louis
>     > >     >     > >
>     > >     >     > >
>     > >     >     > >
>     > >     >     > >
>     > -------------------------------------------------------
>     > >     >     > > This sf.net email is sponsored by:ThinkGeek
>     > >     >     > > Welcome to geek heaven.
>     > >     >     > > http://thinkgeek.com/sf
>     > >     >     > > _______________________________________________
>     > >     >     > > Fault-injection-developer mailing list
>     > >     >     > > Fau...@li...
>     > >     >     > >
>     > >     >     >
> https://lists.sourceforge.net/lists/listinfo/fault-injecti
> >     >     > on-developer
> >     >     >
> >     >
> >     >
> >     > -------------------------------------------------------
> >     > This SF.net email is sponsored by: Get the new Palm Tungsten T
> >     > handheld. Power & Color in a compact size!
> >     > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> >     > _______________________________________________
> >     > Fault-injection-developer mailing list
> >     > Fau...@li...
> >     > https://lists.sourceforge.net/lists/listinfo/fault-injecti
> > on-developer
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten T
> handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> Fault-injection-developer mailing list
> Fau...@li...
> https://lists.sourceforge.net/lists/listinfo/fault-injection-developer

Re: [Fault-injection-developer] Kernel module's implementation in 2.5.48/2.5.49

[Rusty L. <ru...@li...>]

I disagree.  We need to be working on the front lines with the
rest of the kernel hackers.  If in our development we find
problems with other subsystems, then we report them and if
possible supply a patch that fixes the problem.

    -rustyl

----- Original Message -----
From: "Zhuang, Louis" <lou...@in...>
To: "Wang, Stanley" <sta...@in...>; "SourceforgeFI mail list
(E-mail)" <fau...@li...>
Sent: Tuesday, November 26, 2002 1:58 AM
Subject: RE: [Fault-injection-developer] Kernel module's implementation in
2.5.48/2.5.49


> According to Stanley's investigation, I'd like to suggest delay our
porting
> against new module API until they are stable and compatible enough. -Louis
>
>     > -----Original Message-----
>     > From: Wang, Stanley [mailto:sta...@in...]
>     > Sent: Tuesday, November 26, 2002 4:40 PM
>     > To: SourceforgeFI mail list (E-mail)
>     > Subject: [Fault-injection-developer] Kernel module's
>     > implementaiton in
>     > 2.5.48/2.5.49
>     >
>     >
>     > Hello folks,
>     > The kernel module's implementation has been changed a lot
>     > since 2.5.48. And
>     > some of them would
>     > influence our development work:
>     > 1. kernel module's name should be specified by defining
>     > KBUILD_MODNAME
>     > 2. The in-kernel module loader had been rewrited, the
>     > modversions.h had been
>     > eliminated
>     > 3. The kernel implemented a new mechanism for get/put
>     > symbols between
>     > different modules:
>     > symbol_get(const char*)/symbol_put(const char
>     > *)/symbol_put_addr(void *).
>     > These function
>     > could get/put a symbol that had been exported by another
>     > kernel module.
>     > But there is a little bug with them, the following patch
>     > could fix this bug:
>     >
>     >
>     > diff -Naur -X dontdiff linux-2.5.49/include/linux/module.h
>     > linux-2.5.49-bugfix/include/linux/module.h
>     > --- linux-2.5.49/include/linux/module.h 2002-11-26
>     > 16:06:36.000000000 +0800
>     > +++ linux-2.5.49-bugfix/include/linux/module.h 2002-11-26
>     > 16:01:52.000000000 +0800
>     > @@ -86,7 +86,7 @@
>     >  /* Get/put a kernel symbol (calls must be symmetric) */
>     >  void *__symbol_get(const char *symbol);
>     >  void *__symbol_get_gpl(const char *symbol);
>     > -#define symbol_get(x) ((typeof(&x))(__symbol_get(#x)))
>     > +#define symbol_get(x) ((typeof(&x))(__symbol_get(x)))
>     >
>     >  /* For every exported symbol, place a struct in the
>     > __ksymtab section */
>     >  #define EXPORT_SYMBOL(sym) \
>     > @@ -166,7 +166,7 @@
>     >  #ifdef CONFIG_MODULE_UNLOAD
>     >
>     >  void __symbol_put(const char *symbol);
>     > -#define symbol_put(x) __symbol_put(#x)
>     > +#define symbol_put(x) __symbol_put(x)
>     >  void symbol_put_addr(void *addr);
>     >
>     >  /* We only need protection against local interrupts. */
>     >
>     >
>     >
>     > 4. You should get a new module utiliy to cooperate with
>     > 2.5.48/2.5.49
>     > (from http://ozlabs.org/~rusty/module-init-tools-0.7.tar.gz)
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten T
> handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> Fault-injection-developer mailing list
> Fau...@li...
> https://lists.sourceforge.net/lists/listinfo/fault-injection-developer

RE: [Fault-injection-developer] Kernel module's implementation in 2.5.48/2.5.49

[Zhuang, L. <lou...@in...>]

According to Stanley's investigation, I'd like to suggest delay our porting
against new module API until they are stable and compatible enough. -Louis

    > -----Original Message-----
    > From: Wang, Stanley [mailto:sta...@in...]
    > Sent: Tuesday, November 26, 2002 4:40 PM
    > To: SourceforgeFI mail list (E-mail)
    > Subject: [Fault-injection-developer] Kernel module's 
    > implementaiton in
    > 2.5.48/2.5.49
    > 
    > 
    > Hello folks,
    > The kernel module's implementation has been changed a lot 
    > since 2.5.48. And
    > some of them would
    > influence our development work:
    > 1. kernel module's name should be specified by defining 
    > KBUILD_MODNAME
    > 2. The in-kernel module loader had been rewrited, the 
    > modversions.h had been
    > eliminated
    > 3. The kernel implemented a new mechanism for get/put 
    > symbols between
    > different modules:
    > symbol_get(const char*)/symbol_put(const char 
    > *)/symbol_put_addr(void *).
    > These function
    > could get/put a symbol that had been exported by another 
    > kernel module.
    > But there is a little bug with them, the following patch 
    > could fix this bug:
    > 
    > 
    > diff -Naur -X dontdiff linux-2.5.49/include/linux/module.h
    > linux-2.5.49-bugfix/include/linux/module.h
    > --- linux-2.5.49/include/linux/module.h	2002-11-26 
    > 16:06:36.000000000 +0800
    > +++ linux-2.5.49-bugfix/include/linux/module.h	2002-11-26
    > 16:01:52.000000000 +0800
    > @@ -86,7 +86,7 @@
    >  /* Get/put a kernel symbol (calls must be symmetric) */
    >  void *__symbol_get(const char *symbol);
    >  void *__symbol_get_gpl(const char *symbol);
    > -#define symbol_get(x) ((typeof(&x))(__symbol_get(#x)))
    > +#define symbol_get(x) ((typeof(&x))(__symbol_get(x)))
    >  
    >  /* For every exported symbol, place a struct in the 
    > __ksymtab section */
    >  #define EXPORT_SYMBOL(sym)				\
    > @@ -166,7 +166,7 @@
    >  #ifdef CONFIG_MODULE_UNLOAD
    >  
    >  void __symbol_put(const char *symbol);
    > -#define symbol_put(x) __symbol_put(#x)
    > +#define symbol_put(x) __symbol_put(x)
    >  void symbol_put_addr(void *addr);
    >  
    >  /* We only need protection against local interrupts. */
    > 
    > 
    > 
    > 4. You should get a new module utiliy to cooperate with 
    > 2.5.48/2.5.49
    > (from http://ozlabs.org/~rusty/module-init-tools-0.7.tar.gz)

[Fault-injection-developer] Kernel module's implementaiton in 2.5.48/2.5.49

[Wang, S. <sta...@in...>]

Hello folks,
The kernel module's implementation has been changed a lot since 2.5.48. And
some of them would
influence our development work:
1. kernel module's name should be specified by defining KBUILD_MODNAME
2. The in-kernel module loader had been rewrited, the modversions.h had been
eliminated
3. The kernel implemented a new mechanism for get/put symbols between
different modules:
symbol_get(const char*)/symbol_put(const char *)/symbol_put_addr(void *).
These function
could get/put a symbol that had been exported by another kernel module.
But there is a little bug with them, the following patch could fix this bug:


diff -Naur -X dontdiff linux-2.5.49/include/linux/module.h
linux-2.5.49-bugfix/include/linux/module.h
--- linux-2.5.49/include/linux/module.h	2002-11-26 16:06:36.000000000 +0800
+++ linux-2.5.49-bugfix/include/linux/module.h	2002-11-26
16:01:52.000000000 +0800
@@ -86,7 +86,7 @@
 /* Get/put a kernel symbol (calls must be symmetric) */
 void *__symbol_get(const char *symbol);
 void *__symbol_get_gpl(const char *symbol);
-#define symbol_get(x) ((typeof(&x))(__symbol_get(#x)))
+#define symbol_get(x) ((typeof(&x))(__symbol_get(x)))
 
 /* For every exported symbol, place a struct in the __ksymtab section */
 #define EXPORT_SYMBOL(sym)				\
@@ -166,7 +166,7 @@
 #ifdef CONFIG_MODULE_UNLOAD
 
 void __symbol_put(const char *symbol);
-#define symbol_put(x) __symbol_put(#x)
+#define symbol_put(x) __symbol_put(x)
 void symbol_put_addr(void *addr);
 
 /* We only need protection against local interrupts. */



4. You should get a new module utiliy to cooperate with 2.5.48/2.5.49
(from http://ozlabs.org/~rusty/module-init-tools-0.7.tar.gz)

For more detailed information, please read the kernel Change-log for v2.5.48
Thanks

Your Sincerely,
Stanley Wang 

SW Engineer, Intel Corporation.
Intel China Software Lab. 
Tel: 021-52574545 ext. 1171 
iNet: 8-752-1171 
 
Opinions expressed are those of the author and do not represent Intel
Corporation

[Fault-injection-developer] New fith-mini-9 is released

[Zhuang, L. <lou...@in...>]

Cut one level direction
Add a simple README.

    > -----Original Message-----
    > From: Rusty Lynch [mailto:ru...@li...]
    > Sent: Tuesday, November 26, 2002 8:54 AM
    > To: Zhuang, Louis; Lynch, Rusty; 'Rusty Lynch'; FITHML (E-mail)
    > Subject: Re: [Fault-injection-developer] RE: [PATCH 0/3] 
    > FITH patch against 2.5.47
    > 
    > 
    > So I guess you are saying that you have something like:
    > /a/a1/linux/
    > /b/b1/linux/
    > 
    > and you want to build a patch without having to make the 
    > rest of the world
    > reproduce the directory structure you happen to be using?
    > 
    > Why not just add a symbolic link to b/b1/linux, so:
    > 
    > cd /a/a1
    > ln -s /b/b1/linux hacked_linux
    > 
    > and then create you patch by
    > cd /a/a1/
    > patch -urN linux hacked_linux
    > 
    >     -rusty
    > ----- Original Message -----
    > From: "Zhuang, Louis" <lou...@in...>
    > To: "Lynch, Rusty" <rus...@in...>; "'Rusty Lynch'"
    > <ru...@li...>; "FITHML (E-mail)"
    > <fau...@so...>
    > Sent: Monday, November 25, 2002 4:40 PM
    > Subject: RE: [Fault-injection-developer] RE: [PATCH 0/3] 
    > FITH patch against
    > 2.5.47
    > 
    > 
    > > Yes, it's a good convention. There are two level 
    > directory just because of
    > > my development hierarchy. Do you have some utilities 
    > which can reduce the
    > > level of hierarchy of patch? :-)
    > >
    > >     > -----Original Message-----
    > >     > From: Lynch, Rusty
    > >     > Sent: Tuesday, November 26, 2002 8:38 AM
    > >     > To: Zhuang, Louis; 'Rusty Lynch'; FITHML (E-mail)
    > >     > Subject: RE: [Fault-injection-developer] RE: [PATCH 0/3]
    > >     > FITH patch against 2.5.47
    > >     >
    > >     >
    > >     > Ok, thanks.  BTW, patches should normally apply from the
    > >     > kernel root, not one directory above.
    > >     >
    > >     > In other words, if someone hands you over a patch for the
    > >     > kernel, you should be able to apply
    > >     > the patch by:
    > >     >
    > >     > $ cd YOURKERNELROOT
    > >     > $ patch -p1 < PATH_TO_PATCH/somepatch.diff
    > >     >
    > >     > -rusty
    > >     >
    > >     > -----Original Message-----
    > >     > From: Zhuang, Louis [mailto:lou...@in...]
    > >     > Sent: Monday, November 25, 2002 4:22 PM
    > >     > To: 'Rusty Lynch'; Zhuang, Louis; FITHML (E-mail)
    > >     > Subject: [Fault-injection-developer] RE: [PATCH 0/3] FITH
    > >     > patch against 2.5.47
    > >     >
    > >     >
    > >     > All patch files are included in fith-mini-8.tgz
    > >     > http://prdownloads.sourceforge.net/fault-injection/fith-mi
    > >     > ni-8.tgz?download
    > >     >
    > >     >     > -----Original Message-----
    > >     >     > From: Rusty Lynch [mailto:ru...@li...]
    > >     >     > Sent: Tuesday, November 26, 2002 1:41 AM
    > >     >     > To: Zhuang, Louis; FITHML (E-mail)
    > >     >     > Subject: Re: [Fault-injection-developer] 
    > [PATCH 0/3] FITH
    > >     >     > patch against
    > >     >     > 2.5.47
    > >     >     >
    > >     >     >
    > >     >     > Louis, your emailer seems to have messed up the
    > >     > patch files by
    > >     >     > adding new lines.  Could you put them up on 
    > a public server
    > >     >     > (like maybe the sourceforge site) if you are having
    > >     > problems
    > >     >     > posting a patchfile that doesn't get corrupted?
    > >     >     >
    > >     >     >     -rustyl
    > >     >     >
    > >     >     > ----- Original Message -----
    > >     >     > From: "Zhuang, Louis" <lou...@in...>
    > >     >     > To: "FITHML (E-mail)"
    > >     > <fau...@so...>
    > >     >     > Sent: Monday, November 25, 2002 2:02 AM
    > >     >     > Subject: [Fault-injection-developer] [PATCH 
    > 0/3] FITH
    > >     >     > patch against 2.5.47
    > >     >     >
    > >     >     >
    > >     >     > > Dear all,
    > >     >     > > We'd like to put these patches as minimal 
    > as possible
    > >     >     > in order to
    > >     >     > > give more feedback.
    > >     >     > > Any comments, especially about the addon 
    > patches welcome.
    > >     >     > >
    > >     >     > >   - Louis
    > >     >     > >
    > >     >     > >
    > >     >     > >
    > >     >     > > 
    > -------------------------------------------------------
    > >     >     > > This sf.net email is sponsored by:ThinkGeek
    > >     >     > > Welcome to geek heaven.
    > >     >     > > http://thinkgeek.com/sf
    > >     >     > > _______________________________________________
    > >     >     > > Fault-injection-developer mailing list
    > >     >     > > Fau...@li...
    > >     >     > >
    > >     >     > 
https://lists.sourceforge.net/lists/listinfo/fault-injecti
>     >     > on-developer
>     >     >
>     >
>     >
>     > -------------------------------------------------------
>     > This SF.net email is sponsored by: Get the new Palm Tungsten T
>     > handheld. Power & Color in a compact size!
>     > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
>     > _______________________________________________
>     > Fault-injection-developer mailing list
>     > Fau...@li...
>     > https://lists.sourceforge.net/lists/listinfo/fault-injecti
> on-developer

RE: [Fault-injection-developer] RE: [PATCH 0/3] FITH patch agains t 2.5.47

[Zhuang, L. <lou...@in...>]

great idea! how silly I am! :-p

    > -----Original Message-----
    > From: Rusty Lynch [mailto:ru...@li...]
    > Sent: Tuesday, November 26, 2002 8:54 AM
    > To: Zhuang, Louis; Lynch, Rusty; 'Rusty Lynch'; FITHML (E-mail)
    > Subject: Re: [Fault-injection-developer] RE: [PATCH 0/3] 
    > FITH patch against 2.5.47
    > 
    > 
    > So I guess you are saying that you have something like:
    > /a/a1/linux/
    > /b/b1/linux/
    > 
    > and you want to build a patch without having to make the 
    > rest of the world
    > reproduce the directory structure you happen to be using?
    > 
    > Why not just add a symbolic link to b/b1/linux, so:
    > 
    > cd /a/a1
    > ln -s /b/b1/linux hacked_linux
    > 
    > and then create you patch by
    > cd /a/a1/
    > patch -urN linux hacked_linux
    > 
    >     -rusty
    > ----- Original Message -----
    > From: "Zhuang, Louis" <lou...@in...>
    > To: "Lynch, Rusty" <rus...@in...>; "'Rusty Lynch'"
    > <ru...@li...>; "FITHML (E-mail)"
    > <fau...@so...>
    > Sent: Monday, November 25, 2002 4:40 PM
    > Subject: RE: [Fault-injection-developer] RE: [PATCH 0/3] 
    > FITH patch against
    > 2.5.47
    > 
    > 
    > > Yes, it's a good convention. There are two level 
    > directory just because of
    > > my development hierarchy. Do you have some utilities 
    > which can reduce the
    > > level of hierarchy of patch? :-)
    > >
    > >     > -----Original Message-----
    > >     > From: Lynch, Rusty
    > >     > Sent: Tuesday, November 26, 2002 8:38 AM
    > >     > To: Zhuang, Louis; 'Rusty Lynch'; FITHML (E-mail)
    > >     > Subject: RE: [Fault-injection-developer] RE: [PATCH 0/3]
    > >     > FITH patch against 2.5.47
    > >     >
    > >     >
    > >     > Ok, thanks.  BTW, patches should normally apply from the
    > >     > kernel root, not one directory above.
    > >     >
    > >     > In other words, if someone hands you over a patch for the
    > >     > kernel, you should be able to apply
    > >     > the patch by:
    > >     >
    > >     > $ cd YOURKERNELROOT
    > >     > $ patch -p1 < PATH_TO_PATCH/somepatch.diff
    > >     >
    > >     > -rusty
    > >     >
    > >     > -----Original Message-----
    > >     > From: Zhuang, Louis [mailto:lou...@in...]
    > >     > Sent: Monday, November 25, 2002 4:22 PM
    > >     > To: 'Rusty Lynch'; Zhuang, Louis; FITHML (E-mail)
    > >     > Subject: [Fault-injection-developer] RE: [PATCH 0/3] FITH
    > >     > patch against 2.5.47
    > >     >
    > >     >
    > >     > All patch files are included in fith-mini-8.tgz
    > >     > http://prdownloads.sourceforge.net/fault-injection/fith-mi
    > >     > ni-8.tgz?download
    > >     >
    > >     >     > -----Original Message-----
    > >     >     > From: Rusty Lynch [mailto:ru...@li...]
    > >     >     > Sent: Tuesday, November 26, 2002 1:41 AM
    > >     >     > To: Zhuang, Louis; FITHML (E-mail)
    > >     >     > Subject: Re: [Fault-injection-developer] 
    > [PATCH 0/3] FITH
    > >     >     > patch against
    > >     >     > 2.5.47
    > >     >     >
    > >     >     >
    > >     >     > Louis, your emailer seems to have messed up the
    > >     > patch files by
    > >     >     > adding new lines.  Could you put them up on 
    > a public server
    > >     >     > (like maybe the sourceforge site) if you are having
    > >     > problems
    > >     >     > posting a patchfile that doesn't get corrupted?
    > >     >     >
    > >     >     >     -rustyl
    > >     >     >
    > >     >     > ----- Original Message -----
    > >     >     > From: "Zhuang, Louis" <lou...@in...>
    > >     >     > To: "FITHML (E-mail)"
    > >     > <fau...@so...>
    > >     >     > Sent: Monday, November 25, 2002 2:02 AM
    > >     >     > Subject: [Fault-injection-developer] [PATCH 
    > 0/3] FITH
    > >     >     > patch against 2.5.47
    > >     >     >
    > >     >     >
    > >     >     > > Dear all,
    > >     >     > > We'd like to put these patches as minimal 
    > as possible
    > >     >     > in order to
    > >     >     > > give more feedback.
    > >     >     > > Any comments, especially about the addon 
    > patches welcome.
    > >     >     > >
    > >     >     > >   - Louis
    > >     >     > >
    > >     >     > >
    > >     >     > >
    > >     >     > > 
    > -------------------------------------------------------
    > >     >     > > This sf.net email is sponsored by:ThinkGeek
    > >     >     > > Welcome to geek heaven.
    > >     >     > > http://thinkgeek.com/sf
    > >     >     > > _______________________________________________
    > >     >     > > Fault-injection-developer mailing list
    > >     >     > > Fau...@li...
    > >     >     > >
    > >     >     > 
https://lists.sourceforge.net/lists/listinfo/fault-injecti
>     >     > on-developer
>     >     >
>     >
>     >
>     > -------------------------------------------------------
>     > This SF.net email is sponsored by: Get the new Palm Tungsten T
>     > handheld. Power & Color in a compact size!
>     > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
>     > _______________________________________________
>     > Fault-injection-developer mailing list
>     > Fau...@li...
>     > https://lists.sourceforge.net/lists/listinfo/fault-injecti
> on-developer

Re: [Fault-injection-developer] RE: [PATCH 0/3] FITH patch against 2.5.47

[Rusty L. <ru...@li...>]

So I guess you are saying that you have something like:
/a/a1/linux/
/b/b1/linux/

and you want to build a patch without having to make the rest of the world
reproduce the directory structure you happen to be using?

Why not just add a symbolic link to b/b1/linux, so:

cd /a/a1
ln -s /b/b1/linux hacked_linux

and then create you patch by
cd /a/a1/
patch -urN linux hacked_linux

    -rusty
----- Original Message -----
From: "Zhuang, Louis" <lou...@in...>
To: "Lynch, Rusty" <rus...@in...>; "'Rusty Lynch'"
<ru...@li...>; "FITHML (E-mail)"
<fau...@so...>
Sent: Monday, November 25, 2002 4:40 PM
Subject: RE: [Fault-injection-developer] RE: [PATCH 0/3] FITH patch against
2.5.47


> Yes, it's a good convention. There are two level directory just because of
> my development hierarchy. Do you have some utilities which can reduce the
> level of hierarchy of patch? :-)
>
>     > -----Original Message-----
>     > From: Lynch, Rusty
>     > Sent: Tuesday, November 26, 2002 8:38 AM
>     > To: Zhuang, Louis; 'Rusty Lynch'; FITHML (E-mail)
>     > Subject: RE: [Fault-injection-developer] RE: [PATCH 0/3]
>     > FITH patch against 2.5.47
>     >
>     >
>     > Ok, thanks.  BTW, patches should normally apply from the
>     > kernel root, not one directory above.
>     >
>     > In other words, if someone hands you over a patch for the
>     > kernel, you should be able to apply
>     > the patch by:
>     >
>     > $ cd YOURKERNELROOT
>     > $ patch -p1 < PATH_TO_PATCH/somepatch.diff
>     >
>     > -rusty
>     >
>     > -----Original Message-----
>     > From: Zhuang, Louis [mailto:lou...@in...]
>     > Sent: Monday, November 25, 2002 4:22 PM
>     > To: 'Rusty Lynch'; Zhuang, Louis; FITHML (E-mail)
>     > Subject: [Fault-injection-developer] RE: [PATCH 0/3] FITH
>     > patch against 2.5.47
>     >
>     >
>     > All patch files are included in fith-mini-8.tgz
>     > http://prdownloads.sourceforge.net/fault-injection/fith-mi
>     > ni-8.tgz?download
>     >
>     >     > -----Original Message-----
>     >     > From: Rusty Lynch [mailto:ru...@li...]
>     >     > Sent: Tuesday, November 26, 2002 1:41 AM
>     >     > To: Zhuang, Louis; FITHML (E-mail)
>     >     > Subject: Re: [Fault-injection-developer] [PATCH 0/3] FITH
>     >     > patch against
>     >     > 2.5.47
>     >     >
>     >     >
>     >     > Louis, your emailer seems to have messed up the
>     > patch files by
>     >     > adding new lines.  Could you put them up on a public server
>     >     > (like maybe the sourceforge site) if you are having
>     > problems
>     >     > posting a patchfile that doesn't get corrupted?
>     >     >
>     >     >     -rustyl
>     >     >
>     >     > ----- Original Message -----
>     >     > From: "Zhuang, Louis" <lou...@in...>
>     >     > To: "FITHML (E-mail)"
>     > <fau...@so...>
>     >     > Sent: Monday, November 25, 2002 2:02 AM
>     >     > Subject: [Fault-injection-developer] [PATCH 0/3] FITH
>     >     > patch against 2.5.47
>     >     >
>     >     >
>     >     > > Dear all,
>     >     > > We'd like to put these patches as minimal as possible
>     >     > in order to
>     >     > > give more feedback.
>     >     > > Any comments, especially about the addon patches welcome.
>     >     > >
>     >     > >   - Louis
>     >     > >
>     >     > >
>     >     > >
>     >     > > -------------------------------------------------------
>     >     > > This sf.net email is sponsored by:ThinkGeek
>     >     > > Welcome to geek heaven.
>     >     > > http://thinkgeek.com/sf
>     >     > > _______________________________________________
>     >     > > Fault-injection-developer mailing list
>     >     > > Fau...@li...
>     >     > >
>     >     > https://lists.sourceforge.net/lists/listinfo/fault-injecti
>     >     > on-developer
>     >     >
>     >
>     >
>     > -------------------------------------------------------
>     > This SF.net email is sponsored by: Get the new Palm Tungsten T
>     > handheld. Power & Color in a compact size!
>     > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
>     > _______________________________________________
>     > Fault-injection-developer mailing list
>     > Fau...@li...
>     > https://lists.sourceforge.net/lists/listinfo/fault-injecti
> on-developer

RE: [Fault-injection-developer] RE: [PATCH 0/3] FITH patch agains t 2.5.47

[Zhuang, L. <lou...@in...>]

Yes, it's a good convention. There are two level directory just because of
my development hierarchy. Do you have some utilities which can reduce the
level of hierarchy of patch? :-)

    > -----Original Message-----
    > From: Lynch, Rusty 
    > Sent: Tuesday, November 26, 2002 8:38 AM
    > To: Zhuang, Louis; 'Rusty Lynch'; FITHML (E-mail)
    > Subject: RE: [Fault-injection-developer] RE: [PATCH 0/3] 
    > FITH patch against 2.5.47
    > 
    > 
    > Ok, thanks.  BTW, patches should normally apply from the 
    > kernel root, not one directory above.
    > 
    > In other words, if someone hands you over a patch for the 
    > kernel, you should be able to apply
    > the patch by:
    > 
    > $ cd YOURKERNELROOT
    > $ patch -p1 < PATH_TO_PATCH/somepatch.diff
    > 
    > 	-rusty
    > 
    > -----Original Message-----
    > From: Zhuang, Louis [mailto:lou...@in...]
    > Sent: Monday, November 25, 2002 4:22 PM
    > To: 'Rusty Lynch'; Zhuang, Louis; FITHML (E-mail)
    > Subject: [Fault-injection-developer] RE: [PATCH 0/3] FITH 
    > patch against 2.5.47
    > 
    > 
    > All patch files are included in fith-mini-8.tgz
    > http://prdownloads.sourceforge.net/fault-injection/fith-mi
    > ni-8.tgz?download
    > 
    >     > -----Original Message-----
    >     > From: Rusty Lynch [mailto:ru...@li...]
    >     > Sent: Tuesday, November 26, 2002 1:41 AM
    >     > To: Zhuang, Louis; FITHML (E-mail)
    >     > Subject: Re: [Fault-injection-developer] [PATCH 0/3] FITH 
    >     > patch against
    >     > 2.5.47
    >     > 
    >     > 
    >     > Louis, your emailer seems to have messed up the 
    > patch files by
    >     > adding new lines.  Could you put them up on a public server
    >     > (like maybe the sourceforge site) if you are having 
    > problems 
    >     > posting a patchfile that doesn't get corrupted?
    >     > 
    >     >     -rustyl
    >     > 
    >     > ----- Original Message ----- 
    >     > From: "Zhuang, Louis" <lou...@in...>
    >     > To: "FITHML (E-mail)" 
    > <fau...@so...>
    >     > Sent: Monday, November 25, 2002 2:02 AM
    >     > Subject: [Fault-injection-developer] [PATCH 0/3] FITH 
    >     > patch against 2.5.47
    >     > 
    >     > 
    >     > > Dear all,
    >     > > We'd like to put these patches as minimal as possible 
    >     > in order to
    >     > > give more feedback.
    >     > > Any comments, especially about the addon patches welcome.
    >     > > 
    >     > >   - Louis
    >     > > 
    >     > > 
    >     > > 
    >     > > -------------------------------------------------------
    >     > > This sf.net email is sponsored by:ThinkGeek
    >     > > Welcome to geek heaven.
    >     > > http://thinkgeek.com/sf
    >     > > _______________________________________________
    >     > > Fault-injection-developer mailing list
    >     > > Fau...@li...
    >     > > 
    >     > https://lists.sourceforge.net/lists/listinfo/fault-injecti
    >     > on-developer
    >     > 
    > 
    > 
    > -------------------------------------------------------
    > This SF.net email is sponsored by: Get the new Palm Tungsten T 
    > handheld. Power & Color in a compact size! 
    > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
    > _______________________________________________
    > Fault-injection-developer mailing list
    > Fau...@li...
    > https://lists.sourceforge.net/lists/listinfo/fault-injecti
on-developer