cvs commit: src/sys/dev/atkbdc atkbd.c src/sys/dev/digi digi.c src/sys/dev/kbdmux kbdmux.c src/sys/dev/syscons scvidctl.c syscons.c src/sys/dev/uart uart_kbd_sun.c src/sys/dev/usb ukbd.c src/sys/dev/vkbd vkbd.c src/sys/fs/procfs procfs_ioctl.c ...

[Ruslan Ermilov]

On Wed, Sep 27, 2006 at 05:52:56PM -0400, John Baldwin wrote:
> Could you avoid IOWINT by just assuming that any _IO() ioctl is getting an int 
> as the arg?
> 
There are some _IO() ioctls that pass a pointer to variable sized data,
and their ioctl handlers to uiocopy'ing rather than ioctl().  See
sys/cam/scsi/scsi_ses.c, SESIOC_* ioctls for one such example.

> If an ioctl doesn't use the arg, then you don't lose anything.. 
> do we have any ioctl's that use the arg directly but not as an int?
> 
Unfortunately yes.

> The 
> ioctl(2) manpage implies that 'data' is either a pointer or an int.  If you 
> go this route, you avoid changing all the ioctl values, basically just assume 
> that IOC_VOID means the argument is an int.
> 
That has been considered and found impossible due to the above.
We also don't have any spare bits left in the ioctl type field,
so IOC_VOID with size == sizeof(int) have been used to implement
_IOWINT().  IOC_VOID is incorrect name, the argument should either
be a pointer or an "int", even when not used by ioctl().  Some
ioctl() calls to "void" ioctls in userland don't pass a third
argument.  I think on architectures that pass arguments on the
stack (such as i386) this causes return address to be accessed
instead of the argument value.  Ioctls that are "void" should
either pass "0" or "NULL".


Cheers,
-- 
Ruslan Ermilov
ru at FreeBSD.org
FreeBSD committer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-all/attachments/20060927/935ce1f2/attachment.pgp