| Message ID | 201601220013.AA00000@WIN-5MHF4RKU941.jp.fujitsu.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Jan 22, 2016 at 09:13:25AM +0900, Tsutomu Itoh wrote: > ENOTSUPP should not be returned to the user program. > (cf. include/linux/errno.h) > Therefore, EOPNOTSUPP is used instead of ENOTSUPP. I'm not sure that EOPNOTSUPP is the right error code here. I'd rather make it EINVAL, the bug we're talking about is a new type of inode outside of the S_IFMT bits. "not supported" would mean we don't support it but we could in theory. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, David, On 2016/01/22 23:00, David Sterba wrote: > On Fri, Jan 22, 2016 at 09:13:25AM +0900, Tsutomu Itoh wrote: >> ENOTSUPP should not be returned to the user program. >> (cf. include/linux/errno.h) >> Therefore, EOPNOTSUPP is used instead of ENOTSUPP. > > I'm not sure that EOPNOTSUPP is the right error code here. I'd rather > make it EINVAL, the bug we're talking about is a new type of inode > outside of the S_IFMT bits. "not supported" would mean we don't support > it but we could in theory. Thanks for review. In the meaning that btrfs-send is not supporting a new type of inode now, EOPNOTSUPP is acceptable, I think. Thanks, Tsutomu -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jan 25, 2016 at 11:23:51AM +0900, Tsutomu Itoh wrote: > Hi, David, > > On 2016/01/22 23:00, David Sterba wrote: > > On Fri, Jan 22, 2016 at 09:13:25AM +0900, Tsutomu Itoh wrote: > >> ENOTSUPP should not be returned to the user program. > >> (cf. include/linux/errno.h) > >> Therefore, EOPNOTSUPP is used instead of ENOTSUPP. > > > > I'm not sure that EOPNOTSUPP is the right error code here. I'd rather > > make it EINVAL, the bug we're talking about is a new type of inode > > outside of the S_IFMT bits. "not supported" would mean we don't support > > it but we could in theory. > > Thanks for review. > > In the meaning that btrfs-send is not supporting a new type of inode now, > EOPNOTSUPP is acceptable, I think. It is, there's a warning message printed anyway, the actual error code does not matter much. Reviewed-by: David Sterba <dsterba@suse.com> -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c index 63a6152..b4229e8 100644 --- a/fs/btrfs/send.c +++ b/fs/btrfs/send.c @@ -2576,7 +2576,7 @@ verbose_printk("btrfs: send_create_inode %llu\n", ino); } else { btrfs_warn(sctx->send_root->fs_info, "unexpected inode type %o", (int)(mode & S_IFMT)); - ret = -ENOTSUPP; + ret = -EOPNOTSUPP; goto out; }
ENOTSUPP should not be returned to the user program. (cf. include/linux/errno.h) Therefore, EOPNOTSUPP is used instead of ENOTSUPP. Signed-off-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com> --- fs/btrfs/send.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)