Date: Mon, 27 Feb 2006 13:00:31 +0300 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Yar Tikhiy <yar@comp.chem.msu.su> Cc: arch@FreeBSD.org, Andre Oppermann <andre@FreeBSD.org>, jlemon@FreeBSD.org Subject: Re: changing EINVAL for SIOCSIFCAP to something else Message-ID: <20060227100031.GY55275@cell.sick.ru> In-Reply-To: <20060227094458.GH6435@comp.chem.msu.su> References: <20060227083815.GW55275@cell.sick.ru> <20060227091417.GF6435@comp.chem.msu.su> <20060227083815.GW55275@cell.sick.ru> <4402C09C.C3FB0064@freebsd.org> <20060227093431.GX55275@cell.sick.ru> <20060227094458.GH6435@comp.chem.msu.su>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060227100031.GY55275>