changing EINVAL for SIOCSIFCAP to something else

Yar Tikhiy yar at comp.chem.msu.su
Mon Feb 27 01:45:07 PST 2006


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

You see, it isn't ioctl itself that doesn't make sense to the device,
it's a single argument, ifr_reqcap.  That was my point.  Of course,
I won't insist on it because the traditional errno is getting very
limited under the present conditions anyway.

-- 
Yar


More information about the freebsd-arch mailing list