Date: Fri, 11 Mar 2016 13:59:13 -0800
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Gustavo Padovan <gustavo@padovan.org>, devel@driverdev.osuosl.org,
        Rob Clark <robdclark@gmail.com>, Daniel Stone <daniels@collabora.com>,
        Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
        Riley Andrews <riandrews@android.com>, dri-devel@lists.freedesktop.org,
        linux-kernel@vger.kernel.org,
        Arve =?iso-8859-1?B?SGr4bm5lduVn?= <arve@android.com>,
        Greg Hackmann <ghackmann@google.com>,
        Gustavo Padovan <gustavo.padovan@collabora.co.uk>,
        John Harrison <John.C.Harrison@Intel.com>
Subject: Re: [PATCH] staging/android: add flags member to sync ioctl structs
Message-ID: <20160311215913.GB11274@kroah.com>
References: <1456955489-18971-1-git-send-email-gustavo@padovan.org>
 <1457015837-7609-1-git-send-email-gustavo@padovan.org>
 <20160303161714.GA4133@kroah.com>
 <20160304164029.GZ32705@phenom.ffwll.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160304164029.GZ32705@phenom.ffwll.local>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1651
Lines: 45

On Fri, Mar 04, 2016 at 05:40:29PM +0100, Daniel Vetter wrote:
> On Thu, Mar 03, 2016 at 08:17:14AM -0800, Greg Kroah-Hartman wrote:
> > On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote:
> > > From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> > > 
> > > Play safe and add flags member to all structs. So we don't need to
> > > break API or create new IOCTL in the future if new features that requires
> > > flags arises.
> > > 
> > > v2: check if flags are valid (zero, in this case)
> > > 
> > > v3: return -EINVAL if flags are not zero'ed
> > > 
> > > v4: add padding for 64-bit alignment
> > > 
> > > v5: rebase to use only stacked sync_file_info
> > 
> > Why are these vX things here in the changelog?
> 
> Because this is drm and we're special ;-)
> 
> > And you just broke all existing userspace users of this code, why are
> > you allowed to do that?
> > 
> > not ok...
> 
> We could do fence2.h if you absolutely insist and just forget about the
> current one, but that seemed silly. Like Gustavo said, everyone who
> actually cares about this stuff is perfectly fine with this. And there's
> not a single user of this in upstream anyway, so the only trees we could
> break are vendor trees with massive amounts of additional stuff.
> 
> Is that reasonable ok for you, or do you insist we do a fences2.h without
> going through staging ? ;-)

Ok, if everyone is ok with this api changing, and will not get mad if it
breaks things, I'm all for fixing this up.

I just want all of your signed-off-by lines on the series please.
Please respond to the v7 of this series and I'll be glad to queue them
up.

thanks,

greg k-h