FW: [Fault-injection-developer] RFC: Interceptor for PIO

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

> -----Original Message-----
> From: Wang, Stanley=20
> Sent: 2002=E5=B9=B412=E6=9C=8819=E6=97=A5 8:57
> To: Lynch, Rusty
> Subject: RE: [Fault-injection-developer] RFC: Interceptor for PIO
>=20
>=20
> Please see my comment.
>=20
> > -----Original Message-----
> > From: Lynch, Rusty=20
> > Sent: 2002=E5=B9=B412=E6=9C=8819=E6=97=A5 2:12
> > To: Lynch, Rusty; Wang, Stanley;=20
> > 'fau...@li...'
> > Subject: RE: [Fault-injection-developer] RFC: Interceptor for PIO
> >=20
> >=20
> > Now that I think about this some more, it would make more=20
> > sense to first=20
> Sure, I agree with you :)
>=20
> > implement a PIO interceptor that uses kwatch, and just have=20
> > it fail if=20
> > to register a new trigger if the number of watchpoints are =
exceeded.
> >=20
> > After we have that in place and we are trying to use it,=20
> then it will
> > become clear if the watchpoint limitation is too restrictive.=20
> >  From the
> > fault injection core's perspective, both implementations=20
> > would look the
> > same.
> Not true. The debug exception is a trap. Hence we could get=20
> control only
> AFTER the watched address was accessed. And we couldn't injection
> a write fault into the PIO access. So the implementation=20
> based on Kprobes
> is mandatory.
>=20
> -Stan
>=20
> >=20
> >     -rusty
> >=20
> > > -----Original Message-----
> > > From: Lynch, Rusty [mailto:rus...@in...]
> > > Sent: Wednesday, December 18, 2002 9:44 AM
> > > To: Wang, Stanley;=20
> 'fau...@li...'
> > > Subject: RE: [Fault-injection-developer] RFC: Interceptor for PIO
> > >=20
> > >=20
> > >=20
> > > > Stanley wrote:=20
> > > > pros:
> > > > 1. As many breakpoints as you wish :)
> > > >=20
> > > > cons:
> > > > 1. A user mode utility is needed for finding all IO related=20
> > > > instructions
> > > > out.
> > > > 2. And we need to export the symbol "modules" for locating=20
> > > the wanted
> > > > instructions.
> > > >=20
> > >=20
> > > Have you looked into the new kernel module loader?  We=20
> might be able
> > > to take advantage of some of the extra functionality it=20
> presents (at
> > > least for loadable modules).
> > >=20
> > >     --rusty
> > >=20
> > >=20
> > > -------------------------------------------------------
> > > This SF.NET email is sponsored by: Order your Holiday Geek=20
> > > Presents Now!
> > > Green Lasers, Hip Geek T-Shirts, Remote Control Tanks,=20
> > > Caffeinated Soap,
> > > MP3 Players,  XBox Games,  Flying Saucers,  WebCams,  Smart =
Putty.
> > > T H I N K G E E K . C O M       http://www.thinkgeek.com/sf/
> > > _______________________________________________
> > > Fault-injection-developer mailing list
> > > Fau...@li...
> > >=20
> =
https://lists.sourceforge.net/lists/listinfo/fault-injection-developer
> >=20
>=20