changing EINVAL for SIOCSIFCAP to something else

[Gleb Smirnoff]

On Mon, Feb 27, 2006 at 12:44:58PM +0300, Yar Tikhiy wrote:
Y> > On Mon, Feb 27, 2006 at 10:04:28AM +0100, Andre Oppermann wrote:
Y> > A> > I prefer this variant:
Y> > A> > 
Y> > A> >                 if (ifp->if_ioctl == NULL)
Y> > A> >                         return (ENOTTY);
Y> > A> >                 if (ifr->ifr_reqcap & ~ifp->if_capabilities)
Y> > A> >                         return (ENODEV);
Y> > A> > 
Y> > A> > Any objections?
Y> [...]
Y> > Y> I'm afraid that this is a case when EINVAL is used properly: an
Y> > Y> argument to ioctl doesn't make sense to a particular device.  It's
Y> > Y> true that EINVAL may be abused in other places though.  I wish each
Y> > Y> EINVAL being returned to the userland were accompanied by log().
Y> > 
Y> > I don't agree. EINVAL can logically fit to almost any error condition. We
Y> > should fine error codes fitting better. If "ioctl doesn't make sense to a
Y> > particular device", then we should say "Operation not supported by device",
Y> > which is ENODEV.
Y> 
Y> You see, it isn't ioctl itself that doesn't make sense to the device,
Y> it's a single argument, ifr_reqcap.  That was my point.  Of course,

Yes. The ioctl is correct, that's why we do not return ENOTTY. The
argument is correct, that's why we do not return EINVAL. The argument
is not applicable to this device, that's why I suggest to use ENODEV.

Y> I won't insist on it because the traditional errno is getting very
Y> limited under the present conditions anyway.

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE