changing EINVAL for SIOCSIFCAP to something else

[Yar Tikhiy]

On Mon, Feb 27, 2006 at 01:00:31PM +0300, Gleb Smirnoff wrote:
> 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.

This interpretation sounds fair to me.  Did you look at other cases
when ENODEV was returned?  How consistent were they with this one?

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

-- 
Yar