From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:34010) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNO1F-00073R-3Q for qemu-devel@nongnu.org; Mon, 07 Nov 2011 07:09:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RNO1E-0007Vq-4J for qemu-devel@nongnu.org; Mon, 07 Nov 2011 07:09:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:23959) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNO1D-0007Vg-SI for qemu-devel@nongnu.org; Mon, 07 Nov 2011 07:09:40 -0500 Message-ID: <4EB7CA52.5050409@redhat.com> Date: Mon, 07 Nov 2011 13:08:50 +0100 From: Gerd Hoffmann MIME-Version: 1.0 References: <1320543320-32728-1-git-send-email-agraf@suse.de> <4EB65C5B.8070709@redhat.com> <4EB66036.4080102@redhat.com> <1320577728.1428.73.camel@jaguar> <4EB67486.1070105@redhat.com> <4EB67D17.7000701@redhat.com> <4EB680D9.2070706@redhat.com> <877C82F4-F07C-44AA-8722-3AF57CFC4597@suse.de> <4EB7B1A9.9000409@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Blue Swirl , "kvm@vger.kernel.org list" , qemu-devel Developers , "linux-kernel@vger.kernel.org List" , Alexander Graf , Pekka Enberg , Avi Kivity , =?ISO-8859-1?Q?Am=E9rico_?= =?ISO-8859-1?Q?Wang?= , Ingo Molnar , Linus Torvalds On 11/07/11 12:34, Pekka Enberg wrote: > On Mon, 7 Nov 2011, Gerd Hoffmann wrote: >>> It's not just about code, it's as much about culture and development >>> process. >> >> Indeed. The BSDs have both kernel and the base system in a single >> repository. There are probably good reasons for (and against) it. >> >> In Linux we don't have that culture. No tool (except perf) lives in the >> kernel repo. I fail to see why kvm-tool is that much different from >> udev, util-linux, iproute, filesystem tools, that it should be included. > > You seem to think perf is an exception - I think it's going to be the > future norm for userspace components that are very close to the kernel. perf *is* an exception today. It might make sense to change that. But IMHO it only makes sense if there is a really broad agreement on it and other core stuff moves into the kernel too. Then you'll be able to get advantages out of it. For example standardizing the process to create an initramfs (using the userspace tools shipped with the kernel) instead of having each distro creating its own way. I somehow doubt we'll see such an broad agreement though. Most people seem to be happy with the current model. There is a reason why the klibc + early-userspace-in-kernel-tree project died in the end ... cheers, Gerd