From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753368AbaDDOUm (ORCPT ); Fri, 4 Apr 2014 10:20:42 -0400 Received: from one.firstfloor.org ([193.170.194.197]:51761 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753239AbaDDOUk (ORCPT ); Fri, 4 Apr 2014 10:20:40 -0400 Date: Fri, 4 Apr 2014 16:20:38 +0200 From: Andi Kleen To: Jovi Zhangwei Cc: Alexei Starovoitov , Ingo Molnar , Steven Rostedt , Masami Hiramatsu , Greg KH , Andi Kleen , LKML Subject: Re: ktap and ebpf integration Message-ID: <20140404142038.GR22728@two.firstfloor.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Anyway, I think there will don't have any necessary to upstream > ktap any more, I still enjoy the simplicity and flexibility given Not sure how you got to that conclusion. You were asked to evaluate if EBPF is an alternative for ktap. It looks like the answer is no. So the original KTAP VM design is back on the table. You can continue pursuing to merge that. No reason to give up. BTW I agree that EBPF won't work for ktap. The models (static vs dynamic typing etc.) are just too different. But it's good that it was studied in detail. -Andi -- ak@linux.intel.com -- Speaking for myself only.