[looser]

Using some logic here:

1 - It seems Mauro added a new error message called ENOENT; 2 - After this change, Mauro noticed an error at pulseaudio; 3 - Linus says that always the userspace is right and kernel space is wrong in those cases and simply discarded Mauro's argument;

But thinking about this I think Mauro is not entirely wrong. Mauro's question makes a lot of sense to me: Why pulseaudio failed after just a new error code was added to the kernel?

Can't it be that pulseaudio is doing some wrong treatment that is ignoring the possibility of a new (or non-existent) error code?

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

[btilly]

My personal programming style when possible is to break - loudly and informatively - on any unexpected condition so that a human can fix it. A new error code meaning who knows what would qualify.

Now a widely distributed user library is probably not the right place for that style. But I cannot trivially disagree with a developer who took that route.