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 / \/\ _
[EMAIL PROTECTED] / \ \ \ Steamboat Springs, Colorado
-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
