Currently filesystems that don't support discard fail with EOPNOTSUPP, devices that don't support discard fail with ENODEV, and once you get to the hardware devices that don't feel like doing TRIM fail silently (as TRIM is an advisory operation...).
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. The question is: what errnos to use for which cases? I'd originally suggested ENOSYS for the ones where it's just not implemented, but this is traditionally not appropriate (ENOSYS being meant for unimplemented whole syscalls)... another choice is to use EOPNOTSUPP for the devices that should theoretically support discard, but it was also at the same time proposed to use ENODEV for those and EOPNOTSUPP for devices where it doesn't make sense. Currently ENODEV prints "Operation not supported by device" and EOPNOTSUPP prints "Operation not supported". Traditionally EOPNOTSUPP is for sockets, of course... although that stopped being strictly true some time ago. (Then there's also ENOTSUP, which posix invented when they needed EOPNOTSUPP but didn't have it.) The devices in question are ccd, cgd (maybe), ld, raidframe, and vnd, and it might make sense to apply the same errno in sd until it gains support for the SAS equivalent of TRIM... and maybe also in other random disk devices, like the vax ones. (It's also possible that vax disks should accept and ignore discard...) 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... -- David A. Holland dholl...@netbsd.org