ENOENT as an ioctl return code

[Dave Airlie]

On Wed, Dec 4, 2013 at 7:13 AM, Thomas Hellstrom <thomas at shipmail.org> 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.