comioctl() (sys/dev/isa/com.c v1.60, line 447) first tries the ldisc-specific
ioctl and then ttioctl(), and only if both fail with an error < 0 it
interprets the command itself, giving ENOTTY if it doesn't recognize the
command either. At least ttioctl() contains a ttysleep(), which may be
interrupted (e. g. timeout), resulting in ERESTART (?) == -1;
undistinguishable from the -1 returned meaning "don't know how to handle that
command". IMHO an interrupted ioctl shouldn't return ENOTTY; at least my old
X server is very puzzled:

(fd 6 is the mouse, and X shuts itself down right after this)

   159 XF86_S3  CALL  write(0x6,0xaf73,0x2)
   159 XF86_S3  GIO   fd 6 wrote 2 bytes
       "*X"
   159 XF86_S3  RET   write 2
   159 XF86_S3  CALL  ioctl(0x6,TIOCGETA,0xf7bfc3f4)
   159 XF86_S3  RET   ioctl 0
   159 XF86_S3  CALL  ioctl(0x6,TIOCSETAW,0xf7bfc3f4)
   159 XF86_S3  PSIG  SIGTERM caught handler=0x48f6c mask=0x0 code=0x0
   159 XF86_S3  RET   ioctl -1 errno 25 Inappropriate ioctl for device
   159 XF86_S3  CALL  sigreturn(0xf7bfc344)
   159 XF86_S3  RET   sigreturn JUSTRETURN

The same ioctl succeeded a few lines above. Is my theory correct and if it
is, could we please change the ioctl return value semantics to be able to
distinguish an interrupted ioctl from an unrecognized one ?

	Torsten