[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netbsd-tech-kern
Subject:    Re: fdiscard error cases
From:       Alan Barrett <apb () cequrux ! com>
Date:       2014-07-27 8:56:12
Message-ID: 20140727085612.GH2411 () apb-laptoy ! apb ! alt ! za
[Download RAW message or body]

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)
[prev in list] [next in list] [prev in thread] [next in thread]