Date: Tue, 13 Apr 2010 23:03:14 -0600 From: Scott Long <scottl@samsco.org> To: Bruce Evans <brde@optusnet.com.au> Cc: Alfred Perlstein <alfred@freebsd.org>, d@delphij.net, freebsd-arch@freebsd.org Subject: Re: _IOWR when errno != 0 Message-ID: <463B2945-8599-4031-A7A4-E091C69E049F@samsco.org> In-Reply-To: <20100414130627.V12547@delplex.bde.org> References: <4BC39E93.7060906@delphij.net> <20100412233330.GC19003@elvis.mu.org> <4BC3BA48.9010009@delphij.net> <201004130853.16994.jhb@freebsd.org> <20100414130627.V12547@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 13, 2010, at 9:45 PM, Bruce Evans wrote: > On Tue, 13 Apr 2010, John Baldwin wrote: >=20 >> On Monday 12 April 2010 8:26:48 pm Xin LI wrote: >>> On 2010/04/12 16:33, Alfred Perlstein wrote: >>>> * Xin LI <delphij@delphij.net> [100412 15:28] wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> Is there a sane way to copyout ioctl request when the returning = errno !=3D >>>>> 0? Looking at the code, currently, in sys/kern/sys_generic.c, we = have: >=20 > No. You could just do it, but this would be insane since it would > just waste time. >=20 >>>>>=20 >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> error =3D kern_ioctl(td, uap->fd, com, data); >>>>>=20 >>>>> if (error =3D=3D 0 && (com & IOC_OUT)) >>>>> error =3D copyout(data, uap->data, (u_int)size); >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>=20 >>>>> Is there any objection if I change it to something like: >>>>>=20 >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> saved_error =3D kern_ioctl(td, uap->fd, com, data); >>>>>=20 >>>>> if (com & IOC_OUT) >>>>> error =3D copyout(data, uap->data, (u_int)size); >>>>> if (saved_error) >>>>> error =3D saved_error; >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > errno !=3D 0 means that the ioctl failed, so the contents of the = output > buffer (output from the kernel) is indeterminate, so only broken > applications would look at it (except merely insane ones could look > at it and not use the results). More specifically, think of ioctl as a transport mechanism for = information. The errno returned by it is a reflection of the state of the transport, = not the state of the information transported by it. Layers that use ioctl to = transport their information need to use another mechanism to relay the state of those layers and the data transported. errno !=3D 0 means that the = ioctl transport failed, period. Or In other words, the transport of = information failed. As John pointed out, if you want the client layers of ioctl to convey = their=20 status, you need to build that status into the messages that are = conveyed over the ioctl, and not overload the ioctl status. If that means = changing poorly written apps, then that's what it means. Trying to further = overload the functionality of ioctl with heuristic guesses is only going to lead = to fragility and frustration. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?463B2945-8599-4031-A7A4-E091C69E049F>