[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
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
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)
Main Index |
Thread Index |