From owner-freebsd-amd64@FreeBSD.ORG Thu Mar 24 20:39:42 2011 Return-Path: Delivered-To: amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54E78106566B for ; Thu, 24 Mar 2011 20:39:42 +0000 (UTC) (envelope-from john@feith.com) Received: from feith1.FEITH.COM (feith1.FEITH.COM [192.251.93.1]) by mx1.freebsd.org (Postfix) with ESMTP id 699178FC21 for ; Thu, 24 Mar 2011 20:39:40 +0000 (UTC) Received: from jwlab.FEITH.COM (jwlab.FEITH.COM [192.251.93.16]) by feith1.FEITH.COM (8.14.4+Sun/8.12.9) with ESMTP id p2OKJZNd012983; Thu, 24 Mar 2011 16:19:35 -0400 (EDT) (envelope-from john@jwlab.FEITH.COM) Received: from jwlab.FEITH.COM (localhost [127.0.0.1]) by jwlab.FEITH.COM (8.13.8+Sun/8.13.8) with ESMTP id p2OLQ9NW023022; Thu, 24 Mar 2011 17:26:09 -0400 (EDT) Received: (from john@localhost) by jwlab.FEITH.COM (8.13.8+Sun/8.13.8/Submit) id p2OLQ8HM023021; Thu, 24 Mar 2011 17:26:08 -0400 (EDT) Date: Thu, 24 Mar 2011 17:26:08 -0400 (EDT) From: John Wehle Message-Id: <201103242126.p2OLQ8HM023021@jwlab.FEITH.COM> To: kostikbel@gmail.com MIME-Version: 1.0 Content-Type: text/plain X-DCC-x.dcc-servers-Metrics: feith1; whitelist X-Scanned-By: MIMEDefang 2.67 on 192.251.93.1 X-Archived: cashew X-Mailman-Approved-At: Thu, 24 Mar 2011 20:49:40 +0000 Cc: amd64@freebsd.org 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 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 20:39:42 -0000 > 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. Will do. Okay to just submit the series of patches under amd64/155903 or do you want them file under separate bug reports? > 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. I don't necessarily disagree, however that's more work than I'm planning on at the moment. > BTW, would you do the shims for other pciconf ioctls, while there ? I would have if necesary (since I was there). However at a quick glance of pciio.h it didn't appear to me to be necessary. Also I do suspect that the i386 X11 Server is making successfuly use of some of the other calls. Keep in mind that the freebsd32 layer has generic handling for those ioctl calls that don't require anything special. I believe PCIOCREAD, PCIOCWRITE, and friends fall into that category since it appears the structures don't change size or alignment between i386 and amd64 (mind you this was based just on a quick glance at the header). -- John ------------------------------------------------------------------------- | Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | | John Wehle | Fax: 1-215-540-5495 | | -------------------------------------------------------------------------