What would be the preferable error to return
on open for reading of a write-only device?

From man 2 intro:

 6 ENXIO No such device or address.  Input or output on a special file
         referred to a device that did not exist, or made a request beyond
         the limits of the device.  This error may also occur when, for
         example, a tape drive is not online or no disk pack is loaded on
         a drive.

 19 ENODEV Operation not supported by device.  An attempt was made to
         apply an inappropriate function to a device, for example, trying
         to read a write-only device such as a printer.

From man 2 open:

 [ENXIO] The named file is a character special or block special
         file, and the device associated with this special file
         does not exist, or the named file is a FIFO,
         O_NONBLOCK and O_WRONLY is set and no process has the
         file open for reading.

ENODEV looks much more like what I want, but it's not listed as a
possible return for open(2). Does anyone know if there's any existing
precedent that just hasn't made it into the man page?  Should I just
use ENXIO even though it doesn't seem to fit as well?  There is a
precedent for that: I've noticed ugen returns ENXIO if you try to open
an endpoint in the wrong direction. On the other hand, a lot of one-way
devices seem to let the open succeed even though it's silly, and then
the read(2) or write(2) fails later with ENXIO. Is that the best model
to follow?

FWIW, the SUSv3 definitions are very similar (2.3, Error Numbers):

[ENODEV]
    No such device. An attempt was made to apply an inappropriate
    function to a device; for example, trying to read a write-only
    device such as a printer.

[ENXIO]
    No such device or address. Input or output on a special file
    refers to a device that does not exist, or makes a request
    beyond the capabilities of the device. It may also occur when,
    for example, a tape drive is not on-line.

and SUS also does not list ENODEV as a return for open(2), but
it does say:

  The ERRORS section on each reference page specifies whether
  an error shall be returned, or whether it may be returned.
  Implementations shall not generate a different error number
  from the ones described here for error conditions described
  in this volume of IEEE Std 1003.1-2001, but may generate
  additional errors unless explicitly disallowed for a
  particular function.

One way to read that would be that ENODEV would be ok from open,
as it's not disallowed, none of the errors described for open
quite matches the situation, and the description for ENODEV
matches it perfectly. But I hate to do something unprecedented.
Opinions?

Thanks,
-Chap