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.
-- /\
Jens Owen / \/\ _
[EMAIL PROTECTED] / \ \ \ Steamboat Springs, Colorado
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
