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