From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25772 invoked by alias); 21 Sep 2005 20:56:31 -0000 Mailing-List: contact systemtap-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sources.redhat.com Received: (qmail 25608 invoked by uid 22791); 21 Sep 2005 20:56:18 -0000 Date: Wed, 21 Sep 2005 20:56:00 -0000 From: "Frank Ch. Eigler" To: Richard J Moore Cc: systemtap@sources.redhat.com Subject: Re: next steps Message-ID: <20050921205610.GB3989@redhat.com> References: <20050920155034.GA25619@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-SW-Source: 2005-q3/txt/msg00567.txt.bz2 Hi - > Frank, under improving kprobes I would add: Thanks for the suggestions. > 1) dprobes or a scalable mechanism for performance tracing [...] Could you elaborate on what exactly "scalable ... tracing" refers to, and how you believe we're short of this? > 2) watchpoint probes if these aren't already there. [...] This is already tracked by bug #1324. A prerequisite is a debug register management API in the kernel. > 3) add back the ability to place probes in a code location before > the module is loaded. [...] We used to have this capability for > kernel modules. It relied on patches in insmod. Clearly this is > useful especially when wanting to capture initialization module > problems. Sounds useful, especially if it can be accomplished without much or any patching of generic kernel or kernel-utils code. Might the register_module_notifier() hook be sufficient for this? It's worth creating a bugzilla item for this. Bug #1145 is a prerequisite. > 4) Finally I'd request that we re-instate the SysRq function to > disable all probes instantly. [...] Please create a bugzilla item. __sysrq_put_key_op is probably suitable, as long as a handler doesn't try to do much anything fancy. Is it safe to instantly remove all kprobes at an arbitrary moment? > Apart from 1) all of these are simple modification for which the > code has all ready been written. These are good, though was intending to list the *larger* missing chunks: leaps of usefulness that would excite ordinary developers, not just kernel hackers. - FChE