From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752879AbcIBU0i (ORCPT ); Fri, 2 Sep 2016 16:26:38 -0400 Received: from mail-it0-f44.google.com ([209.85.214.44]:37945 "EHLO mail-it0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751971AbcIBU0g (ORCPT ); Fri, 2 Sep 2016 16:26:36 -0400 Subject: Re: [PATCHv2 3/4] staging: android: ion: Add an ioctl for ABI checking To: Greg Kroah-Hartman References: <1472769644-11039-1-git-send-email-labbott@redhat.com> <1472769644-11039-4-git-send-email-labbott@redhat.com> <20160902061040.GB13294@kroah.com> Cc: Sumit Semwal , John Stultz , =?UTF-8?Q?Arve_Hj=c3=b8nnev=c3=a5g?= , Riley Andrews , Daniel Vetter , linaro-mm-sig@lists.linaro.org, devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org, Eun Taik Lee , Liviu Dudau , Jon Medhurst , Mitchel Humpherys , Jeremy Gebben , Bryan Huntsman , Android Kernel Team , Chen Feng , Brian Starkey From: Laura Abbott Message-ID: Date: Fri, 2 Sep 2016 13:26:31 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160902061040.GB13294@kroah.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/01/2016 11:10 PM, Greg Kroah-Hartman wrote: > On Thu, Sep 01, 2016 at 03:40:43PM -0700, Laura Abbott wrote: >> >> The current Ion ioctls lack a good way to tell what ioctls are >> available. Introduce an ioctl to give an ABI version. This way when the >> ABI inevitably gets screwed up userspace will have a way to tell what >> version of the screw up is available. > > This worries me. Why do we need this? Shouldn't any "new" abi changes > just add on, and not change existing ioctl structure calls? Or worst > case, you remove an ioctl and then userspace "knows" that when the call > fails. This may be more of an "I wish we had this when some poor decisions were made in the past". There were a couple of instances when the Ion ABI was broken (adding new fields, new ioctl numbers) that were a nightmare to deal with and a similar ioctl would have helped a lot. The botching-ioctls document also made reference to something simliar. > > And who is the major userspace user of this interface? Who controls it? > How are we keeping things in sync here? > I would expect this to not actually be used until we have breakage. The broken ioctl would then be checked as needed. Reading all this and thinking some, it sounds like this shouldn't actually be needed so long as we continue to not break the ioctls. I had a thought of this possibly making life easier for out of tree users to eventually convert over but I haven't heard much from actual out of tree users. I'd like to keep it just to hedge my bets but I also haven't had as much experience maintaining stable ioctls for the long term. If, from others experience, this type of ioctl is actually just more prone to breakage and doesn't help then I don't want to push something that will eventually break. > thanks, > > greg k-h > Thanks, Laura