Date: Wed, 18 Feb 2015 21:56:03 +0100
From: Ingo Molnar <mingo@kernel.org>
To: Scott Wood <scottwood@freescale.com>
Cc: Andi Kleen <andi@firstfloor.org>, Tom Huynh <tom.huynh@freescale.com>,
        Peter Zijlstra <peterz@infradead.org>, linuxppc-dev@lists.ozlabs.org,
        acme@kernel.org, linux-kernel@vger.kernel.org, paulus@samba.org,
        Jiri Olsa <jolsa@redhat.com>, mingo@redhat.com
Subject: Re: [PATCH 1/3] perf/e6500: Make event translations available in
 sysfs
Message-ID: <20150218205603.GA21074@gmail.com>
References: <1423262636-12053-1-git-send-email-tom.huynh@freescale.com>
 <1423262636-12053-2-git-send-email-tom.huynh@freescale.com>
 <20150209100242.GM23123@twins.programming.kicks-ass.net>
 <20150209100738.GA5461@gmail.com>
 <20150209121132.GB3952@krava.redhat.com>
 <20150209132557.GA8099@gmail.com>
 <20150209204019.GA13991@two.firstfloor.org>
 <1423613998.2713.16.camel@aoeu.buserror.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1423613998.2713.16.camel@aoeu.buserror.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1444
Lines: 43


* Scott Wood <scottwood@freescale.com> wrote:

> On Mon, 2015-02-09 at 21:40 +0100, Andi Kleen wrote:
> > > I'll NAK any external 'download area' (and I told that Andi 
> > > before): tools/perf/event-tables/ or so is a good enough 
> > > 'download area' with fast enough update cycles.
> > 
> > The proposal was to put it on kernel.org, similar to how
> > external firmware blobs are distributed. [...]

Fortunately perf is not an external firmware blob ...

> > [...] CPU event lists are data sheets, so are like 
> > firmware. [...]

What an absolute, idiotic, nonsense argument!

CPU event lists are human readable descriptions for events. 
If they aren't then they have no place in tooling.

Treating them like firmware is as backwards as it gets.

> > [...]  They do not follow the normal kernel code 
> > licenses. They are not source code. They cannot be 
> > reviewed in the normal way.
> 
> How is it different from describing registers and bits in 
> driver header files?  What does it mean to talk about a 
> license on information, rather than the expression of 
> information?

Andi is making idiotic arguments, instead of implementing 
the technically sane solution.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/