From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933327Ab1KHVPt (ORCPT ); Tue, 8 Nov 2011 16:15:49 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48569 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751661Ab1KHVPr (ORCPT ); Tue, 8 Nov 2011 16:15:47 -0500 Date: Tue, 8 Nov 2011 22:15:01 +0100 (CET) From: John Kacur X-X-Sender: jkacur@localhost6.localdomain6 To: "Ted Ts'o" , Ingo Molnar , Anthony Liguori , Pekka Enberg , Vince Weaver , Avi Kivity , "kvm@vger.kernel.org list" , "linux-kernel@vger.kernel.org List" , qemu-devel Developers , Alexander Graf , Blue Swirl , =?ISO-8859-15?Q?Am=E9rico_Wang?= , Linus Torvalds , Thomas Gleixner , Peter Zijlstra , Arnaldo Carvalho de Melo Subject: Re: [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/ In-Reply-To: <20111108163331.GJ24234@thunk.org> Message-ID: References: <20111107203255.GF24234@thunk.org> <4EB85969.2010108@codemonkey.ws> <12F471C8-2CF3-4CD7-B417-C8CC898669E6@mit.edu> <20111108093225.GB32533@elte.hu> <20111108125509.GB1022@elte.hu> <20111108163331.GJ24234@thunk.org> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 8 Nov 2011, Ted Ts'o wrote: > On Tue, Nov 08, 2011 at 01:55:09PM +0100, Ingo Molnar wrote: > > I guess you can do well with a split project as well - my main claim > > is that good compatibility comes *naturally* with integration. > > Here I have to disagree; my main worry is that integration makes it > *naturally* easy for people to skip the hard work needed to keep a > stable kernel/userspace interface. > > The other worry which I've mentioned, but which I haven't seen > addressed, is that the even if you can use a perf from a newer kernel > with an older kernel, this causes distributions a huge amount of pain, > since they have to package two different kernel source packages, and > only compile perf from the newer kernel source package. This leads to > all sorts of confusion from a distribution packaging point of view. > > For example, assume that RHEL 5, which is using 2.6.32 or something > like that, wants to use a newer e2fsck that does a better job fixing > file system corruptions. If it were bundled with the kernel, then > they would have to package up the v3.1 kernel sources, and have a > source RPM that isn't used for building kernel sources, but just to > build a newer version of e2fsck. Fortunately, they don't have to do > that. They just pull down a newer version of e2fsprogs, and package, > build, test, and ship that. > > In addition, suppose Red Hat ships a security bug fix which means a > new kernel-image RPM has to be shipped. Does that mean that Red Hat > has to ship new binary RPM's for any and all tools/* programs that > they have packaged as separate RPM's? Or should installing a new > kernel RPM also imply dropping new binaries in /usr/bin/perf, et. al? > There are all sorts of packaging questions that are raised > integration, and from where I sit I don't think they've been > adequately solved yet. > This in practice is not a big deal. There are many approaches for how the RPM can be built, but basically getting the perf source is just a matter of make perf-tar-src-pkg or friends such as make perf-tarbz2-src-pkg which will create perf-3.2.0-rc1.tar, and perf-3.2.0-rc1.tar.bz2 respectively which can be used for the src rpms. This tar ball can be used as a separate package or subpackage. Thanks From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43526) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNt1G-0005p7-Fk for qemu-devel@nongnu.org; Tue, 08 Nov 2011 16:15:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RNt1F-000623-Gh for qemu-devel@nongnu.org; Tue, 08 Nov 2011 16:15:46 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57099) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNt1F-00061j-6Q for qemu-devel@nongnu.org; Tue, 08 Nov 2011 16:15:45 -0500 Date: Tue, 8 Nov 2011 22:15:01 +0100 (CET) From: John Kacur In-Reply-To: <20111108163331.GJ24234@thunk.org> Message-ID: References: <20111107203255.GF24234@thunk.org> <4EB85969.2010108@codemonkey.ws> <12F471C8-2CF3-4CD7-B417-C8CC898669E6@mit.edu> <20111108093225.GB32533@elte.hu> <20111108125509.GB1022@elte.hu> <20111108163331.GJ24234@thunk.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/ List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ted Ts'o , Ingo Molnar , Anthony Liguori , Pekka Enberg , Vince Weaver , Avi Kivity , "kvm@vger.kernel.org list" , "linux-kernel@vger.kernel.org List" , qemu-devel Developers , Alexander Graf , Blue Swirl , =?ISO-8859-15?Q?Am=E9rico_Wang?= , Linus Torvalds , Thomas Gleixner , Peter Zijlstra , Arnaldo Carvalho de Melo On Tue, 8 Nov 2011, Ted Ts'o wrote: > On Tue, Nov 08, 2011 at 01:55:09PM +0100, Ingo Molnar wrote: > > I guess you can do well with a split project as well - my main claim > > is that good compatibility comes *naturally* with integration. > > Here I have to disagree; my main worry is that integration makes it > *naturally* easy for people to skip the hard work needed to keep a > stable kernel/userspace interface. > > The other worry which I've mentioned, but which I haven't seen > addressed, is that the even if you can use a perf from a newer kernel > with an older kernel, this causes distributions a huge amount of pain, > since they have to package two different kernel source packages, and > only compile perf from the newer kernel source package. This leads to > all sorts of confusion from a distribution packaging point of view. > > For example, assume that RHEL 5, which is using 2.6.32 or something > like that, wants to use a newer e2fsck that does a better job fixing > file system corruptions. If it were bundled with the kernel, then > they would have to package up the v3.1 kernel sources, and have a > source RPM that isn't used for building kernel sources, but just to > build a newer version of e2fsck. Fortunately, they don't have to do > that. They just pull down a newer version of e2fsprogs, and package, > build, test, and ship that. > > In addition, suppose Red Hat ships a security bug fix which means a > new kernel-image RPM has to be shipped. Does that mean that Red Hat > has to ship new binary RPM's for any and all tools/* programs that > they have packaged as separate RPM's? Or should installing a new > kernel RPM also imply dropping new binaries in /usr/bin/perf, et. al? > There are all sorts of packaging questions that are raised > integration, and from where I sit I don't think they've been > adequately solved yet. > This in practice is not a big deal. There are many approaches for how the RPM can be built, but basically getting the perf source is just a matter of make perf-tar-src-pkg or friends such as make perf-tarbz2-src-pkg which will create perf-3.2.0-rc1.tar, and perf-3.2.0-rc1.tar.bz2 respectively which can be used for the src rpms. This tar ball can be used as a separate package or subpackage. Thanks