Re: Getting a DRM "right" from the start

[Ian R. <id...@us...>]

Sorry for taking so long to reply.  In some cultures, taking 9 days to=20
reply to an e-mail means that much thought was put into the reply. ;)

Felix K=FChling wrote:

> =3D=3D=3D Header files in the DRM =3D=3D=3D
>=20
> 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). Someon=
e
> 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.
>=20
> savage.h: DRM template customization
>=20
> =3D=3D=3D Header files in the Xserver =3D=3D=3D
>=20
> savage_sarea.h: Basically a copy of the sarea defines and sarea
> structure in the kernel but with different naming conventions. I vaguel=
y
> remember that this was because of XFree86's policy not to use external
> header files or something such.
>=20
> 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=20
operating-system.  For some drivers, such as i830, there still is.  The=20
XFree86 policy is to not include platform-dependent files, so a new file=20
that mirroed the stuff in the "OS dependent" files was needed.  In=20
"modern" drivers, anything that lives in drm/shared can be considered=20
platform-independent, IMHO.

> =3D=3D=3D 64bit issues =3D=3D=3D
>=20
> 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 t=
o
> 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=20
way.  I seem to recall some Linux kernel developers having issue with=20
anything other than __u32 / __u64 (or was it u32 / u64?) being used, but=20
I don't know what they were.  On any given platform, __u32 had better be=20
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=20
types.  Having drm_u32_t or some such sounds really, really unpleasant.