On Thu, Mar 28, 2002 at 11:15:25 -0500, David Dawes wrote: > I'm losing track of what the goal was with the changes. If it was > to remove hw-specifics from the libdrm.a module, then I think Jeff's > idea of pushing them into a separate HW-specific module is worth looking at. > By doing this, it might even be feasible to make libdrm.a part of the > (built-in) OS-support layer. > That's the goal. Yes, and potentially we could move libdrm.a into the built-in OS-support layer. We'd need to check there isn't anything obvious that would need an upgrade as part of a video driver upgrade within that module.
> Stepping back a bit, the current model puts different types of > dependencies in different places. The XFree86 video driver module > contains HW dependencies, but should have no OS dependencies. The libdrm.a > module contains both HW and OS dependencies. I guess the aim is to > separate that into the HW-dependent and HW-independent pieces? > Correct. > One problem I had with simply changing the libdrm.a interfaces is > that it doesn't succeed in making that separation. Something in > libdrm.a still needs to know how to translate a HW-specific command > into whatever is appropriate for the OS. I.e, there's nothing > conceptually different between drmRadeonCPStop(args) and > drmCOMMAND(RADEON_CP_STOP, args), unless the token RADEON_CP_STOP > can be passed transparently to the HW+OS specific component that > will actually do the requested operation. > > With Jeff's suggestion there would be several components: > > video driver module (HW specific, OS independent) > core libdrm module (HW independent, OS specific, so part of core server?) > HW libdrm module (HW specific, OS specific) > > The question this raises is what do we gain from this? What would > actually be in the core libdrm module -- is there enough there to > justify separating out the HW-specific parts? > Correct in your assesment. Whether there's enough there or not, we end up stamping on another's drivers toes if we replace libdrm.a as part of some other driver upgrade, and potentially introduce a regression as it currently stands. xf86drm.c is what would be in libdrm.a, and then the other files like xf86drmRadeon.c would form libradeon_drm.a etc. But looking at xf86drm.c - things in there haven't changed in a while so it looks good to incorporate that into the core server and remove the libdrm.a module. > If the HW libdrm module could be made HW specific and OS independent, > then that would be a big win, and it could even be moved into the > video driver module in that case. This would simplify things to > the point where the OS-specific parts are built-in to the X server > and the HW specific parts are all in the video driver module. > Correct again, although we're facing the kernel interface with libdrm, and to abstract it to a point of OS indepedence could be a performance hit, and certainly a struggle with all the OS'es out there. I'd vote for moving the code from xf86drm.c into the os-support layer and creating HW specific lib*_drm.a modules. Alan. _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
