On Wed, Dec 4, 2013 at 7:13 AM, Thomas Hellstrom <thomas@xxxxxxxxxxxx> wrote: > On 12/03/2013 09:41 PM, Daniel Vetter wrote: >> >> On Tue, Dec 03, 2013 at 09:09:40PM +0100, Thomas Hellstrom wrote: >>> >>> Hi, >>> >>> By concidence I ran across this lkml message >>> >>> http://marc.info/?l=linux-kernel&m=135628421403144&w=2 >>> >>> with an important part in the middle: (this is not a drm commit) >>> >>> To make matters worse, commit f0ed2ce840b3 is clearly total and utter >>> CRAP even if it didn't break applications. ENOENT is not a valid error >>> return from an ioctl. Never has been, never will be. ENOENT means "No >>> such file and directory", and is for path operations. ioctl's are done >>> on files that have already been opened, there's no way in hell that >>> ENOENT would ever be valid. >>> >>> Perhaps we should rethink the use of ENOENT when not finding mode >>> objects? >> >> Yeah, it's somewhat abuse, otoh if we'd do a dma-buf export telling >> userspace that "no such file exists" is a pretty precise answer. In a way >> we _do_ duplicate file objects ... And having this special error code for >> lookup failures is occasionally rather useful imo. >> >> So honestly I'd prefer we keep on doing our practice. > > > Hmm, yes, I figure this might have originated in the GEM ioctls that was > actually trying to mimic file behavior, > but then spilled over to the mode objects in the modesetting code... > > Just thought I'd raise the issue since I saw that message.. > We just need to make sure userspace relies on it, then we can't change it :-P Linus would enter an infinite loop and possibly explode. Dave. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
