Eric Anholt wrote: > > On Mon, 2002-05-13 at 16:59, Jens Owen wrote: > > Eric, > > > > The watermark I would apply for measuring the success of OS-templating > > is device indepedence. If all device specific code can go into the > > shared/drm/kernel directory and only device independent code is found in > > the OS specific directories <os>/drm/kernel then this will be a huge > > step forward for the DRI. It's likely you'll end up with some OS > > specific #ifdef's in the shared directory, but if you can completely > > remove these ifdef's while supporting three or more OS's then we can be > > confident we have a great template interface, and you can focus more of > > your efforts on keeping up to date with general DRM functionality and > > less on each device specific implementation. > > The device-specific stuff (*_state.c, dma, cp, cce, etc) is almost > completely independent of OS. The changes for those are macros like > DRM_OS_IOCTL, macros for copyin/copyouts, and watching how we deal with > return codes (they're positive on BSD). There's currently an ifdef for > each of the dma/cp/cce files for linux/FreeBSD because of different list > handling, but because it's common we could put it in drm_os_*.h. > Overall there is very little changed in these files. I'm guessing that > adding Net/OpenBSD would not make any changes to this file, only to > drm_os_*bsd.h. > > The bulk of the ifdefs are in stuff like drm_drv.h, but in my current > setup that is in the "shared directory" (I don't have it split into > directories yet). To clarify, do you want all the device-independent > (most drm_*.h) files to be split for Linux/BSD?
I've got some time to take a look at this over the next couple of days. It really depends how big the differences are - but probably we need to come up with a way of doing things without too much #ifdef crud in the main code -- whether this means we need an abstraction layer, more templating to account for OS differences, or other, I don't know. I don't really like the seperate directories idea as this means it is easy for them to get out-of-sync. I'd rather have the core logic in one place only, and have OS-specifics somehow mixed in. Is your latest code available somewhere? Keith _______________________________________________________________ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
