Dave Airlie wrote: > >>> i've thought about this, we probably need to make handle hashing a >>> driver option, if a driver is currently safe then we can just set it >>> by default for that driver, however otherwise we should use a >>> setparam from the DDX to tell the driver that the DDX is at least >>> safe or not .. >> >> >>> In this way and old 2D driver isn't going to fall over hopefully.. >> >> >> But how do we make 3D drivers that are not safe fail gracefully >> without upping the major? > > > Well if you get a new DDX upgrade and still have an old 3D driver, it > is acceptable to not let the 3D driver run, if you don't get the DDX > upgrade the kernel should fall back to old non hashed code and old 3D > drivers should run.. > So the DDX upgrade would bump the DRIDDX major to make the old 3D driver fail gracefully.
> Updating anything in the kernel shouldn't break userspace, updating > the DDX can break 3D drivers, upping the DRM cannot. > > I don't think we can really ever do a DRM major number upgrade without > major problems.. > We've done once for the via code. People just tend to understand that to get DRI or XvMC with their new kernel they need to upgrade their DDX, and they happily (?) upgrade. The problem is distros that aren't aware of pitfalls with a DRM upgrade or simply don't care. Another option is to try to keep the current functionality, setting (handle == physical address) for 32 bit mappings of device addresses, and squeeze 64-bit device addresses and TTMs into the window starting at 0x10000000. I think this is the route of minimal impact, but it means that we'll probably never fix the faulty DRI drivers. /Thomas > Dave. > ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
