mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: Nicolai Stange <nicstange@gmail.com>,
	Brian Starkey <brian.starkey@arm.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] debugfs: Add proxy function for the mmap file operation
Date: Thu, 1 Sep 2016 08:19:33 +0200	[thread overview]
Message-ID: <20160901061933.GA2395@kroah.com> (raw)
In-Reply-To: <20160831152352.GC1050@e106497-lin.cambridge.arm.com>

On Wed, Aug 31, 2016 at 04:23:52PM +0100, Liviu Dudau wrote:
> On Wed, Aug 31, 2016 at 03:07:49PM +0200, Greg Kroah-Hartman wrote:
> > On Fri, Aug 05, 2016 at 01:11:45PM +0200, Nicolai Stange wrote:
> > > Brian Starkey <brian.starkey@arm.com> writes:
> > > 
> > > > On Tue, Aug 02, 2016 at 07:31:36PM +0200, Nicolai Stange wrote:
> > > >>Nicolai Stange <nicstange@gmail.com> writes:
> > > >>> However, if you wish to have some mmapable debugfs file which *can* go
> > > >>> away, introducing mmap support in the debugfs full proxy is perfectly
> > > >>> valid. But please see below.
> > > >>
> > > >>Assuming that you've got such a use case, please consider resending your
> > > >>patch along with the Cocci script below (and the Coccinelle team CC'ed,
> > > >>of course). If OTOH your mmapable debugfs files are never removed, just
> > > >>drop this message and use debugfs_create_file_unsafe() instead.
> > > >
> > > > So we do have an implementation using this, but it's likely we will
> > > > keep it out-of-tree (it's a stop-gap until we can get a non-debugfs
> > > > implementation of the functionality into mainline).
> > > >
> > > > Do you think it's worth merging this (and your cocci script) anyway to
> > > > save someone else doing the same thing later?
> > > 
> > > I personally think that having ->mmap() support in debugfs would be a
> > > good thing to have in general and I expect there to be some further
> > > demand in the future.
> > 
> > Ugh, mmap in debugfs, that's funny.  And sad...
> 
> Yeah.
> 
> While our need for the mmap-ing the debugfs entry is at best a temporary
> option and a hack, I would be interested to know what alternatives could
> be used to read a large amount of data that does not need the seq_operations
> API? The out-of-tree proof-of-concept code that we have to interact with
> a memory write engine needs to be able to access the output buffer from
> userspace, but that output buffer is created by the kernel KMS driver.

What type of debugging do you need this for?

A binary sysfs attribute also might work well for you, on the device
that you are talking to, but if not, yeah, mmap on debugfs will work
just fine, seems to be the best fit.

thanks,

greg k-h

  reply	other threads:[~2016-09-01  6:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-29 14:34 Liviu Dudau
2016-07-29 17:35 ` Nicolai Stange
2016-08-02 17:31   ` Nicolai Stange
2016-08-05 10:18     ` Brian Starkey
2016-08-05 11:11       ` Nicolai Stange
2016-08-31 13:07         ` Greg Kroah-Hartman
2016-08-31 15:23           ` Liviu Dudau
2016-09-01  6:19             ` Greg Kroah-Hartman [this message]
2016-09-01 12:50               ` Liviu Dudau
2016-09-01 14:43                 ` Greg Kroah-Hartman

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=20160901061933.GA2395@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=Liviu.Dudau@arm.com \
    --cc=brian.starkey@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nicstange@gmail.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

Powered by JetHome