Re: [PATCH v4] Staging: comedi: convert while loop to timeout inni_mio_common.c

From: Ian Abbott
Date: Thu Jan 16 2014 - 06:08:32 EST


On 2014-01-16 02:30, Greg KH wrote:
On Wed, Jan 15, 2014 at 06:29:21PM +0000, Hartley Sweeten wrote:
On Tuesday, January 14, 2014 8:59 PM, Greg KH wrote:
Sleep for at least 10, as I think that's the smallest time delay you can
sleep for anyway (meaning it will be that long no matter what number you
put there less than 10, depending on the hardware used of course.)

A bit off topic here but I have a somewhat related question about timeouts.

There are a number of comedi drivers that do a "wait for end-of-conversion"
as part of the (*insn_read) for an analog input subdevice or (*insn_write) for
an analog output subdevice. These functions return an errno if a timeout occurs.

Currently either -ETIME or -ETIMEDOUT is returned. This errno ends up getting
returned to the user as the result of the unlocked_ioctl file operation. What is
the more appropriate errno? Or is there is better one that should be used?

I think they should all be -ETIMEDOUT, -ETIME is used for something
else, and shouldn't be sent to userspace as I don't think it knows what
to do with it.

Linux libc ought to deal with both. glibc 2.17 has the following error strings in the "C" locale:

ETIMEDOUT --> "Connection timed out"
ETIME --> "Timer expired"

I think BSD has:

ETIMEDOUT --> "Operation timed out"
ETIME doesn't exist

so -ETIMEDOUT is better, even though the error string is a bit dodgy in some cases under Linux. This betrays the original purpose of the ETIMEDOUT error code, in the same way that the identifier and original purpose of the ENOTTY error code is betrayed by the original error string "Not a typewriter" (which is now "Inappropriate ioctl for device" in current glibc).

--
-=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@xxxxxxxxx> )=-
-=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/