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 ...
ru at freebsd.org
Wed Sep 27 15:12:52 PDT 2006
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?
> 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".
ru at FreeBSD.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20060927/935ce1f2/attachment.pgp
More information about the cvs-src