From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754541AbbIAMzT (ORCPT ); Tue, 1 Sep 2015 08:55:19 -0400 Received: from mail-wi0-f174.google.com ([209.85.212.174]:35075 "EHLO mail-wi0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753505AbbIAMzR (ORCPT ); Tue, 1 Sep 2015 08:55:17 -0400 Date: Tue, 1 Sep 2015 14:55:12 +0200 From: Ingo Molnar To: Adrian Hunter Cc: =?utf-8?B?5bmz5p2+6ZuF5bezIC8gSElSQU1BVFXvvIxNQVNBTUk=?= , Arnaldo Carvalho de Melo , "linux-kernel@vger.kernel.org" , Jiri Olsa , Andy Lutomirski , Denys Vlasenko , Peter Zijlstra , Dave Hansen , Qiaowei Ren , "H. Peter Anvin" , Thomas Gleixner , Linus Torvalds Subject: Re: [PATCH 0/4] x86/insn: perf tools: Add a few new x86 instructions Message-ID: <20150901125512.GA13857@gmail.com> References: <1441029522-20235-1-git-send-email-adrian.hunter@intel.com> <20150901085432.GE6315@gmail.com> <50399556C9727B4D88A595C8584AAB37524FF3EF@GSjpTKYDCembx32.service.hitachi.net> <55E595B5.7090407@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55E595B5.7090407@intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Adrian Hunter wrote: > > Agreed, what I concern is that someone finds a bug and fixes one of them and > > another is not fixed. > > > > I'll see the forked version and check if it can be merged into the kernel. > > Ever since Linus complained about perf tools including kernel headers, I have > assumed we should have separate source code. That email thread was not cc'ed to > a mailing list but here is a quote: > > Em Sat, Jul 04, 2015 at 08:53:46AM -0700, Linus Torvalds escreveu: > > > So this is more fundamental, and looks like it's just due to perf abusing the > > kernel headers, and now that rbtree has rcu support ("rbtree: Make lockless > > searches non-fatal"), it gets tons of headers included that really don't work > > from user space. > > > > There might be other things going on, but the rbtree one seems to be a big > > one. I think perf needs to get its own rbtree header or something, instead of > > doing that insane "let's include random core kernel headers" thing. Note that even plain copying and occasional back-merges isn't a bad solution: it's better than 'messy sharing' of code. But we can also share code in a bit more organized fashion, and any of the two solutions I proposed solve these complications: - if we do the diff -u check warning during perf build then the forked versions won't stay forked for long. This is the simplest variant. - if we librarize this functionality into tools/lib/x86/decode/ (and make sure it's a library that can be linked into the kernel) then we are back to shared code. The problem wasn't to share code per se, the problem was to share code in a messy way, without making it apparent that it's shared code: which made it easy to break the tools/perf build via harmless looking kernel side changes. Thanks, Ingo