From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57440) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNOAO-0001F2-82 for qemu-devel@nongnu.org; Mon, 07 Nov 2011 07:19:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RNOAN-0000kw-6X for qemu-devel@nongnu.org; Mon, 07 Nov 2011 07:19:08 -0500 Received: from mx1.redhat.com ([209.132.183.28]:8045) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNOAM-0000ks-Sj for qemu-devel@nongnu.org; Mon, 07 Nov 2011 07:19:07 -0500 Message-ID: <4EB7CCA9.7010507@redhat.com> Date: Mon, 07 Nov 2011 13:18:49 +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> <4EB7BACA.70006@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: "kvm@vger.kernel.org list" , qemu-devel Developers , Alexander Graf , "linux-kernel@vger.kernel.org List" , Blue Swirl , Sasha Levin , =?ISO-8859-1?Q?Am=E9rico_Wang?= , Paolo Bonzini , Ingo Molnar , Linus Torvalds , Avi Kivity On 11/07/11 12:44, Pekka Enberg wrote: > On Mon, Nov 7, 2011 at 1:02 PM, Paolo Bonzini wrote: >> Indeed I do not see any advantage, since all the interfaces they use are >> stable anyway (sysfs, msr.ko). >> >> If they had gone in x86info, for example, my distro (F16, not exactly >> conservative) would have likely picked those tools up already, but it >> didn't. > > Distributing userspace tools in the kernel tree is a relatively new > concept so it's not at all surprising distributions don't pick them up > as quickly. That doesn't mean it's a fundamentally flawed approach, > though. tools/ lacks a separation into "kernel hacker's testing+debugging toolbox" and "userspace tools". It lacks proper buildsystem integration for the userspace tools, there is no "make tools" and also no "make tools_install". Silently dropping new stuff into tools/ and expecting the world magically noticing isn't going to work. cheers, Gerd