On Thu, Mar 25, 2010 at 9:49 PM, Jakob Bornecrantz <wallbra...@gmail.com> wrote: > On Thu, Mar 25, 2010 at 7:00 PM, George Sapountzis > <gsapount...@gmail.com> wrote: >> On Thu, Mar 25, 2010 at 7:58 PM, Jakob Bornecrantz <wallbra...@gmail.com> >> wrote: >>> 0003 moves drisw into dri/sw and the drm dri files into dri/drm, yet >>> again for clarity. >>> >>> 0004 moves the common files into a common directory. >>> >> >> I think that it may be better to just consolidate dri_screen.c / >> dri_context.c / dri_drawable.c / dri_extension.c in a single file >> named dri.c or dri_api.c or dri_driver_api.c similar to the glx/xlib >> state_tracker. There is not much left in the above files after >> splitting out version-specific code. >> >> Then you will have: >> dri_api.c or dri_driver_api.c for the DRI "window system" binding >> dri_st_api.c >> and >> dri1.c dri2.c drisw.c for the different versions >> >> the only outlier is dri1_helper which I agree may have a better name. >> >> But then I looked at this a lot lately and your suggestion may be >> better for someone looking at it after some time. > > I think you can do both, the moving of the files is more for making it > blatantly clear what is going on. The common files live in the common > directory and the rest are in their own directory. This mirrors what > is done in egl. > > I'm ambivalent about grouping the files together. And I don't think > that moving them it a common directory stops us from doing either one. > Then again dri_extension.c is quite useless, and should probably be > moved into dri_screen either way. > > Are you strongly against the layout that I suggested? I have no real > problem with doing both? >
Ah ok, then the suggested layout serves well its purpose. Wrt to consilidating in dri_driver_api.c (dri_util.c is effectively dri_api.c), it depends on what your plans are for st/dri and if it involves adding more common code, I don't have other plans for st/dri :-) I'll add a comment about the ifdef's (srceen / swap_buffers in dri_screen.c, flush_front / alloc_buffers in dri_st_api.c) and to drisw_util.h about its relationship to dri_util.h . >> >>> One thing that could be done to reduce the amount of #ifdefs would be >>> to move the tables from dri_screen.c into drisw.c and dri2.c. >> >> yes, this could be done unless the suggestion above is adopted, in >> which case I thinks it's probably better to keep all the dri_ >> functions static and the _DriverAPI tables in the common file. > > There is only one function that is static that is used in the tables, > or are you meaning that we should make them static as we move all of > them into a single file? > yes, if we move them all to dri_driver_api.c then it makes more sense to make them static and keep _DriverAPI in dri_driver_api.c with an ifdef. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
