From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg Hackmann Subject: Re: [PATCH v2 01/11] dma-buf/sync_file: de-stage sync_file Date: Fri, 29 Jan 2016 09:46:15 -0800 Message-ID: <56ABA567.6000501@google.com> References: <1453901439-19467-1-git-send-email-gustavo@padovan.org> <1453901439-19467-2-git-send-email-gustavo@padovan.org> <56A8D4A7.1070409@linux.intel.com> <20160127170313.GC3773@joana> <20160127202540.GD3773@joana> <56A9396F.8010803@google.com> <20160128092355.GS11240@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20160128092355.GS11240@phenom.ffwll.local> Sender: linux-kernel-owner@vger.kernel.org To: Gustavo Padovan , Emil Velikov , Maarten Lankhorst , Greg Kroah-Hartman , "Linux-Kernel@Vger. Kernel. Org" , devel@driverdev.osuosl.org, ML dri-devel , Daniel Stone , =?UTF-8?Q?Arve_Hj=c3=b8nnev=c3=a5g?= , Riley Andrews , Rob Clark , John Harrison , Gustavo Padovan List-Id: dri-devel@lists.freedesktop.org On 01/28/16 01:23, Daniel Vetter wrote: > And I think driver_data really shouldn't be there, it makes things > complicated with the array of variable-sized objects, and generic > userspace can't really use it - for debug output we already have > obj/driver_name per fence point, which I think is good enough. I looked at our device kernels, and some vendors actually are filling in driver_data. I'm just not seeing any accesses to them in our *userspace* tree. And in a lot of cases it looks like they're just filling in debugging information that they could get elsewhere. I'm checking with our vendor contacts to see what they're actually using this for (if anything). > Would that be ok for you from the Android side if Gustavo also provides a > patch to update libsync? I don't think the ABI is fundamentally broken, > but this light cleanup would be nice. No objections here. Just upload the changes to AOSP and add me as a reviewer. > Wrt keeping SYNC_WAIT: I think that's totally fine. Redundant since > polling is supported, but not really an issue imo either. If we're totally > lazy we could implement SYNC_WAIT internally using poll and shave off a > few lines of the implementation. Honestly this is the change I'm least worried about, since poll() will work with existing kernels too. The only difference would be that the SYNC_WAIT ioctl fails when given something that's not specifically a sync fence; but I'm skeptical that anything actually depends on that behavior.