From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S936192AbcA0VlQ (ORCPT <rfc822;w@1wt.eu>);
	Wed, 27 Jan 2016 16:41:16 -0500
Received: from mail-pa0-f49.google.com ([209.85.220.49]:33775 "EHLO
	mail-pa0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S935244AbcA0VlJ (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Jan 2016 16:41:09 -0500
Subject: Re: [PATCH v2 01/11] dma-buf/sync_file: de-stage sync_file
To: Gustavo Padovan <gustavo@padovan.org>,
        Emil Velikov <emil.l.velikov@gmail.com>,
        Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>,
        devel@driverdev.osuosl.org,
        ML dri-devel <dri-devel@lists.freedesktop.org>,
        Daniel Stone <daniels@collabora.com>,
        =?UTF-8?Q?Arve_Hj=c3=b8nnev=c3=a5g?= <arve@android.com>,
        Riley Andrews <riandrews@android.com>,
        Daniel Vetter <daniel.vetter@ffwll.ch>,
        Rob Clark <robdclark@gmail.com>,
        John Harrison <John.C.Harrison@intel.com>,
        Gustavo Padovan <gustavo.padovan@collabora.co.uk>
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>
 <CACvgo52bp9FQO50REHMzqaqXnwdkTx2yjx_xiet2V_wQscuu1Q@mail.gmail.com>
 <20160127202540.GD3773@joana>
From: Greg Hackmann <ghackmann@google.com>
Message-ID: <56A9396F.8010803@google.com>
Date: Wed, 27 Jan 2016 13:41:03 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <20160127202540.GD3773@joana>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 01/27/2016 12:25 PM, Gustavo Padovan wrote:
>>>> Is there a value in keeping the abi unchanged?
>>>> If not, then Documentation/ioctl/botching-up-ioctls.txt is worth a read.
>>>
>>> None from me. I'll look where we can improve the ABI.

Android has existing clients of the current ABI.  Thankfully they're all 
contained in system services like SurfaceFlinger, since end-user apps 
don't get direct access to fence fds.

As long the ABI breaks don't remove functionality we depend on, we can 
wrap around them in our userspace libsync.  I'd rather not have to do 
that, but it's a price I'm willing to pay to get this moved out of staging.

>>   - struct sync_file_info_data::fence_info is of type __u8 yet it is "a
>> fence_info struct for every fence in the sync_file". Thus shouldn't
>> one use "struct fence_info" as the type ?
>
> Agreed. But I'm currently thinking if we really should keep this ioctl.
>
> 	Gustavo
>

I'm not seeing any consumers of driver_data in our tree.  OTOH 
completely getting rid of the ioctl would be a problem, since 
SurfaceFlinger depends on the timestamp information for its own bookkeeping.