From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757490Ab1KJIQw (ORCPT ); Thu, 10 Nov 2011 03:16:52 -0500 Received: from mx3.mail.elte.hu ([157.181.1.138]:35294 "EHLO mx3.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755240Ab1KJIQu (ORCPT ); Thu, 10 Nov 2011 03:16:50 -0500 Date: Thu, 10 Nov 2011 09:14:58 +0100 From: Ingo Molnar To: Alexander Graf Cc: "Ted Ts'o" , Anthony Liguori , Pekka Enberg , Vince Weaver , Avi Kivity , "kvm@vger.kernel.org list" , "linux-kernel@vger.kernel.org List" , qemu-devel Developers , Blue Swirl , =?iso-8859-1?Q?Am=E9rico?= Wang , Linus Torvalds , Thomas Gleixner , Peter Zijlstra , Arnaldo Carvalho de Melo Subject: Re: [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/ Message-ID: <20111110081458.GC12768@elte.hu> References: <20111107203255.GF24234@thunk.org> <4EB85969.2010108@codemonkey.ws> <12F471C8-2CF3-4CD7-B417-C8CC898669E6@mit.edu> <20111108093225.GB32533@elte.hu> <20111108125509.GB1022@elte.hu> <20111108163331.GJ24234@thunk.org> <20111109082321.GA11473@elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-ELTE-SpamScore: -2.0 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-2.0 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.3.1 -2.0 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Alexander Graf wrote: > [...] > > Outside of the kernel tree, you can do your own decisions. If > someone thinks it's a great idea to write device emulation in > python (I would love that!), he could go in and implement it > without having to worry about Linus possibly rejecting it because > it's out of scope for a "Linux kernel testing tool". If you want to > create the greatest GUI for virtualization the world has ever seen, > you can just do it! Nothing holds you back. We actually recently added Python bindings to event tracing in perf: earth5:~/tip> find tools/perf/ -name '*.py' tools/perf/python/twatch.py tools/perf/util/setup.py tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/Util.py tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/Core.py tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/SchedGui.py tools/perf/scripts/python/syscall-counts.py tools/perf/scripts/python/sctop.py tools/perf/scripts/python/sched-migration.py tools/perf/scripts/python/check-perf-trace.py tools/perf/scripts/python/futex-contention.py tools/perf/scripts/python/failed-syscalls-by-pid.py tools/perf/scripts/python/net_dropmonitor.py tools/perf/scripts/python/syscall-counts-by-pid.py tools/perf/scripts/python/netdev-times.py ... and Linus did not object (so far ;-) - nor does he IMHO have many reasons to object as long as the code is sane and useful. Nor did Linus object when perf extended its scope from profiling to tracing, system monitoring, etc. While i don't talk for Linus, the only 'hard boundary' that Linus enforces and expects all maintainers to enforce that i'm aware of is "don't do crazy crap". Everything else is possible as long as it's high quality and reasonable, with a good upside story that is relevant to the kernel - you can let your imagination run wild, there's no artificial barriers that i'm aware of. Anyway, i have outlined the rough consequences of a user-space project being inside the kernel repo in this post: http://lkml.org/lkml/2011/11/10/86 ... and they are definitely not trivial and easy to meet. Thanks, Ingo From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/ Date: Thu, 10 Nov 2011 09:14:58 +0100 Message-ID: <20111110081458.GC12768@elte.hu> References: <20111107203255.GF24234@thunk.org> <4EB85969.2010108@codemonkey.ws> <12F471C8-2CF3-4CD7-B417-C8CC898669E6@mit.edu> <20111108093225.GB32533@elte.hu> <20111108125509.GB1022@elte.hu> <20111108163331.GJ24234@thunk.org> <20111109082321.GA11473@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Blue Swirl , Ted Ts'o , Peter Zijlstra , "kvm@vger.kernel.org list" , qemu-devel Developers , Vince Weaver , "linux-kernel@vger.kernel.org List" , Pekka Enberg , Arnaldo Carvalho de Melo , Avi Kivity , =?iso-8859-1?Q?Am=E9rico?= Wang , Thomas Gleixner , Linus Torvalds To: Alexander Graf Return-path: Content-Disposition: inline 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 * Alexander Graf wrote: > [...] > > Outside of the kernel tree, you can do your own decisions. If > someone thinks it's a great idea to write device emulation in > python (I would love that!), he could go in and implement it > without having to worry about Linus possibly rejecting it because > it's out of scope for a "Linux kernel testing tool". If you want to > create the greatest GUI for virtualization the world has ever seen, > you can just do it! Nothing holds you back. We actually recently added Python bindings to event tracing in perf: earth5:~/tip> find tools/perf/ -name '*.py' tools/perf/python/twatch.py tools/perf/util/setup.py tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/Util.py tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/Core.py tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/SchedGui.py tools/perf/scripts/python/syscall-counts.py tools/perf/scripts/python/sctop.py tools/perf/scripts/python/sched-migration.py tools/perf/scripts/python/check-perf-trace.py tools/perf/scripts/python/futex-contention.py tools/perf/scripts/python/failed-syscalls-by-pid.py tools/perf/scripts/python/net_dropmonitor.py tools/perf/scripts/python/syscall-counts-by-pid.py tools/perf/scripts/python/netdev-times.py ... and Linus did not object (so far ;-) - nor does he IMHO have many reasons to object as long as the code is sane and useful. Nor did Linus object when perf extended its scope from profiling to tracing, system monitoring, etc. While i don't talk for Linus, the only 'hard boundary' that Linus enforces and expects all maintainers to enforce that i'm aware of is "don't do crazy crap". Everything else is possible as long as it's high quality and reasonable, with a good upside story that is relevant to the kernel - you can let your imagination run wild, there's no artificial barriers that i'm aware of. Anyway, i have outlined the rough consequences of a user-space project being inside the kernel repo in this post: http://lkml.org/lkml/2011/11/10/86 ... and they are definitely not trivial and easy to meet. Thanks, Ingo From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37778) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROPoU-0005hV-WB for qemu-devel@nongnu.org; Thu, 10 Nov 2011 03:16:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ROPoT-0007p5-FY for qemu-devel@nongnu.org; Thu, 10 Nov 2011 03:16:46 -0500 Received: from mx3.mail.elte.hu ([157.181.1.138]:54928) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROPoT-0007ow-1y for qemu-devel@nongnu.org; Thu, 10 Nov 2011 03:16:45 -0500 Date: Thu, 10 Nov 2011 09:14:58 +0100 From: Ingo Molnar Message-ID: <20111110081458.GC12768@elte.hu> References: <20111107203255.GF24234@thunk.org> <4EB85969.2010108@codemonkey.ws> <12F471C8-2CF3-4CD7-B417-C8CC898669E6@mit.edu> <20111108093225.GB32533@elte.hu> <20111108125509.GB1022@elte.hu> <20111108163331.GJ24234@thunk.org> <20111109082321.GA11473@elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/ List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Blue Swirl , Ted Ts'o , Peter Zijlstra , "kvm@vger.kernel.org list" , qemu-devel Developers , Vince Weaver , "linux-kernel@vger.kernel.org List" , Pekka Enberg , Arnaldo Carvalho de Melo , Avi Kivity , =?iso-8859-1?Q?Am=E9rico?= Wang , Thomas Gleixner , Linus Torvalds * Alexander Graf wrote: > [...] > > Outside of the kernel tree, you can do your own decisions. If > someone thinks it's a great idea to write device emulation in > python (I would love that!), he could go in and implement it > without having to worry about Linus possibly rejecting it because > it's out of scope for a "Linux kernel testing tool". If you want to > create the greatest GUI for virtualization the world has ever seen, > you can just do it! Nothing holds you back. We actually recently added Python bindings to event tracing in perf: earth5:~/tip> find tools/perf/ -name '*.py' tools/perf/python/twatch.py tools/perf/util/setup.py tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/Util.py tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/Core.py tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/SchedGui.py tools/perf/scripts/python/syscall-counts.py tools/perf/scripts/python/sctop.py tools/perf/scripts/python/sched-migration.py tools/perf/scripts/python/check-perf-trace.py tools/perf/scripts/python/futex-contention.py tools/perf/scripts/python/failed-syscalls-by-pid.py tools/perf/scripts/python/net_dropmonitor.py tools/perf/scripts/python/syscall-counts-by-pid.py tools/perf/scripts/python/netdev-times.py ... and Linus did not object (so far ;-) - nor does he IMHO have many reasons to object as long as the code is sane and useful. Nor did Linus object when perf extended its scope from profiling to tracing, system monitoring, etc. While i don't talk for Linus, the only 'hard boundary' that Linus enforces and expects all maintainers to enforce that i'm aware of is "don't do crazy crap". Everything else is possible as long as it's high quality and reasonable, with a good upside story that is relevant to the kernel - you can let your imagination run wild, there's no artificial barriers that i'm aware of. Anyway, i have outlined the rough consequences of a user-space project being inside the kernel repo in this post: http://lkml.org/lkml/2011/11/10/86 ... and they are definitely not trivial and easy to meet. Thanks, Ingo