From owner-cvs-src@FreeBSD.ORG Wed Sep 27 21:53:04 2006 Return-Path: X-Original-To: cvs-src@freebsd.org Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14C6016A5AC; Wed, 27 Sep 2006 21:53:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6BDC43D80; Wed, 27 Sep 2006 21:52:56 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k8RLqn4Z061525; Wed, 27 Sep 2006 17:52:52 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Ruslan Ermilov Date: Wed, 27 Sep 2006 17:52:56 -0400 User-Agent: KMail/1.9.1 References: <200609271957.k8RJv25Z028902@repoman.freebsd.org> <200609271710.51869.jhb@freebsd.org> <20060927212949.GB83490@rambler-co.ru> In-Reply-To: <20060927212949.GB83490@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609271752.57082.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 27 Sep 2006 17:52:54 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1948/Wed Sep 27 12:03:03 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx 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 ... X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2006 21:53:04 -0000 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