On Wed, 2002-06-26 at 23:50, Jens Owen wrote: > 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.>
Well, at least on the OSes we are looking at now (Linux, FreeBSD, NetBSD) I think we can move the DRIVER_IOCTLS, along with the rest of the interface information from the *_drv.c, into the *_drv.h headers. This would leave the copyright, the header includes (whose inclusion is both os and device specific), and whatever module glue (DRIVER_MODULE and the pci chip ids on FreeBSD, *_options() on Linux). I really don't want to move the Makefiles out, they're very specific. If all the porting necessary was making another *_drv.c on BSD and a Makefile for it, I would be ecstatic. But the difficulty of porting the drivers isn't this bit of module and Makefile glue, it's all the functions that the driver writer uses that aren't a part of the os-independent interface. The non-checking copyins in the radeon code, for example, or the tricks i8x0 plays with the mmap handler, or the sis framebuffer requirement. I believe every new driver, even when the developer takes some reasonable care to follow the interface, will need some touching up for compatibility. For example, to be included in FreeBSD the modules need to be warns-clean with gcc3 at some pretty strict warning levels. There is also the krnfromusr/copyfromusr difference that doesn't exist on Linux. A README file in shared/drm/kernel/ on the interface would help, but probably not eliminate problems. My goal with the interface when we started discussing them here was to avoid having to re-port future changes to existing modules (bugfixes, small feature additions). TCL would probably even have worked almost perfectly if the interface was already there when Keith was doing the code that used verifyarea. I think this goal is accomplished now. As far as new drivers, if they start from existing os-independent driver code, I think we'll be good enough. As a note in this os-independence discussion, breaking the DRM for BSD (accidentally committing something that isn't independent) won't be that big of a deal. FreeBSD-current has the DRM in the system, and I'll probably merge to -stable (what releases are made of) whenever I can get a merge to trunk and then back to FreeBSD done. NetBSD will also most likely have to bring the code manually into the kernel, as the kernel module system is pretty primitive from what we can see. Normal BSD users won't be relying on the DRI CVS or even XFree86 release DRMs, and instead will get them from their OS. -- Eric Anholt <[EMAIL PROTECTED]> http://gladstone.uoregon.edu/~eanholt/dri/ ------------------------------------------------------- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
