From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753709Ab1KGWTh (ORCPT ); Mon, 7 Nov 2011 17:19:37 -0500 Received: from mail-gy0-f174.google.com ([209.85.160.174]:56801 "EHLO mail-gy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751898Ab1KGWTg (ORCPT ); Mon, 7 Nov 2011 17:19:36 -0500 Message-ID: <4EB85969.2010108@codemonkey.ws> Date: Mon, 07 Nov 2011 16:19:21 -0600 From: Anthony Liguori User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Pekka Enberg CC: "Ted Ts'o" , Vince Weaver , 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 Subject: Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels References: <4EB6BAED.2030400@redhat.com> <4EB6BEFA.6000303@codemonkey.ws> <20111106183132.GA4500@thunk.org> <20111106231953.GD4500@thunk.org> <20111107203255.GF24234@thunk.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/07/2011 03:36 PM, Pekka Enberg wrote: > 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 The kernel ecosystem does not have to be limited to linux.git. There could be a process to be a "kernel.org project" for projects that fit a certain set of criteria. These projects could all share the Linux kernel release cadence and have a kernel maintainer as a sponsor or something like that. That is something that could potentially benefit things like e2fs-tools and all of the other tools that are tied closely to the kernel. In fact, having a single place where users could find all of the various kernel related tools and helpers would probably be extremely useful. There's no reason this needs to be linux.git though, this could just be a web page on kernel.org. Regards, Anthony Liguori > > Pekka From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels Date: Mon, 07 Nov 2011 16:19:21 -0600 Message-ID: <4EB85969.2010108@codemonkey.ws> References: <4EB6BAED.2030400@redhat.com> <4EB6BEFA.6000303@codemonkey.ws> <20111106183132.GA4500@thunk.org> <20111106231953.GD4500@thunk.org> <20111107203255.GF24234@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Graf , Ted Ts'o , "kvm@vger.kernel.org list" , qemu-devel Developers , "linux-kernel@vger.kernel.org List" , Blue Swirl , Vince Weaver , Avi Kivity , =?ISO-8859-1?Q?Am=E9rico_Wang?= , Ingo Molnar , Linus Torvalds To: Pekka Enberg Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org On 11/07/2011 03:36 PM, Pekka Enberg wrote: > 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 The kernel ecosystem does not have to be limited to linux.git. There could be a process to be a "kernel.org project" for projects that fit a certain set of criteria. These projects could all share the Linux kernel release cadence and have a kernel maintainer as a sponsor or something like that. That is something that could potentially benefit things like e2fs-tools and all of the other tools that are tied closely to the kernel. In fact, having a single place where users could find all of the various kernel related tools and helpers would probably be extremely useful. There's no reason this needs to be linux.git though, this could just be a web page on kernel.org. Regards, Anthony Liguori > > Pekka From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54427) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNXXW-0000DU-2v for qemu-devel@nongnu.org; Mon, 07 Nov 2011 17:19:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RNXXU-0006bp-HV for qemu-devel@nongnu.org; Mon, 07 Nov 2011 17:19:38 -0500 Received: from mail-gx0-f173.google.com ([209.85.161.173]:57926) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNXXU-0006bl-Dg for qemu-devel@nongnu.org; Mon, 07 Nov 2011 17:19:36 -0500 Received: by ggnp2 with SMTP id p2so2252243ggn.4 for ; Mon, 07 Nov 2011 14:19:35 -0800 (PST) Message-ID: <4EB85969.2010108@codemonkey.ws> Date: Mon, 07 Nov 2011 16:19:21 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4EB6BAED.2030400@redhat.com> <4EB6BEFA.6000303@codemonkey.ws> <20111106183132.GA4500@thunk.org> <20111106231953.GD4500@thunk.org> <20111107203255.GF24234@thunk.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Alexander Graf , Ted Ts'o , "kvm@vger.kernel.org list" , qemu-devel Developers , "linux-kernel@vger.kernel.org List" , Blue Swirl , Vince Weaver , Avi Kivity , =?ISO-8859-1?Q?Am=E9rico_Wang?= , Ingo Molnar , Linus Torvalds On 11/07/2011 03:36 PM, Pekka Enberg wrote: > 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 The kernel ecosystem does not have to be limited to linux.git. There could be a process to be a "kernel.org project" for projects that fit a certain set of criteria. These projects could all share the Linux kernel release cadence and have a kernel maintainer as a sponsor or something like that. That is something that could potentially benefit things like e2fs-tools and all of the other tools that are tied closely to the kernel. In fact, having a single place where users could find all of the various kernel related tools and helpers would probably be extremely useful. There's no reason this needs to be linux.git though, this could just be a web page on kernel.org. Regards, Anthony Liguori > > Pekka