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

[John Baldwin]

On Wednesday 27 September 2006 17:03, John Baldwin wrote:
> Eh?  You just changed ioctl values breaking ABI all over the place, e.g. 
> sys/pioctl.h.  The size field changed from 0 to sizeof(int) meaning
> different ioctl values and thus ABI breakage.

Bah, I see you did add compat hacks for the old ioctls.  I don't see why we 
don't just fix the original ioctls to just use IOCPARM_IVAL() and be done 
with it, why do we have to add _IOWINT() and other hacks?

> Plus, what if you have: 
> 
> 	struct foo {
> 		int bar;
> 	};
> 
> #define FOOIO	_IOW('y', 0, struct foo)
> 
> that's going to have the same issue isn't it?

Ok, see now why this works.  This is only for ioctl's that use int w/o 
specifying it (i.e. take an int directly instead of pointer to int).

> I think instead the various ioctl handlers have to realize that for IOC_VOID 
> ioctls declared using _IO() data is a (caddr_t *), not an (int *) (the uap 
> struct for ioctl clearly defines data as a caddr_t).  Fix whatever crap you 
> have to in the kernel to deal with it, but don't change the userland ABI. :(

I still think doing this (via IOCPARM_IVAL()) is best and is probably a much 
smaller diff.

-- 
John Baldwin