Erik Andersen (
Tue, 23 Sep 1997 16:56:39 -0600 (MDT)

Oops. Looks like I mis-understood what you meant. Sorry. If there
really is no "Device does not implement this functionality that should
normally be supported by this type of device" type of error
message in errno.h (I'm still at work so I can't check), then you could
submit a request to the libc folks to get something added to errno.h. I
know David VanLeewen got ENOMEDIUM and EMEDIUMTYPE added to errno.h just
because adding them was the right thing to do. Now, cdrom.c returns
them when appropriate. If ENODEV truly means "No device", then getting a
new error code added to libc would be appropriate.


Erik B. Andersen   Web: 
--This message was written using 73% post-consumer electrons--

On Wed, 24 Sep 1997, Gerd Knorr wrote:

> On Tue, 23 Sep 1997, Erik Andersen wrote: > > > I believe you are looking for ENOSYS. > > > > As one of the things I am doing in my ever-expanding-in-scope > > CD include patch (see > > is to return ENOSYS for non-implemented functions instead of > > EINVAL. > > Hmm, not exactly. "not implemented" (in the driver) is a bit different > from "drive can't do". > > > Grep /usr/include/asm/errno.h some time and you will > > have your eyes opened to all the official things that can go wrong. > > I *did* check this. Is there some standard paper which tells what the > error codes mean? Lets take ENODEV as example. linux errno.h says: > > #define ENODEV 19 /* No such device */ > > According to some other mail I got glibc 2.1 says: > > ENODEV = "Operation not supported by device" > > One of them is completely wrong... > > glibc is newer and probably checked against posix, so I think I'll take > ENODEV. > > Gerd > >