Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 Sep 2006 17:52:56 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        Ruslan Ermilov <ru@freebsd.org>
Cc:        cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org
Subject:   Re: 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 ...
Message-ID:  <200609271752.57082.jhb@freebsd.org>
In-Reply-To: <20060927212949.GB83490@rambler-co.ru>
References:  <200609271957.k8RJv25Z028902@repoman.freebsd.org> <200609271710.51869.jhb@freebsd.org> <20060927212949.GB83490@rambler-co.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 27 September 2006 17:29, Ruslan Ermilov wrote:
> On Wed, Sep 27, 2006 at 05:10:51PM -0400, John Baldwin wrote:
> > 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.
> > 
> 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.. 
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.

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200609271752.57082.jhb>