[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180928205907.GD32651@tassilo.jf.intel.com>
Date: Fri, 28 Sep 2018 13:59:07 -0700
From: Andi Kleen <ak@...ux.intel.com>
To: Jann Horn <jannh@...gle.com>
Cc: Mark Rutland <mark.rutland@....com>,
Thomas Gleixner <tglx@...utronix.de>, tursulin@...ulin.net,
kernel list <linux-kernel@...r.kernel.org>,
tvrtko.ursulin@...ux.intel.com,
Peter Zijlstra <peterz@...radead.org>,
the arch/x86 maintainers <x86@...nel.org>,
"H . Peter Anvin" <hpa@...or.com>, acme@...nel.org,
alexander.shishkin@...ux.intel.com, jolsa@...hat.com,
namhyung@...nel.org, maddy@...ux.vnet.ibm.com,
alexey.budankov@...ux.intel.com, Kees Cook <keescook@...omium.org>
Subject: Re: [RFC 0/5] perf: Per PMU access controls (paranoid setting)
> > This new file descriptor argument doesn't exist today so it would
> > need to create a new system call with more arguments
>
> Is that true? The first argument is a pointer to a struct that
> contains its own size, so it can be expanded without an ABI break. I
> don't see any reason why you couldn't cram more stuff in there.
You're right we could put the fd into the perf_event, but the following is
still true:
> > Obviously we would need to keep the old system call around
> > for compability, so you would need to worry about this
> > interaction in any case!
> >
> > So tying it together doesn't make any sense, because
> > the problem has to be solved separately anyways.
-Andi
Powered by blists - more mailing lists