linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: christian.koenig@amd.com (Christian König)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 05/98] exynos_drm.h: use __u64 from linux/types.h
Date: Mon, 1 Jun 2015 10:20:10 +0200	[thread overview]
Message-ID: <556C15BA.7000909@amd.com> (raw)
In-Reply-To: <20150530164655.GM2067@n2100.arm.linux.org.uk>

On 30.05.2015 18:46, Russell King - ARM Linux wrote:
> On Sat, May 30, 2015 at 05:37:57PM +0200, Mikko Rapeli wrote:
>> Fixes userspace compilation error:
>>
>> drm/exynos_drm.h:30:2: error: unknown type name ?uint64_t?
>>
>> Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
> This is another thing which we need to address.  We should not be using
> unsigned int/unsigned long/uintXX_t/etc in here, but the __uXX and __sXX
> types.
>
> The lesson learned from other DRM developers is that using these types
> simplifies the API especially when it comes to the differences between
> 32-bit and 64-bit machines, and compat applications.
>
> Note that drm/drm.h is all that should need to be included - drm/drm.h
> takes care of including linux/types.h when building on Linux platforms.
> (note: if your compiler doesn't set __linux__ then you're probably not
> using the proper compiler...)
>

Using types that differs on 32-bit and 64-bit machines for a kernel 
interface is indeed a rather bad idea. This not only includes longs, but 
pointers as well.

But the int8_t, int16_t int32_t, int64_t and their unsigned counterparts 
are defined in stdint.h which is part of the ISO/IEC 9899:1999 standard, 
similar is true for size_t.

The __uXX, __sXX and _kernel_size_t types are linux specific as far as I 
know.

For best interoperability and standard conformance I think that 
definitions from the C standard we use should out-rule linux specific 
definitions.

Additional to that "linux/types.h" is not part of the uapi as far as I 
know, so including it in a header which is part of the uapi should be 
forbidden.

So this is a NAK from my side for the whole series, userspace programs 
should include <stdint.h> for the definition of the ISO/IEC 9899:1999 
standard types if necessary.

Regards,
Christian.

  reply	other threads:[~2015-06-01  8:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1433000370-19509-1-git-send-email-mikko.rapeli@iki.fi>
2015-05-30 15:37 ` [PATCH 05/98] exynos_drm.h: use __u64 from linux/types.h Mikko Rapeli
2015-05-30 16:46   ` Russell King - ARM Linux
2015-06-01  8:20     ` Christian König [this message]
2015-06-01  8:56       ` Russell King - ARM Linux
2015-06-01  9:08         ` Christian König
2015-06-01  9:14           ` Frans Klaver
2015-06-01  9:38           ` Russell King - ARM Linux
2015-06-01  9:51             ` Christian König
2015-06-01  9:15       ` Mikko Rapeli
2015-06-02 18:59     ` Mikko Rapeli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=556C15BA.7000909@amd.com \
    --to=christian.koenig@amd.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).