Thread: RE: [Fault-injection-developer] Couple of issues downloading and building the FITH source code
Status: Alpha
Brought to you by:
rustyl
Menu
▾
▴
fault-injection-developer
|
From: Zhuang, L. <lou...@in...> - 2002-10-22 02:56:53
|
I agree totally. We'll change README and INSTALL against stock kernel
2.4/2.5.
> -----Original Message-----
> From: Rob Rhoads [mailto:err...@li...]
> Sent: Tuesday, October 22, 2002 10:53 AM
> To: Zhuang, Louis
> Cc: fau...@li...;
> Perez-Gonzalez, Inaky; 'Rob Rhoads'; Wang, Frank
> Subject: RE: [Fault-injection-developer] Couple of issues
> downloading and building the FITH source code
>
>
> On Mon, 2002-10-21 at 19:27, Zhuang, Louis wrote:
> > Thanks Rob for his push! :)
> > We've made FITH conformable to Red hat 8.0. Now, it is
> conformable to ISO
> > C99, aclocal 1.6, autoconf 2.53, automake 1.6. But,
> kernel with Red hat 8.0
> > is not suitable for compiling and running FITH because
> DProbes and some
> > symbol exports are needed. The CGL precompiled kernel
> is most suitable for
> > that. :)
> http://builds.developer.osdl.org/index.php?ver=v1_0&type=stable
> >
> > Louis Zhuang, SW Engineer, Intel Corporation.
> > My opinions are my own and NEVER the opinions of Intel
> Corporation.
>
> Sorry Louis, but if we want this to be a useful SF
> project & one that we
> can announce on the LKML, we've got to provide the patches and
> instructions for someone to take a stock 2.4.x or 2.5.x
> kernel and get
> it working for use with FIFTH. I would further argue that
> 2.5.x is more
> important than 2.4.x, at least to the kernel developer community.
>
> Look at this way, someone on LKML has no idea what CGLE
> is, let alone
> TLT. You need to assume your intended audience only knows
> about the
> stock kernel sources on kernel.org.
>
> -RobR
>
|
|
From: Zhuang, L. <lou...@in...> - 2002-10-22 03:03:17
|
FITH has nothing to do with CGLE indeed except for some reference to
hardened driver spec. :-) We'll eliminate all references for CGLE in
documents.
> -----Original Message-----
> From: Zhuang, Louis
> Sent: Tuesday, October 22, 2002 10:55 AM
> To: 'Rob Rhoads'; Zhuang, Louis
> Cc: fau...@li...;
> Perez-Gonzalez, Inaky; Wang, Frank
> Subject: RE: [Fault-injection-developer] Couple of issues
> downloading and building the FITH source code
>
>
> I agree totally. We'll change README and INSTALL against
> stock kernel 2.4/2.5.
>
> > -----Original Message-----
> > From: Rob Rhoads [mailto:err...@li...]
> > Sent: Tuesday, October 22, 2002 10:53 AM
> > To: Zhuang, Louis
> > Cc: fau...@li...;
> > Perez-Gonzalez, Inaky; 'Rob Rhoads'; Wang, Frank
> > Subject: RE: [Fault-injection-developer] Couple of issues
> > downloading and building the FITH source code
> >
> >
> > On Mon, 2002-10-21 at 19:27, Zhuang, Louis wrote:
> > > Thanks Rob for his push! :)
> > > We've made FITH conformable to Red hat 8.0. Now, it is
> > conformable to ISO
> > > C99, aclocal 1.6, autoconf 2.53, automake 1.6. But,
> > kernel with Red hat 8.0
> > > is not suitable for compiling and running FITH because
> > DProbes and some
> > > symbol exports are needed. The CGL precompiled kernel
> > is most suitable for
> > > that. :)
> >
> http://builds.developer.osdl.org/index.php?ver=v1_0&type=stable
> > >
> > > Louis Zhuang, SW Engineer, Intel Corporation.
> > > My opinions are my own and NEVER the opinions of Intel
> > Corporation.
> >
> > Sorry Louis, but if we want this to be a useful SF
> > project & one that we
> > can announce on the LKML, we've got to provide the
> patches and
> > instructions for someone to take a stock 2.4.x or 2.5.x
> > kernel and get
> > it working for use with FIFTH. I would further argue that
> > 2.5.x is more
> > important than 2.4.x, at least to the kernel
> developer community.
> >
> > Look at this way, someone on LKML has no idea what CGLE
> > is, let alone
> > TLT. You need to assume your intended audience only knows
> > about the
> > stock kernel sources on kernel.org.
> >
> > -RobR
> >
>
|
|
From: Rob R. <err...@li...> - 2002-10-22 03:44:55
|
On Mon, 2002-10-21 at 20:00, Zhuang, Louis wrote: > FITH has nothing to do with CGLE indeed except for some reference to > hardened driver spec. :-) We'll eliminate all references for CGLE in > documents. Hardened Driver spec? What's that? I claim no knowledge of that dreaded beast! :-) *ouch!* -- Rob Rhoads mailto:err...@li... Telecom Software Platforms office: 503-677-5498 Intel Communications Group <disclaimer value="pointless"> This email message solely contains my own personal views, and not necessarily those of my employer. </disclaimer> |
|
From: Zhuang, L. <lou...@in...> - 2002-10-22 03:04:27
|
It is first time for me to use plain text format in outlook, so... pardon me
:-)
> -----Original Message-----
> From: Rob Rhoads [mailto:err...@li...]
> Sent: Tuesday, October 22, 2002 10:59 AM
> To: Zhuang, Louis
> Cc: fau...@li...;
> Perez-Gonzalez, Inaky; Wang, Frank
> Subject: RE: [Fault-injection-developer] Couple of issues
> downloading and building the FITH source code
>
>
> Louis, not that I want to hammer you some more (better me
> though, than
> someone on the LKML -- I learned the hard way *ouch!*) but ...
>
> When you respond to someone's e-mail with in-line
> comments, you need to
> clearly mark your response or the original text w/
> something. So the
> reader can distinguish what you are saying and what the
> original poster
> said.
>
> Needless to say, I had a very difficult time
> distinguishing my comments
> from yours in your response below.
>
> -RobR
>
> On Mon, 2002-10-21 at 19:37, Zhuang, Louis wrote:
> > OK, got the source, and I'm now going through the build
> steps and
> > reading the documentation. In short, its way too TLT
> specific for a
> > general announcement on the LKML.
> >
> > I haven't attempted to build it yet, but this is what I
> see so far that
> > needs to be fixed before the project is announced (in
> any form) to the
> > LKML:
> >
> > 1. Remove all mention & dependencies on TLT,
> carrierlinux, etc. from
> > everything. The README file is full of TLT &
> carrierlinux 'isms. If this
> > is going to be posted on LKML, the instructions and
> code had better work
> > on a stock kernel by applying relevant kernel patches.
> >
> > If you rely on the TLT or CGLE kernel no one on the
> LKML, outside of
> > OSDL developers, will take a second look at it.
> >
> > The instructions need to be written so anyone can take
> a stock kernel
> > apply the relevant patches and make it work. For
> example, dprobes is
> > required, but the instruction don't clearly state that
> you need to apply
> > the patch to the stock kernel sources.
> > We'll fix these issues. thx
> >
> >
> > 2. You need to break-out the required kernel patches
> from the user-space
> > components. Separate source tarballs & separate
> instructions, might be
> > one way to do it. Right now it's confusing from reading
> the README what
> > exactly you need to do in order to get going. At the
> very least you need
> > to build a new kernel with the right patches applied,
> and then make the
> > user-space components.
> > Good point! Fixing... :)
> >
> >
> > 3. A lot of the info that's in the README should be in
> the INSTALL file.
> > The INSTALL file has good info, but is pretty much
> generic to running
> > ./configure.
> > INSTALL file is generated by 'automake' automatically.
> We'd like put all
> > information in README. If you think it is an issue,
> we'll change some
> > installation-relative information into INSTALL.
> >
> >
> > 4. To get the best exposure on the LKML, it would be
> better to also
> > provide instructions on how to make it work on the 2.5
> kernel. I would
> > think that would be just a matter of getting the
> patches working on the
> > 2.5 kernel. This could be any area where we ask for
> community help in
> > making it work on 2.5. This shouldn't stop us from
> announcing, but after
> > listening to Greg K-H yesterday and my past experience
> this is the
> > conclusion I come to.
> > We all have little experience in 2.5, but we'll try to
> merge our things into
> > 2.5. Maybe we need some help from other kernel guys :)
> >
> >
> > More comments to follow...stay tuned...
> >
> > -RobR
> >
> >
>
> --
> Rob Rhoads mailto:err...@li...
> Telecom Software Platforms office: 503-677-5498
> Intel Communications Group
>
> <disclaimer value="pointless">
> This email message solely contains my own personal views,
> and not necessarily those of my employer.
> </disclaimer>
>
|
|
From: Zhuang, L. <lou...@in...> - 2002-10-22 03:10:27
|
Just for fun. I call this project FITH (Fault Injection Test Harness). I
wonder what FIFTH stands for? :-)
> -----Original Message-----
> From: Rob Rhoads [mailto:err...@li...]
> Sent: Tuesday, October 22, 2002 11:05 AM
> To: Zhuang, Louis
> Cc: fau...@li...;
> Perez-Gonzalez, Inaky; Wang, Frank
> Subject: RE: [Fault-injection-developer] Couple of issues
> downloading and building the FITH source code
>
>
> On Mon, 2002-10-21 at 19:54, Zhuang, Louis wrote:
> > I agree totally. We'll change README and INSTALL
> against stock kernel
> > 2.4/2.5.
> >
> Just to clarify, I never expected FIFTH to work on the kernel that
> shipped with RH 8.0. Just that I could build both a stock
> kernel w/
> relevant patches, and the FIFTH user-space components on a RH 8.0
> system.
>
> So it sounds like we are then in agreement. Cool. ;-)
>
> --
> Rob Rhoads mailto:err...@li...
> Telecom Software Platforms office: 503-677-5498
> Intel Communications Group
>
> <disclaimer value="pointless">
> This email message solely contains my own personal views,
> and not necessarily those of my employer.
> </disclaimer>
>
|
|
From: Rob R. <err...@li...> - 2002-10-22 03:19:11
|
On Mon, 2002-10-21 at 20:08, Zhuang, Louis wrote: > Just for fun. I call this project FITH (Fault Injection Test Harness). I > wonder what FIFTH stands for? :-) > It could mean one of the following: a) fifth of gin b) fifth of vodka c) Or for O.J. Simpson, I take the fifth... Just kidding... :-) -- Rob Rhoads mailto:err...@li... Telecom Software Platforms office: 503-677-5498 Intel Communications Group <disclaimer value="pointless"> This email message solely contains my own personal views, and not necessarily those of my employer. </disclaimer> |
|
From: Wang, F. <fra...@in...> - 2002-10-22 03:33:54
|
Good comments from Rob! -----Original Message----- From: Rob Rhoads [mailto:err...@li...] Sent: 2002?10?22? 10:59 To: Zhuang, Louis Cc: fau...@li...; Perez-Gonzalez, Inaky; Wang, Frank Subject: RE: [Fault-injection-developer] Couple of issues downloading and building the FITH source code Louis, not that I want to hammer you some more (better me though, than someone on the LKML -- I learned the hard way *ouch!*) but ... When you respond to someone's e-mail with in-line comments, you need to clearly mark your response or the original text w/ something. So the reader can distinguish what you are saying and what the original poster said. Needless to say, I had a very difficult time distinguishing my comments from yours in your response below. -RobR On Mon, 2002-10-21 at 19:37, Zhuang, Louis wrote: > OK, got the source, and I'm now going through the build steps and > reading the documentation. In short, its way too TLT specific for a > general announcement on the LKML. > > I haven't attempted to build it yet, but this is what I see so far that > needs to be fixed before the project is announced (in any form) to the > LKML: > > 1. Remove all mention & dependencies on TLT, carrierlinux, etc. from > everything. The README file is full of TLT & carrierlinux 'isms. If this > is going to be posted on LKML, the instructions and code had better work > on a stock kernel by applying relevant kernel patches. > > If you rely on the TLT or CGLE kernel no one on the LKML, outside of > OSDL developers, will take a second look at it. > > The instructions need to be written so anyone can take a stock kernel > apply the relevant patches and make it work. For example, dprobes is > required, but the instruction don't clearly state that you need to apply > the patch to the stock kernel sources. > We'll fix these issues. thx > > > 2. You need to break-out the required kernel patches from the user-space > components. Separate source tarballs & separate instructions, might be > one way to do it. Right now it's confusing from reading the README what > exactly you need to do in order to get going. At the very least you need > to build a new kernel with the right patches applied, and then make the > user-space components. > Good point! Fixing... :) > > > 3. A lot of the info that's in the README should be in the INSTALL file. > The INSTALL file has good info, but is pretty much generic to running > ./configure. > INSTALL file is generated by 'automake' automatically. We'd like put all > information in README. If you think it is an issue, we'll change some > installation-relative information into INSTALL. > > > 4. To get the best exposure on the LKML, it would be better to also > provide instructions on how to make it work on the 2.5 kernel. I would > think that would be just a matter of getting the patches working on the > 2.5 kernel. This could be any area where we ask for community help in > making it work on 2.5. This shouldn't stop us from announcing, but after > listening to Greg K-H yesterday and my past experience this is the > conclusion I come to. > We all have little experience in 2.5, but we'll try to merge our things into > 2.5. Maybe we need some help from other kernel guys :) > > > More comments to follow...stay tuned... > > -RobR > > -- Rob Rhoads mailto:err...@li... Telecom Software Platforms office: 503-677-5498 Intel Communications Group <disclaimer value="pointless"> This email message solely contains my own personal views, and not necessarily those of my employer. </disclaimer> |
|
From: Wang, S. <sta...@in...> - 2002-10-22 03:49:27
|
Hi, Rob I think the reason why we used a modified version insmod is that we = have not enough time to complete a FITH's insmod:) And we can write a insmod = when time permits. And we really want :) Thank, Stanley=20 -----Original Message----- From: Rob Rhoads [mailto:err...@li...] Sent: 2002=E5=B9=B410=E6=9C=8822=E6=97=A5 11:41 To: fau...@li... Cc: Zhuang, Louis; Perez-Gonzalez, Inaky; Wang, Frank Subject: RE: [Fault-injection-developer] Couple of issues downloading = and building the FITH source code On Mon, 2002-10-21 at 20:05, Rob Rhoads wrote: > On Mon, 2002-10-21 at 19:54, Zhuang, Louis wrote: > > I agree totally. We'll change README and INSTALL against stock = kernel > > 2.4/2.5.=20 Upon further reflection...just so I'm even more clear (sorry if you already knew this): At a minimum, break FITH out into 2 packages: 1. One for kernel patches, kernel modules, plus kernel related build instructions. 2. One for user-space components, plus build scripts (configure file) & instructions IOW don't package FITH up as a single tarball that contains both kernel and user-space components, and one big README for building both. Bundling them together just isn't a good idea from a Linux kernel developers perspective. Also, can you explain why we aren't modifying & using dprobes? Why are we instead using a modified version of insmod? With your current FITH implementation, can you inject faults in statically compiled/linked drivers or kernel code (e.g. not just kernel modules)?=20 I have concerns that using a modified insmod, won't fly with kernel developers. If dprobes isn't sufficient, why can't it be modified, so = we don't have to use a modified version of insmod. I may be drawing the wrong conclusion here, so don't change it until you explain it.=20 Anyone should feel free to jump-in in this discussion, if you disagree/agree or whatever. > >=20 > Just to clarify, I never expected FIFTH to work on the kernel that > shipped with RH 8.0. Just that I could build both a stock kernel w/ > relevant patches, and the FIFTH user-space components on a RH 8.0 > system.=20 >=20 > So it sounds like we are then in agreement. Cool. ;-) >=20 --=20 Rob Rhoads mailto:err...@li... Telecom Software Platforms office: 503-677-5498 Intel Communications Group <disclaimer value=3D"pointless"> This email message solely contains my own personal views,=20 and not necessarily those of my employer. </disclaimer> ------------------------------------------------------- This sf.net emial is sponsored by: Influence the future=20 of Java(TM) technology. Join the Java Community=20 Process(SM) (JCP(SM)) program now.=20 http://ad.doubleclick.net/clk;4699841;7576298;k?http://www.sun.com/javav= ote _______________________________________________ Fault-injection-developer mailing list Fau...@li... https://lists.sourceforge.net/lists/listinfo/fault-injection-developer |
|
From: Wang, S. <sta...@in...> - 2002-10-22 04:17:20
|
Hi, Rob Dprobes replaces the instruction in the specified addrees with "int3". We replace all "in/out". Thanks, Stanley -----Original Message----- From: Rob Rhoads [mailto:err...@li...] Sent: 2002=E5=B9=B410=E6=9C=8822=E6=97=A5 12:12 To: Wang, Stanley Cc: fau...@li... Subject: RE: [Fault-injection-developer] Couple of issues downloading = and building the FITH source code On Mon, 2002-10-21 at 21:07, Wang, Stanley wrote: > Hi Rob, > The modified version insmod's job is very simple:=20 > 1. finds out all "in_x/out_x" instruction in the tested module and replaces > them with "int3" > 2. redirect "ioremap" and "request_irq" to FITH's hook > What does dprobes do? =20 > These work can be done in kernel space with more difficulty :( > So we do it in user space (insmod). >=20 > Thanks, > Stanley >=20 --=20 Rob Rhoads mailto:err...@li... Telecom Software Platforms office: 503-677-5498 Intel Communications Group <disclaimer value=3D"pointless"> This email message solely contains my own personal views,=20 and not necessarily those of my employer. </disclaimer> |
|
From: Rob R. <err...@li...> - 2002-10-22 04:23:18
|
On Mon, 2002-10-21 at 21:15, Wang, Stanley wrote: > Hi, Rob > Dprobes replaces the instruction in the specified addrees with "int3". > We replace all "in/out". Why can't dprobes be modified/extended to do that? > > Thanks, > Stanley > -- Rob Rhoads mailto:err...@li... Telecom Software Platforms office: 503-677-5498 Intel Communications Group <disclaimer value="pointless"> This email message solely contains my own personal views, and not necessarily those of my employer. </disclaimer> |
|
From: Wang, S. <sta...@in...> - 2002-10-22 05:42:19
|
Hi Rob, I think it is what FITH did indeed.=20 Dprobes' fault injection mechanism causes that the faultset must be = updated after the driver was recompiled. FITH uses almost all hooks (GKHI) that Dprobes places in kernel, but = its faultset needn't to be updated after you=20 recompiled the driver. FITH is extending the Dprobes, doing something = better :) Stanley Wang=20 SW Engineer, Intel Corporation. Intel China Software Lab.=20 Tel: 021-52574545 ext. 1171=20 iNet: 8-752-1171=20 =20 Opinions expressed are those of the author and do not represent Intel Corporation -----Original Message----- From: Rob Rhoads [mailto:err...@li...] Sent: 2002=E5=B9=B410=E6=9C=8822=E6=97=A5 12:23 To: Wang, Stanley Cc: fau...@li...; ina...@in... Subject: RE: [Fault-injection-developer] Couple of issues downloading = and building the FITH source code On Mon, 2002-10-21 at 21:15, Wang, Stanley wrote: > Hi, Rob > Dprobes replaces the instruction in the specified addrees with = "int3". > We replace all "in/out". Why can't dprobes be modified/extended to do that? >=20 > Thanks, > Stanley >=20 --=20 Rob Rhoads mailto:err...@li... Telecom Software Platforms office: 503-677-5498 Intel Communications Group <disclaimer value=3D"pointless"> This email message solely contains my own personal views,=20 and not necessarily those of my employer. </disclaimer> |
|
From: Lynch, R. <rus...@in...> - 2002-10-22 18:23:23
|
I think we need to be a little more clear on the terms we are using. I think that when Rob refers to "extending dprobes", he means patching = dprobes to enable some additional features, not taking advantage of various = kernel hooks that the dprobes patch adds to the kernel. For example, a very small tweak to dprobes could enable an extra = instruction in the probe rpn files that allows arbitrary exit points to be called = from the rpn file. This could enable something like: 1. Some user space tool analysis a driver module and then and generates = a rpn file that would insert probe points for each of the in/out = operations where each probe point calls an exit function in a FITH loadable kernel module 2. Once the exit function in the FITH module has been called then the = rest of the design for FITH would be the same -rusty=20 -----Original Message----- From: Wang, Stanley [mailto:sta...@in...] Sent: Monday, October 21, 2002 10:40 PM To: 'Rob Rhoads' Cc: fau...@li...; Perez-Gonzalez, Inaky Subject: RE: [Fault-injection-developer] Couple of issues downloading and building the FITH source code Hi Rob, I think it is what FITH did indeed.=20 Dprobes' fault injection mechanism causes that the faultset must be = updated after the driver was recompiled. FITH uses almost all hooks (GKHI) that Dprobes places in kernel, but = its faultset needn't to be updated after you=20 recompiled the driver. FITH is extending the Dprobes, doing something = better :) Stanley Wang=20 SW Engineer, Intel Corporation. Intel China Software Lab.=20 Tel: 021-52574545 ext. 1171=20 iNet: 8-752-1171=20 =20 Opinions expressed are those of the author and do not represent Intel Corporation -----Original Message----- From: Rob Rhoads [mailto:err...@li...] Sent: 2002=E5=B9=B410=E6=9C=8822=E6=97=A5 12:23 To: Wang, Stanley Cc: fau...@li...; ina...@in... Subject: RE: [Fault-injection-developer] Couple of issues downloading = and building the FITH source code On Mon, 2002-10-21 at 21:15, Wang, Stanley wrote: > Hi, Rob > Dprobes replaces the instruction in the specified addrees with = "int3". > We replace all "in/out". Why can't dprobes be modified/extended to do that? >=20 > Thanks, > Stanley >=20 --=20 Rob Rhoads mailto:err...@li... Telecom Software Platforms office: 503-677-5498 Intel Communications Group <disclaimer value=3D"pointless"> This email message solely contains my own personal views,=20 and not necessarily those of my employer. </disclaimer> ------------------------------------------------------- This sf.net emial is sponsored by: Influence the future of=20 Java(TM) technology. Join the Java Community Process(SM) (JCP(SM))=20 program now. http://ad.doubleclick.net/clk;4699841;7576301;v? http://www.sun.com/javavote _______________________________________________ Fault-injection-developer mailing list Fau...@li... https://lists.sourceforge.net/lists/listinfo/fault-injection-developer |
|
From: Rob R. <err...@li...> - 2002-10-22 19:00:21
|
On Tue, 2002-10-22 at 11:22, Lynch, Rusty wrote: > I think we need to be a little more clear on the terms we are using. I > think that when Rob refers to "extending dprobes", he means patching dprobes > to enable some additional features, not taking advantage of various kernel > hooks that the dprobes patch adds to the kernel. > > For example, a very small tweak to dprobes could enable an extra instruction > in the probe rpn files that allows arbitrary exit points to be called from > the rpn file. This could enable something like: > 1. Some user space tool analysis a driver module and then and generates a > rpn file that would insert probe points for each of the in/out operations > where each probe point calls an exit function in a FITH loadable kernel > module > 2. Once the exit function in the FITH module has been called then the rest > of the design for FITH would be the same > > -rusty > Yes, that was similar to what I was thinking. It would be nice though, if the user-space tool could also work on more than just modules though. Does dprobes allow you to insert anywhere in the kernel (i.e. not just kernel modules)? It would be nice to be able to insert probe points for compiled in drivers as well. This could be tricky, but you could use the tool to run through the kernel System.map and vmlinux (uncompressed compiled kernel ELF file) to figure out where to insert probe points in the rpn file for a running kernel. Just a thought... -- Rob Rhoads mailto:err...@li... Telecom Software Platforms office: 503-677-5498 Intel Communications Group <disclaimer value="pointless"> This email message solely contains my own personal views, and not necessarily those of my employer. </disclaimer> |
|
From: Lynch, R. <rus...@in...> - 2002-10-22 19:05:34
|
Yes, dprobes allows probe points to be inserted into a running kernel. There are a couple of exceptions that are artifacts of how dprobes works... I believe one is that you can not insert a probe in the page fault handler (or was it the exception handler). -rusty -----Original Message----- From: Rob Rhoads [mailto:err...@li...] Sent: Tuesday, October 22, 2002 12:00 PM To: Lynch, Rusty Cc: Wang, Stanley; fau...@li...; Perez-Gonzalez, Inaky Subject: RE: [Fault-injection-developer] Couple of issues downloading and building the FITH source code On Tue, 2002-10-22 at 11:22, Lynch, Rusty wrote: > I think we need to be a little more clear on the terms we are using. I > think that when Rob refers to "extending dprobes", he means patching dprobes > to enable some additional features, not taking advantage of various kernel > hooks that the dprobes patch adds to the kernel. > > For example, a very small tweak to dprobes could enable an extra instruction > in the probe rpn files that allows arbitrary exit points to be called from > the rpn file. This could enable something like: > 1. Some user space tool analysis a driver module and then and generates a > rpn file that would insert probe points for each of the in/out operations > where each probe point calls an exit function in a FITH loadable kernel > module > 2. Once the exit function in the FITH module has been called then the rest > of the design for FITH would be the same > > -rusty > Yes, that was similar to what I was thinking. It would be nice though, if the user-space tool could also work on more than just modules though. Does dprobes allow you to insert anywhere in the kernel (i.e. not just kernel modules)? It would be nice to be able to insert probe points for compiled in drivers as well. This could be tricky, but you could use the tool to run through the kernel System.map and vmlinux (uncompressed compiled kernel ELF file) to figure out where to insert probe points in the rpn file for a running kernel. Just a thought... -- Rob Rhoads mailto:err...@li... Telecom Software Platforms office: 503-677-5498 Intel Communications Group <disclaimer value="pointless"> This email message solely contains my own personal views, and not necessarily those of my employer. </disclaimer> |
|
From: Rob R. <err...@li...> - 2002-10-22 03:05:22
|
On Mon, 2002-10-21 at 19:54, Zhuang, Louis wrote: > I agree totally. We'll change README and INSTALL against stock kernel > 2.4/2.5. > Just to clarify, I never expected FIFTH to work on the kernel that shipped with RH 8.0. Just that I could build both a stock kernel w/ relevant patches, and the FIFTH user-space components on a RH 8.0 system. So it sounds like we are then in agreement. Cool. ;-) -- Rob Rhoads mailto:err...@li... Telecom Software Platforms office: 503-677-5498 Intel Communications Group <disclaimer value="pointless"> This email message solely contains my own personal views, and not necessarily those of my employer. </disclaimer> |
|
From: Rob R. <err...@li...> - 2002-10-22 03:41:07
|
On Mon, 2002-10-21 at 20:05, Rob Rhoads wrote: > On Mon, 2002-10-21 at 19:54, Zhuang, Louis wrote: > > I agree totally. We'll change README and INSTALL against stock kernel > > 2.4/2.5. Upon further reflection...just so I'm even more clear (sorry if you already knew this): At a minimum, break FITH out into 2 packages: 1. One for kernel patches, kernel modules, plus kernel related build instructions. 2. One for user-space components, plus build scripts (configure file) & instructions IOW don't package FITH up as a single tarball that contains both kernel and user-space components, and one big README for building both. Bundling them together just isn't a good idea from a Linux kernel developers perspective. Also, can you explain why we aren't modifying & using dprobes? Why are we instead using a modified version of insmod? With your current FITH implementation, can you inject faults in statically compiled/linked drivers or kernel code (e.g. not just kernel modules)? I have concerns that using a modified insmod, won't fly with kernel developers. If dprobes isn't sufficient, why can't it be modified, so we don't have to use a modified version of insmod. I may be drawing the wrong conclusion here, so don't change it until you explain it. Anyone should feel free to jump-in in this discussion, if you disagree/agree or whatever. > > > Just to clarify, I never expected FIFTH to work on the kernel that > shipped with RH 8.0. Just that I could build both a stock kernel w/ > relevant patches, and the FIFTH user-space components on a RH 8.0 > system. > > So it sounds like we are then in agreement. Cool. ;-) > -- Rob Rhoads mailto:err...@li... Telecom Software Platforms office: 503-677-5498 Intel Communications Group <disclaimer value="pointless"> This email message solely contains my own personal views, and not necessarily those of my employer. </disclaimer> |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X