Subject: Re: ENXIO or ENODEV when r-opening a w-only device?
To: Chapman Flack <nblists@anastigmatix.net>
From: Garrett D'Amore <garrett_damore@tadpole.com>
List: tech-kern
Date: 01/04/2006 17:29:28
Not at all surprised about EINVAL -- I think its what a
naive-non-standards concerned implementation would use.  (It was what
came first to my mind -- think "Invalid operation".

ENODEV still seems like the "correct" operation, though, after reading
the relevant docs.  I also wouldn't worry too much about prior art here
-- in all likelihood the vast majority of cases check only for success
or failure, and the exact error code returned by open() is likely to be
ignored or just printed (ala perror) without much handling.  (The
exception to this being EINTR, which often does get special handling in
the form of a retry.)

The reality is that there are a lot of different error codes that open()
can return, and the set is not the same on all OS', so portable
applications should generally not try to behave too much based upon the
value of errno.

    -- Garrett

Chapman Flack wrote:

> Steven M. Bellovin wrote:
>
>> What do you get if you open a device on a read-only file system for 
>
>
> Umm, EROFS. But again, that has kind of a specific meaning that
> isn't what I mean.
>
>> writing?  A CD-Ro for writing?  I'd return the same error.
>
>
> I put a cd into cd0, and open("/dev/rcd0a",O_WRONLY) succeeded. :/
> Then write(2) returned ... EINVAL.   EINVAL?  I had my money on
> ENXIO. :)
>
> man 2 write:
>
>     [EINVAL]   The pointer associated with d was negative.
>
>     [EINVAL]   The total length of the I/O is more than can be
>                expressed by the ssize_t return value.
>
> SUS:
>
> The write() and pwrite() functions may fail if:
>
> [EINVAL]
>    The STREAM or multiplexer referenced by fildes is linked
>    (directly or indirectly) downstream from a multiplexer.
>
> The more I think about this, the less I seem to understand. I
> think I expected the question to be easier, more settled-like. :)
>
> -Chap



-- 
Garrett D'Amore                          http://www.tadpolecomputer.com/
Sr. Staff Engineer          Extending the Power of 64-bit UNIX Computing
Tadpole Computer, Inc.                             Phone: (951) 325-2134