On Wed, 15 Mar 2000, Jeff Hartmann wrote:
> Doug Rabson wrote:
> > The main problem is that the size argument to the various _IOW and _IOWR
> > macros is wrong. The header agpgart.h uses pointers for this argument
> > where it should use the base type. The sizeof this type is used by some
> > operating systems to automate the copying of date to/from the user address
> > space.
> > For instance, the current declaration:
> > _IOR(AGPIOC_BASE, 0, agp_info*)
> > specifies that sizeof(agp_info*) bytes of information are generated by the
> > ioctl. Since the ioctl is really providing sizeof(agp_info) bytes of
> > information, this is a problem.
> > The correct declaration should be:
> > _IOR(AGPIOC_BASE, 0, agp_info)
> > This is a fairly trivial issue and can probably be patched by the Linux
> > emulation layer of FreeBSD but I think it ought to be fixed since it
> > obscures what is really going on in the ioctl and may even break in a
> > future Linux kernel implementation of ioctl.
> Sounds completely reasonable. I'll take a look at it.
Thanks. Fixing this will change the ABI so you might want to support the
old ioctl numbers too for a while.
> > The main problem with the agpgart ioctl api is that it seems to require
> > that the driver can maintain a certain amount of state per open file. This
> > is not possible in FreeBSD due to the way that drivers are used by the
> > kernel and may also be a problem for other operating systems.
> Interesting. Having a private data area per each open file is quite
> useful. I've never looked at the Freebsd kernel, but can you at least
> get the number of the open file doing the ioctl? You could do the
> storage of data based on that.
Unfortunately, the drivers are insulated from this information. We have
been thinking of changing the device driver interface for FreeBSD 5.0 but
that won't be released for at least a year and probably won't allow
per-open-file private data either.
To support the DRI (which has similar requirements), I did some handwaving
and looked up the private data based on the pid but its not very
> > In practice, I'm intending to only support a subset of the agpgart api in
> > order to allow the X server to use AGP memory for e.g. i810 frame buffers
> > etc. For multiple client support, I will probably rely on the DRI
> > interfaces.
> Sounds reasonable. Another thing that was suggested by David Dawes is a
> os independant layer for agp functionality. I think this becomes quite
> important if the exact interface can not be replicated under other
> os'es. Perhaps its time to look at doing something like this in Xfree.
I think this is the best solution since it can leverage the authentication
aspects of XFree. On the other hand, isn't this exactly what the DRI
interface to AGP does now?
Doug Rabson Mail: dfr@...
Technical Director, Qube Software Ltd. Phone: +44 171 431 9995