On Sat, 2004-05-15 at 14:23, Felix Kühling wrote: > Hi, > > I'm using a few spare hours to get started working on the Savage DRM > driver. I'm going to have to rewrite it from scratch. The current sarea > definition is essentially copied from the MGA driver and the only 3 > driver-specific ioctls are not (and probably won't be) used by the > current 2D/3D drivers. ;-) > > To get started I have to clean up the savage_sarea structure and define > structures for ioctl arguments and such stuff. I looked around in some > existing DRM header files, mostly MGA. At first I was a bit confused > about how things fit together and recent comments about fixing 64-bit > issues and reorganizing DRM header files added to that confusion. I'd > like to get this DRM right from the start. So any advice would be > welcome. Below is my current understanding about how things _should_ be. > > === Header files in the DRM === > > drm.h: driver-independent types and definitions for the 3D driver to > communicate with the DRM. > > drmP.h: driver-independent internal types and definitions. > > savage_drm.h: any definitions needed by the 3D driver to communicate > with the DRM (sarea, sarea defines, ioctl parameter structures). Someone > recently proposed to use a "sanitized" copy of this file (and probably > drm.h) in the 3D driver instead of the kernel header file. That would > mean that these definitions have to be kept in sync in 3 places: kernel, > sanitized user-space copy and Xserver (see below). Does that make sense? > > savage_drv.h: driver-internal data types like the dev_private structure > and function prototypes, some macros for BCI access. > > savage.h: DRM template customization > > === Header files in the Xserver === > > savage_sarea.h: Basically a copy of the sarea defines and sarea > structure in the kernel but with different naming conventions. I vaguely > remember that this was because of XFree86's policy not to use external > header files or something such. > > savage_common.h: Ioctl parameter structures with XFree86 naming > conventions. Same rationale as for savage_sarea.h, I guess. > > The sarea defines are protected by a macro __SAVAGE_SAREA_DEFINES__. > This looks like it should be possible to include savage_sarea.h and > savage_drm.h in the same source file. I havn't found any example of that > though. Is this an artifact from early DRI/DRM days? > > === 64bit issues === > > Basically any fields in data structures shared between kernel and > user-space must have a fixed size in order to allow 32-bit user space to > work with a 64-bit kernel. Is that correct? Then what are the right > types (u32, __u32, uint32, ...?) that are available in both the kernel > (possibly linux and BSD) and user-space? Or if we're not going to share > header files between kernel tree and 3D drivers, then what types would > be used in the kernel and which types in user-space? > > For keeping the DRM portable among OS's, should fixed-size number types > be defined in drm.h/drmP.h?
This all basically looks right to me. I had forgotten that we maintained separate *_common.h and *_sarea.h. It seems like a waste to me. The one thing I ask, for portability, is to use uint32_t and friends, instead of u32/__u32. It sounds we shouldn't have anything that requires a pointer (64-bit) to be passed between kernel/userland, so setting things to int32s should be fine. I know SiS is an exception, which I'll fix soon. -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
