[tmhedberg]

ENOENT isn't a new error code. It's the standard errno value that indicates an attempt to access a nonexistent file or directory on all POSIX platforms.

The problem is that it was being misappropriated in a nonsensical way, returned by an ioctl call. ioctl can only be called on already-open file descriptors, so it makes no sense for it to complain that the file doesn't exist. If the file pointed to by the file descriptor didn't exist, the file descriptor wouldn't have been able to be opened in the first place (errno would have been set to ENOENT by the call to open).

[ziffusion]

What if an ioctl is trying to indicate that a certain "entry" is not valid or available? Like when it is returning a cached entry or dealing with some container, where a notion of an entry does make sense. Insisting that ENOENT is reserved for path operations seems asinine.

[tmhedberg]

What if an ioctl is trying to indicate that a certain "entry" is not valid or available?

I don't understand the question. It is not possible for ioctl to be called on a valid, open file descriptor that represents a file that is not valid or available. Even if the file is unlinked after being opened, the kernel will ensure that it remains available to any processes that have it open until they close the file descriptor.

Like when it is returning a cached entry or dealing with some container, where a notion of an entry does make sense.

I honestly don't know what you mean by this. ioctls, like nearly all Unix system calls, are file system operations, they necessarily and by definition refer to files.

Insisting that ENOENT is reserved for path operations seems asinine.

On the contrary, ENOENT has meant "No such file or directory" since the early days of Unix history. Arbitrarily deciding to redefine it now would be asinine. There are other errno values to represent other error conditions.

[ziffusion]

I am just saying that the abstractions that the drivers can implement, can be pretty diverse. A particular ioctl may very well be dealing with a container like abstraction (contained items may or may not be file paths), and some return value that indicates "NO SUCH ENTRY" (i.e. ENOENT) may not be so out of order.

These examples are contrived, but consider a driver returning a encryption key corresponding to a index, which is stored in some encryption hardware table (controlled by the driver). Or a driver could be maintaining a cache, which is indexed by a key. Or even routing entries. There are a million possibilities.

I have to admit that I have used ENOENT for cases where "NO SUCH ENTRY" made sense. But maybe the tradition is to exclusively use it for path based operations only. I better shut up before Linus gets on my case. Because it would not be good for the Linux world at all. I'd probably clock him really badly if he spoke to me like that.

[tmhedberg]

As far as I know, the "ENT" in ENOENT refers specifically to a "dentry" (directory entry), i.e. the kernel data structure `struct dentry`, identified by a pathname in the virtual file system. It's not supposed to be a generic term for an entry in some arbitrary container of data.

I do see where you're coming from now, but I still think any usage other than the standard "no such file" meaning is errno abuse.

[ziffusion]

Seems reasonable enough. Can't help but wonder though, that a lot or the other errnos were probably also invented for very specific contexts, but find use in a wider sense because they capture a more generic error class.

[looser]

Ah! So Linus argument makes sense indeed. No need to test if the file exists in a process that assumes it is already opened... Thanks for clearing that up.