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 ...

[Bruce Evans]

On Wed, 27 Sep 2006, John Baldwin wrote:

> On Wednesday 27 September 2006 17:29, Ruslan Ermilov wrote:
>> On Wed, Sep 27, 2006 at 05:10:51PM -0400, John Baldwin wrote:
>>> I still think doing this (via IOCPARM_IVAL()) is best and is probably a
> much
>>> smaller diff.
>>>
>> You don't consider that many ioctls are initiated inside the kernel,
>> and this kernel code already uses (and passes) pointers to "int".
>> While we could fix all of our kernel (and my first patch did exactly
>> this), it's 1) very inconvenient, and 2) we cannot fix third-party
>> kernel code this way.
>
> Could you avoid IOWINT by just assuming that any _IO() ioctl is getting an int
> as the arg?  If an ioctl doesn't use the arg, then you don't lose anything..

No -- see ru@'s reply.

> do we have any ioctl's that use the arg directly but not as an int?  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.

The point of changing all the "void int" ioctls that actually pass an
int to use _IOWINT() was to get away from the horrible (kernel) API
and (user and kernel) ABI for them.  The API is so horrible that there
were no instances of correct use of it.  The complications for using
it are now mostly handled in IOCPARM_IVAL(), but we wanted to inhibit
future uses of "void int" so so changed the ABI so that new (user)
binaries use _IOWINT().  The ABI is still horrible because there aren't
enough bits to encode the types in a nice way.

Bruce