Re: changing EINVAL for SIOCSIFCAP to something else

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
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages