From owner-freebsd-amd64@FreeBSD.ORG Thu Mar 24 15:40:03 2011 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99259106564A for ; Thu, 24 Mar 2011 15:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 84C5F8FC0C for ; Thu, 24 Mar 2011 15:40:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p2OFe3oE096326 for ; Thu, 24 Mar 2011 15:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p2OFe3CC096324; Thu, 24 Mar 2011 15:40:03 GMT (envelope-from gnats) Date: Thu, 24 Mar 2011 15:40:03 GMT Message-Id: <201103241540.p2OFe3CC096324@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: Mark Linimon X-Mailman-Approved-At: Thu, 24 Mar 2011 15:59:08 +0000 Cc: Subject: Re: amd64/155903: FreeBSD32 emulation patch to support i386 X11 Server X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mark Linimon List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 15:40:03 -0000 The following reply was made to PR amd64/155903; it has been noted by GNATS. From: Mark Linimon To: bug-followup@FreeBSD.org Cc: Subject: Re: amd64/155903: FreeBSD32 emulation patch to support i386 X11 Server Date: Thu, 24 Mar 2011 10:34:30 -0500 ----- Forwarded message from Kostik Belousov ----- Date: Thu, 24 Mar 2011 13:27:07 +0200 From: Kostik Belousov To: John Wehle Cc: amd64@freebsd.org Subject: Re: amd64/155903: FreeBSD32 emulation patch to support i386 X11 Server User-Agent: Mutt/1.4.2.3i All of this looks interesting. First, please split the patch into smaller, logically self-contained parts. E.g. the change to handle fdrop() in one place should be committed separately. Then, I propose to add the compat definitions of MEMRANGE_GET32, SET32 and PCIOCGETCONF_32. Then, we could move the copyin_map/copyout_map. Also, we could fix the sz == 0 case. The last commit is the most controversial, in fact. I understand the reason to get the user memory for calling into pciconf ioctls, but this is somewhat ugly. Ideally, the pci_ioctl() would be changed into wrapper and core code, and two wrappers produced, one for the native call path, other for compat32. BTW, would you do the shims for other pciconf ioctls, while there ? ----- End forwarded message -----