On Sun, 2003-10-26 at 16:06, Jon Smirl wrote: > This is the start of a patch to get a few more things out of the driver that I > need. I thought I'd run it by you before implementing the rest of it. I need to > get hardware info including PC IDs, interrupt number, mmio and framebuffer > locations. Since we don't want to use any more generic IOCTLS I modified the > GetStats call to return the hw info as statistics. You may have a better > solution for doing this. > > Also, I noticed that the GetStat IOCTL is flawed in it's extensibility. The > first field in drm_stats_t should have been a size which is set to > sizeof(drm_stats_t) on input. If this was the case the structure could have > easily been expanded. Instead I have to use a more complicated scheme based on > the interface version. > > The behavior of drmGetStats() is unchanged, drmGetHardwareInfo() just shared > the GetStat IOCTL since all of the data needed fits into the same format.
Where is drmGetHardareInfo()? If the DRM is copy_to_usering more data in the 1.1 interface verision, the drmGetStats needs to be passing a larger struct in so that other data won't be overwritten or EFAULT generated, right? Also, the 1.1 interface has already gone downstream to at least one destination (FreeBSD) so it would call for another minor bump, since there are side effects. However, I'm not so sure about using the stats ioctl for this. Do we need to be overloading things in the name of ioctl management? We've used up 3/4 of the generic ioctl space from 0x0 to 0x40, and have 0x80-0xff still. Also, couldn't we also use another DRM_IOCTL_BASE if we somehow, some day ran out of ioctl space in the current one? I just don't want to make our interfaces cruftier if we don't have to (or unless it's for a good cause, such as encouraging removal of bad interfaces in the future :) > After getting the hardware info I need one final change. I need to make the > radeon DRM driver report it's name as r200 when it is on r200 hardware and > radeon otherwise. This will let my generic boot code take the driver name, tack > _dri.so on to it, and load the right DSO. Alternatively I could modify the DRM > code to build two ATI drivers: radeon and r200; each containing their > respective PCI IDs. Which scheme is better? I don't think the kernel should be making the decision of telling userland what the client driver name should be. What if we decide to merge radeon and r200 DSOs at some point? Does your generic boot code actually have nothing radeon-specific? -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ------------------------------------------------------- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
