From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31798 invoked by alias); 22 Dec 2008 23:34:45 -0000 Received: (qmail 31791 invoked by uid 22791); 22 Dec 2008 23:34:45 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,KAM_MX,SPF_HELO_PASS,SPF_PASS X-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,KAM_MX,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 22 Dec 2008 23:34:10 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id mBMNY7Pe005100 for ; Mon, 22 Dec 2008 18:34:07 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id mBMNY60X030327 for ; Mon, 22 Dec 2008 18:34:06 -0500 Received: from [10.16.3.219] (dhcp-100-3-219.bos.redhat.com [10.16.3.219]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id mBMNY4qm017553; Mon, 22 Dec 2008 18:34:06 -0500 Message-ID: <495023F3.2010508@redhat.com> Date: Tue, 23 Dec 2008 00:34:00 -0000 From: Masami Hiramatsu User-Agent: Thunderbird 2.0.0.18 (X11/20081119) MIME-Version: 1.0 To: Theodore Tso CC: "Frank Ch. Eigler" , systemtap@sources.redhat.com Subject: Re: Discussion at Linux Foundation Japan Symposium References: <20081221003831.GG24081@redhat.com> <20081222181921.GH23723@mit.edu> <20081222203747.GA4195@redhat.com> <20081222223741.GM23723@mit.edu> In-Reply-To: <20081222223741.GM23723@mit.edu> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 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/msg00630.txt.bz2 Theodore Tso wrote: >>> This means no modules, since debuginfo is a disaster with modules >>> (so helping people create configurations that don't use modules >>> would be helpful); >> Please elaborate what you mean. Why systemtap is forced to use >> (create) modules at all has been explained often. > > What I mean is that if you build a kernel with a large number of > modules, the bloat of systemtap becomes disastrous. With a > distro-style kernel, the compilation time literally goes up by a > factor of 4-5 or so, and the disk space utilization goes up by a > factor of 8 or so. It's not so bad if you only the device drivers you > into a single kernel, and not create any unneeded modules. This is > often not the common way at least some kernel developers build > systems, since (a) modules make it easier to load and unload > subsystems without rebooting, and this can shorten the > compile-edit-debug cycle times, and (b) some kernel developers want to > be sure they know whether any infrastructural changes they might cause > some random device driver or other random subsystem to break. > Unfortunately, building a distro-style kernel is a horrible disaster > with debuginfo enabled, and so warning people off about this > particular issue would be helpful. 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. >> Sure, upstream changes in the location of Modules.marker are something >> we can easily adapt to. Are you aware of a current problem with that? >> On the other hand, we plan to work on also connecting straight to >> tracepoints, and to various slices of ftrace, for which a file such >> the troubled-history Modules.markers will not be necessary. > > Only that "make install" or "make modules_install" doesn't currently > install Modules.marker anywhere useful. And there is no standard > location for where Modules.marker will be installed given current > distribution packaging tools. Attention to consumability of SystemTap > given a variety of different kernel installation schemes is a Really > Good Idea. It's not just Fedora RPM-style macros and "make install". > There are many other ways that people create and install kernels; and > this kind of attention to detail will stop people from getting > Frustrated with SystemTap. 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. Thank you, -- Masami Hiramatsu Software Engineer Hitachi Computer Products (America) Inc. Software Solutions Division e-mail: mhiramat@redhat.com