_IOWR when errno != 0

[Scott Long]

On Apr 13, 2010, at 9:45 PM, Bruce Evans wrote:
> On Tue, 13 Apr 2010, John Baldwin wrote:
> 
>> On Monday 12 April 2010 8:26:48 pm Xin LI wrote:
>>> On 2010/04/12 16:33, Alfred Perlstein wrote:
>>>> * Xin LI <delphij at delphij.net> [100412 15:28] wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> Is there a sane way to copyout ioctl request when the returning errno !=
>>>>> 0?  Looking at the code, currently, in sys/kern/sys_generic.c, we have:
> 
> No.  You could just do it, but this would be insane since it would
> just waste time.
> 
>>>>> 
>>>>> ===========
>>>>>       error = kern_ioctl(td, uap->fd, com, data);
>>>>> 
>>>>>       if (error == 0 && (com & IOC_OUT))
>>>>>               error = copyout(data, uap->data, (u_int)size);
>>>>> ===========
>>>>> 
>>>>> Is there any objection if I change it to something like:
>>>>> 
>>>>> ===========
>>>>>       saved_error = kern_ioctl(td, uap->fd, com, data);
>>>>> 
>>>>>       if (com & IOC_OUT)
>>>>>               error = copyout(data, uap->data, (u_int)size);
>>>>>       if (saved_error)
>>>>>               error = saved_error;
>>>>> ===========
> 
> errno != 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 != 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 
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