From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933598AbcIAMuo (ORCPT ); Thu, 1 Sep 2016 08:50:44 -0400 Received: from foss.arm.com ([217.140.101.70]:58112 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752127AbcIAMum (ORCPT ); Thu, 1 Sep 2016 08:50:42 -0400 Date: Thu, 1 Sep 2016 13:50:39 +0100 From: Liviu Dudau To: Greg Kroah-Hartman Cc: Nicolai Stange , Brian Starkey , LKML Subject: Re: [PATCH] debugfs: Add proxy function for the mmap file operation Message-ID: <20160901125039.GA26936@e106497-lin.cambridge.arm.com> References: <20160729143459.2672-1-Liviu.Dudau@arm.com> <87oa5gpcu1.fsf@gmail.com> <87wpjzkrgn.fsf@gmail.com> <20160805101849.GA29995@e106950-lin.cambridge.arm.com> <8760rfzczy.fsf@gmail.com> <20160831130749.GA23785@kroah.com> <20160831152352.GC1050@e106497-lin.cambridge.arm.com> <20160901061933.GA2395@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160901061933.GA2395@kroah.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 01, 2016 at 08:19:33AM +0200, Greg Kroah-Hartman wrote: > 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 writes: > > > > > > > > > On Tue, Aug 02, 2016 at 07:31:36PM +0200, Nicolai Stange wrote: > > > > >>Nicolai Stange 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? Taking snapshots of a composition scene using the KMS driver for Mali DP. > > 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. We felt sysfs gives a whiff of official support for the feature, while in reality is a stop gap until we work out the V4L2 functionality to do the same thing. Best regards, Liviu > > thanks, > > greg k-h > -- ==================== | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --------------- ¯\_(ツ)_/¯