On Mon, Apr 01, 2002 at 07:38:18AM -0700, Jens Owen wrote: > Alan Hourihane wrote: > > > > On Fri, Mar 29, 2002 at 09:21:52PM -0700, Jens Owen wrote: > > > I've checked into the drmcommand-0-0-1-branch the complete conversion of > > > the Radeon driver suite to the drmCommand interface. Take a look, and > > > let me know if you see any problems, or if you have any questions. > > > > > > If anyone is interested in converting any of the other drivers, please > > > let me know and we'll coordinate the work. I won't be able to get to > > > any of the other drivers until sometime next week. > > > > > Jens, > > > > I see you've got the four drmCommand*() functions but I'm wondering > > if there's a need for these 4 and it could be reduced to just the one. > > > > The command itself identifies it's direction - so why do we specifically > > need to pass this ? > > Alan, > > My original definition of the functions encoded alot of information just > like a regular Linux IOCTL. In addition to the request index, it also > included the device type, direction of data transfer and size of data > structure. However, with the concern about the interface not being > generic, I broke away from the Linux encoding and made the interface > very generic. Now, the function is only the request index and does > contain the direction of other information. This also addresses any > potential concern about the overhead of decoding and re-encoding bit > fields for none Linux OS's. My think was to be explicit with each > parameter and encode it at the OS dependent level inside the drmCommand > implementation. > > We could add an additional parameter for direction, and get down to one > call...but I didn't know how important that was vs. the overhead of > creating run time conditions for something that was static at compile > time. > > > We could just do drmCommand(fd, FUNCTION, NULL, NULL); for the current > > drmCommandNone() call to keep the interface the same. > > If we encode the size and type as well, we get back to the original > Linux semantics that made everyone scream that this wasn't portable. I > believe EVERYTHING we've covered to date is portable. One extreme is > the Linux semantics I started with...the other is what I've got now, > very generic semantics. You're suggesting something in the middle. I'm > good with any of these solutions, but I would like to avoid changing > this more than once, just from a development time perspective. > O.k. Understand what your saying.
Alan. _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
