From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755681Ab1KHNa2 (ORCPT ); Tue, 8 Nov 2011 08:30:28 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35005 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754420Ab1KHNa0 (ORCPT ); Tue, 8 Nov 2011 08:30:26 -0500 Date: Tue, 8 Nov 2011 14:29:35 +0100 From: Karel Zak To: Pekka Enberg Cc: "Ted Ts'o" , Gerd Hoffmann , Pekka Enberg , Alexander Graf , Avi Kivity , Linus Torvalds , Ingo Molnar , "linux-kernel@vger.kernel.org List" , "kvm@vger.kernel.org list" , qemu-devel Developers , =?utf-8?Q?Am=C3=A9rico?= Wang , Blue Swirl Subject: Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels Message-ID: <20111108132935.GE3322@nb.net.home> References: <877C82F4-F07C-44AA-8722-3AF57CFC4597@suse.de> <4EB7B1A9.9000409@redhat.com> <4EB7CA52.5050409@redhat.com> <20111107122902.GA24685@thunk.org> <20111107124757.GC24685@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 07, 2011 at 03:12:28PM +0200, Pekka Enberg wrote: > On Mon, Nov 7, 2011 at 2:47 PM, Ted Ts'o wrote: > > I don't think perf should be used as a precendent that now argues that > > any new kernel utility should be moved into the kernel sources.  Does > > it make sense to move all of mount, fsck, login, etc., into the kernel > > sources?  There are far more kernel tools outside of the kernel > > sources than inside the kernel sources. [...] > I don't know if it makes sense to merge the tools you've mentioned above. > My gut feeling is that it's probably not reasonable - there's already a > community working on it with their own development process and coding > style. I don't think there's a simple answer to this but I don't agree with > your rather extreme position that all userspace tools should be kept out > of the kernel tree. Ted's position is not extreme. He follows the simple and exactly defined border between userspace and kernel. The native userspace feature is variability and substitutability. The util-linux package is really nice example: - you don't have to use it, you can use busybox - we have currently three implementation of login(1), many getty implementations, etc. - it's normal that people use the latest util-linux releases with very old kernels (in year 2008 I had report from person with kernel 2.4:-) - userspace is very often about portability -- it's crazy, but some people use some utils from util-linux on Hurd, Solaris and BSD (including very Linux specific things like mkswap and hwclock) Anyway, I agree that small one-man projects are ineffective for important system tools -- it's usually better to merge things into large projects with reliable infrastructure and alive community (here I agree with Lennart's idea to have 3-5 projects for whole low-level userspace). Karel -- Karel Zak http://karelzak.blogspot.com From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:32880) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNll0-0003aL-Bj for qemu-devel@nongnu.org; Tue, 08 Nov 2011 08:30:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RNlku-00012V-HR for qemu-devel@nongnu.org; Tue, 08 Nov 2011 08:30:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36106) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNlku-00012I-94 for qemu-devel@nongnu.org; Tue, 08 Nov 2011 08:30:24 -0500 Date: Tue, 8 Nov 2011 14:29:35 +0100 From: Karel Zak Message-ID: <20111108132935.GE3322@nb.net.home> References: <877C82F4-F07C-44AA-8722-3AF57CFC4597@suse.de> <4EB7B1A9.9000409@redhat.com> <4EB7CA52.5050409@redhat.com> <20111107122902.GA24685@thunk.org> <20111107124757.GC24685@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pekka Enberg Cc: Ted Ts'o , "kvm@vger.kernel.org list" , qemu-devel Developers , Alexander Graf , "linux-kernel@vger.kernel.org List" , Blue Swirl , Pekka Enberg , Avi Kivity , =?utf-8?Q?Am=C3=A9rico?= Wang , Ingo Molnar , Linus Torvalds , Gerd Hoffmann On Mon, Nov 07, 2011 at 03:12:28PM +0200, Pekka Enberg wrote: > On Mon, Nov 7, 2011 at 2:47 PM, Ted Ts'o wrote: > > I don't think perf should be used as a precendent that now argues tha= t > > any new kernel utility should be moved into the kernel sources. =C2=A0= Does > > it make sense to move all of mount, fsck, login, etc., into the kerne= l > > sources? =C2=A0There are far more kernel tools outside of the kernel > > sources than inside the kernel sources. [...] > I don't know if it makes sense to merge the tools you've mentioned abov= e. > My gut feeling is that it's probably not reasonable - there's already a > community working on it with their own development process and coding > style. I don't think there's a simple answer to this but I don't agree = with > your rather extreme position that all userspace tools should be kept ou= t > of the kernel tree. Ted's position is not extreme. He follows the simple and exactly defined border between userspace and kernel. The native userspace feature is variability and substitutability. The util-linux package is really nice example: - you don't have to use it, you can use busybox - we have currently three implementation of login(1), many getty=20 implementations, etc. - it's normal that people use the latest util-linux releases with very=20 old kernels (in year 2008 I had report from person with kernel 2.4:-) - userspace is very often about portability -- it's crazy, but some peo= ple use some utils from util-linux on Hurd, Solaris and BSD (including ve= ry Linux specific things like mkswap and hwclock) Anyway, I agree that small one-man projects are ineffective for important system tools -- it's usually better to merge things into large projects with reliable infrastructure and alive community (here I agree with Lennart's idea to have 3-5 projects for whole low-level userspace).=20 Karel --=20 Karel Zak http://karelzak.blogspot.com