<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Aug 19, 2016 at 6:32 PM, Rob Clark <span dir="ltr"><<a href="mailto:robdclark@gmail.com" target="_blank">robdclark@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
</span>tbh, I'm all in favor of making it easier to sync kernel headers to libdrm, etc.<br>
<br>
But kernel *does* have stdint types.  Just (for some reason that<br>
completely baffles me) not in stdint.h so we can't include that from<br>
the uapi headers themselves.  I'm not a huge fan of the uX/sX types<br>
when the rest of the world has moved on to stdint.  I can *kinda*<br>
(barely) understand the argument for kernel using uX/sX in uapi (to<br>
avoid other userspace src files from needing to #include stdint.h<br>
first).  But I think that is a bad argument (kernel should fix it's<br>
shit to be compatible with stdint.h, not other way around), and it<br>
doesn't even apply for drm uapi (where the consumer of the uapi is<br>
just libdrm_$drivername, not random other consumers) so we can take<br>
care to #include stdint.h first..<br>
<br>
tl;dr: I wasn't a big fan of the conversion to uX/sX types.. I kinda<br>
see the argument in the general case (but I think it is bogus, and<br>
even if it was legit it doesn't apply to drm uapi)<br>
<br>
</rant><br>
<br>
BR,<br>
-R<br>
</blockquote><div><br></div>I believe that this patch is to simplify porting requirements by reducing system<br>specific data types whenever possible. The C99 capable data types defined in <br>stdbool.h, stdint.h and inttypes.h are supported by modern compilers. This <br>means that anyone who uses gcc, clang, and Visual Studio 2013 ( or newer )<br>can compile these include files without any major hassles.<br></div><br></div></div>