Re: ENOENT as an ioctl return code

[Thomas Hellstrom <thomas@shipmail.org>]

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..

Thanks,
Thomas


> -Daniel