tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: fdiscard error cases

On Sun, 27 Jul 2014, David Holland wrote:
It was pointed out that it would be well to distinguish devices that don't currently support discard, but theoretically should (because they're disks) from devices where it makes no sense (e.g. ttys). This is probably a good idea.

For fdiscard, I think the following errno values are likely to be relevant:

ENOSYS: The operation is not supported at all. e.g. a kernel module has not been loaded, or a build option was not enabled.

ENOTTY: It doesn't make sense to ask this driver layer to perform this operation. e.g. disk operation on a file or non-disk device.

ENODEV: It does make sense to ask, but this device (or this driver layer) doesn't support this operation. e.g. this device or file system doesn't implement discard. This doesn't distinguish between "not supported by driver" and "not supported by underlying hardware".

EINVAL: The arguments don't make sense. e.g. null pointer, or an invalid combination of flags, or a length or offset out of bounds.

EPERM: You don't have permission, but perhaps a process with different
credentials might success.

EACCESS: You don't have permission, but the problem is not in your credentials, the problem is in the way the object was opened. e.g. write on file opened with O_RDONLY.

Another option is to add a new errno for "Operation not implemented on
this object" or the like, to be a bit clearer about the distinction
between "not appropriate" and "not implemented" and maintain the
distinction between not implemented at the syscall level and not
implemented on a particular backend entity. But, adding errnos is not
something to do lightly...

I think the ENOTTY/ENODEV distinction is enough.

Many existing drivers or subsystems use ENODEV where I think ENOTTY or EINVAL or some other error would be more appropriate, but if you are careful to make the distinction for your new syscalls then you can document it.

--apb (Alan Barrett)

Home | Main Index | Thread Index | Old Index