On Thu, Mar 24, 2011 at 05:26:08PM -0400, John Wehle wrote: > > 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? Simply mail the patches to me, with some words attached. I will land them into the tree.
> > > 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. Sigh. > > > 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). This is good answer, I wanted to make sure that ioctls that need special handling are handled. Thanks.
pgpVfblVhuta5.pgp
Description: PGP signature
