RE: [Fault-injection-developer] We need to get up to speed with t he kprobes proposal on lkml

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

I think we would have to have a pretty damn good reason for adding more 
namespace pollution to the kernel.  There has got to be a better way to 
do this.

	-rusty

-----Original Message-----
From: Zhuang, Louis 
Sent: Wednesday, October 23, 2002 6:06 PM
To: 'Rob Rhoads'; Lynch, Rusty
Cc: fau...@li...
Subject: RE: [Fault-injection-developer] We need to get up to speed with
the kprobes proposal on lkml


    > -----Original Message-----
    > From: Rob Rhoads [mailto:err...@li...]
    > Sent: Thursday, October 24, 2002 2:03 AM
    > To: Lynch, Rusty
    > Cc: fau...@li...
    > Subject: Re: [Fault-injection-developer] We need to get 
    > up to speed with the kprobes proposal on lkml
    > 
    > 
    > On Wed, 2002-10-23 at 10:49, Lynch, Rusty wrote:
    > > The dprobes guys are working with a strategy where all 
    > of the infrastructure
    > > for attaching probe points, kernel hooks, and dealing 
    > with architecture
    > > specific debug registers is covered by a kprobes patch, 
    > and then dprobes
    > > would just be one of many consumers of kprobes.
    > > 
    > > The debates are happening right now, with kprobes 
    > patches posted for 2.5.44.
    > > We need to get a good understanding of these patches 
    > since I suspect we 
    > > could at least be a consumer of kprobes (if not of 
    > dprobes which will depend
    > > on kprobes.)
    > 
    > Yeah, that was my thinking as well. Which is why I forwarded that
    > previous email from the lkml on kprobes vs. dprobes.
    > 
Yes, FITH is a customer of kprobes indeed. There is little FITH patch
against kernel. In fact, the patch only exports two symbols of kernel
(irq_desc and mmu_cr4_features). According to Rob's comments, should we only
discuss following patch in kernel mail list, not FITH itself? How can we
find a altisonant reason to have Linus applied this aptch? ;-p


--- ksyms.c.old Tue May 28 10:39:32 2002
+++ ksyms.c     Tue May 28 10:41:20 2002
@@ -48,6 +48,7 @@
 #include <linux/completion.h>
 #include <linux/seq_file.h>
 #include <asm/checksum.h>
+#include <linux/irq.h>

 #if defined(CONFIG_PROC_FS)
 #include <linux/proc_fs.h>
@@ -357,6 +358,8 @@
 #if !defined(CONFIG_ARCH_S390)
 EXPORT_SYMBOL(irq_stat);       /* No separate irq_stat for s390, it is part
of PSA */
 #endif
+EXPORT_SYMBOL(irq_desc);
+EXPORT_SYMBOL(mmu_cr4_features);

 /* waitqueue handling */
 EXPORT_SYMBOL(add_wait_queue);



    > > 
    > > Also, depending on how successful dprobes is at this 
    > approach, we could 
    > > model our involvement with the kernel after dprobes.
    > > 
    > > 	-rusty
    > > 
    > 
    > -- 
    > Rob Rhoads                     mailto:err...@li...
    > Telecom Software Platforms     office: 503-677-5498
    > Intel Communications Group
    > 
    > <disclaimer value="pointless">
    > This email message solely contains my own personal views, 
    > and not necessarily those of my employer.
    > </disclaimer>
    > 
    > 
    > 
    > -------------------------------------------------------
    > This sf.net email is sponsored by: Influence the future 
    > of Java(TM) technology. Join the Java Community 
    > Process(SM) (JCP(SM)) program now. 
    > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
    > 
    > _______________________________________________
    > Fault-injection-developer mailing list
    > Fau...@li...
    > https://lists.sourceforge.net/lists/listinfo/fault-injecti
on-developer