Felix K�hling wrote:
=== Header files in the DRM ===
drm.h: driver-independent types and definitions for the 3D driver to communicate with the DRM.
Driver-indepenent / OS-independent.
drmP.h: driver-independent internal types and definitions.
Driver-indepenent / OS-dependent.
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?
Basically, this defines the user / kernel interface for the driver.
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.
Close. There used to be separate *_drm.h files for each operating-system. For some drivers, such as i830, there still is. The XFree86 policy is to not include platform-dependent files, so a new file that mirroed the stuff in the "OS dependent" files was needed. In "modern" drivers, anything that lives in drm/shared can be considered platform-independent, IMHO.
=== 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?
IMO, the C99 types should be used. That is the portable, future-proof way. I seem to recall some Linux kernel developers having issue with anything other than __u32 / __u64 (or was it u32 / u64?) being used, but I don't know what they were. On any given platform, __u32 had better be the exact same type as the C99 uint32_t, or that platform is broken!
For keeping the DRM portable among OS's, should fixed-size number types be defined in drm.h/drmP.h?
Yuck. :( Nobody wants more types that mean the same thing as existing types. Having drm_u32_t or some such sounds really, really unpleasant.
------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id�66&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
