Running on bare hardware

[Marty Jack]

On 02/06/2011 04:28 PM, Dave Airlie wrote:
> On Mon, Feb 7, 2011 at 6:48 AM, Marty Jack <martyj19 at comcast.net> wrote:
>> Well, I have over 40 years experience, a lot of it on Unix and more recently Linux and a lot of it doing compilers, so data typing is second nature.
>>
>> But, I'm getting a little older, I could be mistaken and I'm always happy to learn something new.  Maybe sometime when you have a moment you would be so kind as to explain how this parameter block works successfully for DRM_IOCTL_VERSION and the modesetting ones wouldn't if they had pointer types in the 32/64 scenario you raised.  (We did have the exact same situation on Tru64 Unix running a userspace program compiled with 32-bit pointers.)
>>
>> struct drm_version {
>>        int version_major;        /**< Major version */
>>        int version_minor;        /**< Minor version */
>>        int version_patchlevel;   /**< Patch level */
>>        size_t name_len;          /**< Length of name buffer */
>>        char *name;       /**< Name of driver */
>>        size_t date_len;          /**< Length of date buffer */
>>        char *date;       /**< User-space buffer to hold date */
>>        size_t desc_len;          /**< Length of desc buffer */
>>        char *desc;       /**< User-space buffer to hold desc */
>> };
>>
> 
> Look at that structs built on a 32-bit compiler and a 64-bit compiler,
> notice the alignment differences and size differences, so when a 32-bit
> struct gets passed to the kernel we need to add an additional layer of
> compatiblity, have a look at drm_ioc32.c, this is an extra copy of stuff
> to fix up all the 32/64 issues.
> 
> The proper way is to design ioctls so compat layers aren't needed, to work
> across all 32/64 combos, so that means using 64-bit aligned types as much
> as possible, and padding to make sure 64-bit types don't end up unaligned.
> 
> We then use libdrm in userspace to abstract away the internal details
> of the interface,
> you shouldn't ever be directly talking to drm ioctls.
> 
> x86-64 and ppc have different requirements on 64-bit alignments just
> to make things more interesting.
> 
> Dave.
> 

Right.  If I remember correctly Tru64 interposed some sort of trampoline system to handle the copy-in/copy-out.

I would rather see the natural types used everywhere in the user mode visible definitions and have the compatibility layer where it is needed.  What happens on the day when you want to go to 128-bit pointers.  Of course that is probably some time after the 2038 problem.

I can see that it is a little bit different viewpoint of where user mode starts.  You view libdrm as the outermost level and as part of the compatibility layer, not the ioctls, and it does have the natural types.  Not unlike the idea that the C library, rather than a system call, is where you start your guarantees.  Fair enough.  That's a way of doing it that we can agree on.

It is, if you will, an unfortunate side effect of the way ioctls work.  It is entirely too sensitive to structure mapping.  Also, all the compilers have to be careful to agree on mapping if you have a variety of compilers targeting a platform.

I apologize for making the remark.  It was unnecessary.