From owner-freebsd-arch@FreeBSD.ORG Wed Apr 14 05:03:29 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 915B9106566B; Wed, 14 Apr 2010 05:03:29 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 29F448FC0A; Wed, 14 Apr 2010 05:03:28 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.3/8.14.3) with ESMTP id o3E53ECd018824; Tue, 13 Apr 2010 23:03:14 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <20100414130627.V12547@delplex.bde.org> Date: Tue, 13 Apr 2010 23:03:14 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <463B2945-8599-4031-A7A4-E091C69E049F@samsco.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> To: Bruce Evans X-Mailer: Apple Mail (2.1078) X-Spam-Status: No, score=-1.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: Alfred Perlstein , d@delphij.net, freebsd-arch@freebsd.org Subject: Re: _IOWR when errno != 0 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 05:03:29 -0000 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 [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