linux-kernel - Re: [PATCH v4 04/79] drm_mode.h: use __u32 and _

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADnq5_MMzO+bmMmw96=n998hDgGXPbuvFmboO3tw9PMk9S3UdQ@mail.gmail.com>
Date:	Wed, 21 Oct 2015 11:18:36 -0400
From:	Alex Deucher <alexdeucher@...il.com>
To:	Emil Velikov <emil.l.velikov@...il.com>
Cc:	Mikko Rapeli <mikko.rapeli@....fi>,
	"open list:ABI/API" <linux-api@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Maling list - DRI developers 
	<dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH v4 04/79] drm_mode.h: use __u32 and __u64 from linux/types.h

On Wed, Oct 21, 2015 at 11:09 AM, Emil Velikov <emil.l.velikov@...il.com> wrote:
> Hi Alex,
>
> On 15 October 2015 at 14:48, Mikko Rapeli <mikko.rapeli@....fi> wrote:
>> On Thu, Oct 15, 2015 at 09:32:10AM -0400, Alex Deucher wrote:
>>> On Thu, Oct 15, 2015 at 1:55 AM, Mikko Rapeli <mikko.rapeli@....fi> wrote:
>>> > Fixes userspace compilation error:
>>> >
>>> > drm/drm_mode.h:472:2: error: unknown type name ‘uint32_t’
>>> >
>>> > Signed-off-by: Mikko Rapeli <mikko.rapeli@....fi>
>>>
>>> NACK on all these type conversions.  This has not been a problem for
>>> years and years and the result looks terrible.
>>
>> Documentation/CodingStyle, section 5
>>
>>  (e) Types safe for use in userspace.
>>
>>      In certain structures which are visible to userspace, we cannot
>>      require C99 types and cannot use the 'u32' form above. Thus, we
>>      use __u32 and similar types in all structures which are shared
>>      with userspace.
>>
>> I have only been looking at kernel headers from userspace occationally in
>> the past 10 years and had a several cases where the provided headers did
>> not compile when included into trivial programs trying to use the structs
>> for an ioctl() for example. This long lasting problem triggered me to write
>> a test for this and provide these fixes too. In previous reviews usage
>> of <stdint.h> and its types in kernel headers was already NACK'ed
>> so I changed several places from uint32_t's to __u32.
>>
>> With these changes it is btw trivial now to add a grep test the there
>> are no uint32_t's in include/uapi/ anymore, thus enforcing that coding style
>> rule.
>>
> Based of the reply from Mikko, can you please elaborate your concern ?
> Are you thinking about some corner case where this may cause breakage,
> or it's solely on stylistic point of view ?

Style.

>
> Over the last few years we've been doing some ad-hoc 'synchronisation'
> with the headers in libdrm, and this will get us one step closer to
> doing things properly.

How does this affect libdrm one way or another?

Alex

>
> Fwiw I fully support these changes, as does Gustavo for exynos and Rob for msm.
> Reviewed-by: Emil Velikov <emil.l.velikov@...il.com>
>
> Thanks
> Emil
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/