0

I am implementing a Linux device driver that can have partial reads and writes. For example, the caller may have requested to read N bytes from the device, but part of the way through an error was encountered and now the driver has M bytes available to pass back to userspace.

How do I report the error back to userspace? For example, I would normally do something like return -EIO; in the event of an I/O error, but this does not tell the whole story (i.e., the caller might be interested in the fact that there still are M usable bytes).

I'm aware of the fact that setting errno isn't a thing in kernel space (see here: "'errno' undeclared" when compile Linux kernel), but is there any way that in my scenario I can return M, but also indicate the cause of the short read? How is this generally handled by other device drivers? Do you just return the error code and don't try to indicate that part of the buffer might be usable?

It'sPete
  • 5,083
  • 8
  • 39
  • 72
  • I don't know about anybody else, but I don't consider a short read to be an error at all. – Steve Summit Jun 13 '18 at 22:24
  • 2
    You'd probably have to have your short read return `M`, and then have the next call return `-EIO`. – Steve Summit Jun 13 '18 at 22:25
  • 4
    My opinion: @SteveSummit is exactly right. Most char devices return the short count (except 0, in which case they return an error code, e.g. -EIO). The error can be reported on the next read, via a separate call (ioctl() for example; compare to how sockets use `MSG_ERRQUE` flag to receive error data), or via a signal (as e.g. O_ASYNC descriptor status flag does; POSIX realtime signals are queued and can have one long or pointer as payload). I would use the ioctl() approach, with the signal as an option (also set via fcntl()); or report the error on the next read if important (data was lost). – Nominal Animal Jun 13 '18 at 22:33
  • 1
    I'd expect a short read and -EIO on the read after that. – Petr Skocik Jun 13 '18 at 23:03

0 Answers0