Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964822AbcCDQjz (ORCPT ); Fri, 4 Mar 2016 11:39:55 -0500 Received: from mail-wm0-f53.google.com ([74.125.82.53]:37894 "EHLO mail-wm0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964793AbcCDQjt (ORCPT ); Fri, 4 Mar 2016 11:39:49 -0500 Date: Fri, 4 Mar 2016 17:40:29 +0100 From: Daniel Vetter To: Greg Kroah-Hartman Cc: Gustavo Padovan , devel@driverdev.osuosl.org, Rob Clark , Daniel Stone , Daniel Vetter , Maarten Lankhorst , Riley Andrews , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Greg Hackmann , Gustavo Padovan , John Harrison Subject: Re: [PATCH] staging/android: add flags member to sync ioctl structs Message-ID: <20160304164029.GZ32705@phenom.ffwll.local> Mail-Followup-To: Greg Kroah-Hartman , Gustavo Padovan , devel@driverdev.osuosl.org, Rob Clark , Daniel Stone , Maarten Lankhorst , Riley Andrews , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Greg Hackmann , Gustavo Padovan , John Harrison References: <1456955489-18971-1-git-send-email-gustavo@padovan.org> <1457015837-7609-1-git-send-email-gustavo@padovan.org> <20160303161714.GA4133@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160303161714.GA4133@kroah.com> X-Operating-System: Linux phenom 4.3.0-1-amd64 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 Content-Length: 1336 Lines: 39 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 > > > > 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 ? ;-) Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch