On Thu, Mar 28, 2002 at 11:15:25AM -0500, David Dawes wrote: > On Thu, Mar 28, 2002 at 09:31:40AM +0000, Alan Hourihane wrote: > >On Wed, Mar 27, 2002 at 07:22:40 -0700, Jens Owen wrote: > > >Also, we should be able to hide the type in the Linux os support and > >not need to pass this ? > > > >I've just taken a closer look at the xf86drmRadeon.c code, and in > >drmRadeonCPStop we're issuing 3 ioctl's to flush, and idle the CP. > > > >Going down this road though, we'll be pushing that back into the 2d/3d code > >which I don't think is the right way to go. > > > >I'm thinking more of Jeff's solution now, and what we could do..... > > > >If we take a minimalist xf86drm.c which makes the libdrm.a loadable > >module. Then within xf86drm.c we identify which sub-drm module to > >load (i.e. the driver's libradeon_drm.a - or something like that) and > >load it. For the *BSD's this code is a symlink from the Linux directory. > > 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. > > 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? > > 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? > > 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.
Thank you David. I was just starting to write up my thoughts, and found that you've covered everything that I was concerned about. So, I would like to echo David's concerns and look forward to hearing more about the motivation for the proposed changes. Thanks, Kevin ------------------------------------------------------------------------ Kevin E. Martin Core Team Member, The XFree86 Project, Inc. Chapel Hill, NC Senior Software Architect, Red Hat, Inc. _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
