From: Jens O. <je...@tu...> - 2002-06-27 05:50:28
|
Eric Anholt wrote: >>Log message: >> Include protection against ioctl() definition only in the __FreeBSD__ and >> XFree86Server case. These two drm.h's probably should be shared. >> > > With this commit radeon, r128, and mga are all working on FreeBSD and > Linux. Haven't tested tdfx, but I have no reason to not expect it to > work. > > At this point, who should review this for a merge? Damn, this is looking sweet! You have almost hit gold with this work, and here's what I would consider perfection: The source repository and plain source trees that haven't been built, yet would contain an os-support/linux/drm/kernel that contained the drm* files for Linux: drm_agpsupport.h drm_drawable.h drm_ioctl.h drm_os_freebsd.h drm_auth.h drm_drv.h drm_linux.h drm_os_netbsd.h drm_bufs.h drm_fops.h drm_lists.h drmP.h drm_context.h drm.h drm_lock.h drm_scatter.h drm_dma.h drm_init.h drm_memory.h drm_sysctl.h drm_vm.h Not these are all Linux specific, but Hardware independent, and of course an os-support/bsd/drm/kernel and other os specific directories, too. None of which contained HW specific files. The os-support/shared/drm/kernel directory would then contain the HW specifics: gamma_dma.c i810_drv.h mga_drm.h r128_drm.h radeon_drv.h gamma_drm.h i810.h mga_drv.c r128_drv.c radeon_state.c gamma_drv.c i830_dma.c mga_drv.h r128_drv.h radeon.h gamma_drv.h i830_drm.h mga_state.c r128_state.c tdfx_drv.c gamma.h i830_drv.c mga_ucode.h r128.h tdfx.h i810_dma.c i830_drv.h mga_warp.c radeon_cp.c i810_drm.h i830.h mga.h radeon_drm.h i810_drv.c mga_dma.c r128_cce.c radeon_drv.c For the drivers you've ported to your OS independent templates (radeon, r128 and mga), it looks like the *_drv.c and Makefile support are all that's left in the OS directories. If you can get these out of there, even by adding a few OS ifdefs in the shared directory, you will get big leverage when a new driver is written. Generally, a driver writer copies another driver as a starting point, and they won't discard non development OS's simply because it's easier to ignore the directories. In other words, let's make new drivers work on all supported OS's by default instead of having to enable each OS/driver combo by hand. I can see the need for disabling a OS/driver combo by hand after we know it can't be easily supported. I'm definitely interested in hearing your opinion on squeeking out the last bigs of OS specifics in these drivers. I realize the last parts are usually the most difficult. Regards, Jens -- /\ Jens Owen / \/\ _ je...@tu... / \ \ \ Steamboat Springs, Colorado |