From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [PATCH] drm: Use ENOENT consistently for the error return for an unmatched handle. Date: Thu, 05 Aug 2010 09:25:32 +0100 Message-ID: <89kc63$hlloja@fmsmga002.fm.intel.com> References: <1280927986-7333-1-git-send-email-chris@chris-wilson.co.uk> <1280961991.3525.3.camel@clockmaker-el6> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1280961991.3525.3.camel@clockmaker-el6> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Dave Airlie Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On Thu, 05 Aug 2010 08:46:31 +1000, Dave Airlie wrote: > Have you verified no userspace relies on this return value? since this > technically an ABI change. > > >From what I can see probably only libdrm tests care. I haven't found any other instances of code checking return values, more often the error code is simply reported. Even those tests show that we can expect EINVAL, ENOENT or EBADF for an invalid buffer handle. It's the reporting that I want clarified as the "invalid fd" is misleading for bug reporters. (Doubly so when this gets confused with a genuine EBADF!) -- Chris Wilson, Intel Open Source Technology Centre