From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22541 invoked by alias); 23 Dec 2008 00:33:44 -0000 Received: (qmail 22528 invoked by uid 22791); 23 Dec 2008 00:33:43 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from BISCAYNE-ONE-STATION.MIT.EDU (HELO biscayne-one-station.mit.edu) (18.7.7.80) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 23 Dec 2008 00:33:01 +0000 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id mBN0VxlQ007477; Mon, 22 Dec 2008 19:32:09 -0500 (EST) Received: from closure.thunk.org (c-98-216-98-217.hsd1.ma.comcast.net [98.216.98.217]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id mBN0Vup1026142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Dec 2008 19:31:57 -0500 (EST) Received: from tytso by closure.thunk.org with local (Exim 4.69) (envelope-from ) id 1LEvBk-0002Lg-O7; Mon, 22 Dec 2008 19:31:56 -0500 Date: Tue, 23 Dec 2008 00:44:00 -0000 From: Theodore Tso To: Masami Hiramatsu Cc: "Frank Ch. Eigler" , systemtap@sources.redhat.com Subject: Re: Discussion at Linux Foundation Japan Symposium Message-ID: <20081223003156.GN23723@mit.edu> References: <20081221003831.GG24081@redhat.com> <20081222181921.GH23723@mit.edu> <20081222203747.GA4195@redhat.com> <20081222223741.GM23723@mit.edu> <495023F3.2010508@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <495023F3.2010508@redhat.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Scanned-By: MIMEDefang 2.42 X-Spam-Score: 0.00 X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2008-q4/txt/msg00631.txt.bz2 On Mon, Dec 22, 2008 at 06:34:11PM -0500, Masami Hiramatsu wrote: > > Hmm, why would you think all or nothing? > > I agreed with your opinion that the kernel compilation time longer > if we configure more drivers compiling as modules. > > However, even if you build all required modules into the kernel, > you can still enable module support. So, I think it's not an issue. Yes, that's what I was talking about; my apologies for not being clear. So what I do when I want to use debuginfo is I build a single reduced-functionality kernel, with only device drivers I need built into the kernel, but I allow modules because SystemTap requires them. My suggestion was *documenting* this in the Wiki to make it clear that (a) debuginfo sucks and terribly bloats with lots of modules, and (b) developers who want to use SystemTap with debuginfo would be well advised to avoid using large numbers of modules. This is the kind of usability issue that SystemTap is badly lacking. Also, if you want to advertise using line-by-line probes as a SystemTap feature, you might want to suggest a kernel patch that disables gcc optimizations such that probes have a half-way decent chance of actually working. Yes it violates the SystemTap religion about never needing to recompile the kernel; but it recognizes the reality that the gcc toolchain has incredibly sucky debuginfo that doesn't take into account CSE, function reordering, and inlining of static functions. > Hm, perhaps, we should support an option or environment variable to > specify (several) path of Modules.marker. After fixing that path, we can > deprecate the option. There are only a few places where it can go; one is /boot/Module.marker-; another is /lib/modules//Module.markers. The last place is /lib/modules//build/Module.marker . -Ted