From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752933Ab1KGVgN (ORCPT ); Mon, 7 Nov 2011 16:36:13 -0500 Received: from mail-vx0-f174.google.com ([209.85.220.174]:42459 "EHLO mail-vx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752212Ab1KGVgK convert rfc822-to-8bit (ORCPT ); Mon, 7 Nov 2011 16:36:10 -0500 MIME-Version: 1.0 In-Reply-To: <20111107203255.GF24234@thunk.org> References: <4EB6BAED.2030400@redhat.com> <4EB6BEFA.6000303@codemonkey.ws> <20111106183132.GA4500@thunk.org> <20111106231953.GD4500@thunk.org> <20111107203255.GF24234@thunk.org> Date: Mon, 7 Nov 2011 23:36:09 +0200 X-Google-Sender-Auth: X2LMXqC4xeTooONB8WyP9_ETHCo Message-ID: Subject: Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels From: Pekka Enberg To: "Ted Ts'o" , Pekka Enberg , Vince Weaver , Anthony Liguori , Avi Kivity , "kvm@vger.kernel.org list" , "linux-kernel@vger.kernel.org List" , qemu-devel Developers , Alexander Graf , Blue Swirl , =?ISO-8859-1?Q?Am=E9rico_Wang?= , Ingo Molnar , Linus Torvalds Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Ted, On Mon, Nov 7, 2011 at 10:32 PM, Ted Ts'o wrote: > Personally, I consider code that runs in userspace as a pretty bright > line, as being "not kernel code", and while perhaps things like > initramfs and the crazy ideas people have had in the past of moving > stuff out of kernel/init.c into userspace might have qualified as > stuff really close to the kernel, something like kvm-tool that runs > way after boot, doesn't even come close.  Wine is another example of > another package that has lots of close kernel ties, but was also not > bundled into the kernel. It's not as clear line as you make it out to be. KVM tool also has mini-BIOS code that runs in guest space. It has a code that runs in userspace but is effectively a simple bootloader. So it definitely doesn't fit the simple definition of "running way after boot" (we're _booting_ the kernel too). Linsched fits your definition but is clearly worth integrating to the kernel tree. While you are suggesting that maybe we should move Perf out of the tree now that it's mature, I'm pretty sure you'd agree that it probably would not have happened if the userspace parts were developed out of tree. There's also spectacular failures in the kernel history where the userspace split was enforced. For example, userspace suspend didn't turn out the way people envisioned it at the time. We don't know how it would have worked out if the userspace components would have been in the tree but it certainly would have solved many if the early ABI issues. I guess I'm trying to argue here that there's a middle ground. I'm willing to bet projects like klibc and unified initramfs will eventually make it to the kernel tree because they simply make so much sense. I'm also willing to be that the costs of moving Perf out of the tree are simply too high to make it worthwhile. Does that mean KVM tool should get a free pass in merging? Absolutely not. But I do think your position is too extreme and ignores the benefits of developing userspace tools in the kernel ecosystem which was summed up by Anthony rather well in this thread: https://lkml.org/lkml/2011/11/7/169 Pekka