public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: acme@kernel.org, peterz@infradead.org, mingo@redhat.com,
	tglx@linutronix.de, alexander.shishkin@linux.intel.com,
	schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com,
	will.deacon@arm.com, mark.rutland@arm.com, jolsa@redhat.com,
	namhyung@kernel.org, adrian.hunter@intel.com, ast@kernel.org,
	hpa@zytor.com, suzuki.poulosi@arm.com,
	linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 4/6] coresight: Use PMU driver configuration for sink selection
Date: Fri, 30 Nov 2018 08:42:53 +0100	[thread overview]
Message-ID: <20181130074253.GA3314@kroah.com> (raw)
In-Reply-To: <20181129230915.GA8881@xps15>

On Thu, Nov 29, 2018 at 04:09:15PM -0700, Mathieu Poirier wrote:
> Hi Greg,
> 
> On Thu, Nov 29, 2018 at 08:49:36AM +0100, Greg KH wrote:
> > On Wed, Nov 28, 2018 at 03:01:16PM -0700, Mathieu Poirier wrote:
> > > This patch uses the PMU driver configuration held in event::hw::drv_config
> > > to select a sink for each event that is created (the old sysFS way of
> > > working is kept around for backward compatibility).
> > 
> > It is "sysfs", no InterCaps please, I've never called it that in the
> > past.
> > 
> > And just use sysfs, if that does not work properly, then fix that, don't
> > create yet-another-way-to-configure-this-thing to just confuse people.
> 
> Thanks for the review, you've provided usefull comments.
> 
> Regarding the "char *" argument for the ioctl, I followed an example that
> currently exist but I can proceed differently.  

What driver currently uses a char * on an ioctl to parse arbritrary
userspace information to set its configuration?  That should be fixed...

> My goal with this patchset was specifically to fix what is wrong with sysfs and
> completely take it out of the equation.  The only reason to keep the kernel 
> interface alive was to prevent braking older user space perf tools currently
> using it.  

That's fine, just don't create a new syscall that takes arbritrary data
and parses it in the kernel, that's not ok.

> I chose to use an ioctl() because it is flexible and well suited for the dynamic
> nature of perf events.  It is also currently used to set various event specific 
> configuration so doing the same adds to the established pattern and avoids
> creating a new way of doing things, something the perf crew would have been
> quick to point out.
> 
> Was my approach wrong?

I don't know how the perf interface works, so perhaps work with those
developers to sync up and match what they use today?

But step back, what exactly are you trying to do here?  You have an
implementation of a solution but I don't see the problem stated anywhere
here.

thanks,

greg k-h

  reply	other threads:[~2018-11-30  7:42 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-28 22:01 [PATCH v4 0/6] perf: Add ioctl for PMU driver configuration Mathieu Poirier
2018-11-28 22:01 ` [PATCH v4 1/6] perf: Introduce ioctl to communicate driver configuration to kernel Mathieu Poirier
2018-11-29  7:47   ` Greg KH
2018-11-28 22:01 ` [PATCH v4 2/6] perf/core: Use " Mathieu Poirier
2018-11-29  7:48   ` Greg KH
2018-11-28 22:01 ` [PATCH v4 3/6] perf/aux: Make perf_event accessible to setup_aux() Mathieu Poirier
2018-11-28 22:01 ` [PATCH v4 4/6] coresight: Use PMU driver configuration for sink selection Mathieu Poirier
2018-11-29  7:49   ` Greg KH
2018-11-29 23:09     ` Mathieu Poirier
2018-11-30  7:42       ` Greg KH [this message]
2018-11-30 18:05         ` Mathieu Poirier
2018-11-28 22:01 ` [PATCH v4 5/6] perf tools: Make perf_evsel accessible to PMU driver configuration code Mathieu Poirier
2018-11-28 22:01 ` [PATCH v4 6/6] perf tools: Use ioctl function to send sink configuration to kernel Mathieu Poirier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181130074253.GA3314@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=ast@kernel.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=hpa@zytor.com \
    --cc=jolsa@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mathieu.poirier@linaro.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=schwidefsky@de.ibm.com \
    --cc=suzuki.poulosi@arm.com \
    --cc=tglx@linutronix.de \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox