linux-kernel - Re: [PATCH 05/45] drm.h: include stdlib.h in userspace

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]

Date:	Fri, 20 Mar 2015 20:25:40 +0000
From:	Emil Velikov <emil.l.velikov@...il.com>
To:	Mikko Rapeli <mikko.rapeli@....fi>,
	David Howells <dhowells@...hat.com>,
	Daniel Vetter <daniel@...ll.ch>,
	Dave Airlie <airlied@...il.com>
Cc:	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
	ML dri-devel <dri-devel@...ts.freedesktop.org>,
	linux-api@...r.kernel.org
Subject: Re: [PATCH 05/45] drm.h: include stdlib.h in userspace

On 23 February 2015 at 10:35, Mikko Rapeli <mikko.rapeli@....fi> wrote:
> On Mon, Feb 23, 2015 at 10:26:58AM +0000, Emil Velikov wrote:
>> On 16/02/15 23:05, Mikko Rapeli wrote:
>> > Fixes <drm/drm.h> compilation error:
>> >
>> > drm/drm.h:132:2: error: unknown type name ‘size_t’
>> >
>> Hi Mikko,
>>
>> Can you let us know how you're getting these (series-wise) errors ? I've
>> been meaning to sync the uapi/drm and libdrm headers and would be nice
>> to have an extra step to test things.
>
> This should have everything needed to reproduce these compile errors,
> though some of the errors hide behind other errors and fixes:
>
> https://lkml.org/lkml/2015/2/16/525
>
Thanks for the link Mikko.

Afaict the general consensus seems to be that one should avoid using
stdint's uint8_t, but stick to __u8 and friends. Did you had the
chance to roll out another series that does so ?

That aside I'm not 100% sure that doing the UAPI split, as is, was the
perfect solution. Afaik drm used to live as an out of tree userspace
library(libdrm). Not sure at which point the major restructuring took
part, but one is certain - libdrm remains the only authoritative
sources of the headers. It's possible that some buggy programs pull
the UAPI headers while linking against the library, but I'd say that
won't end up well in the long term. Additionally since the UAPI split
the `make update-headers' target used to sync libdrm's headers have
been broken leading people to copy misc. hunks and/or files. Leading
to greater chance of things going sour.

All that said, I will need to gather some opinions for drm developers
and maintainers if the idea of part revering 718dcedd7e8(UAPI:
(Scripted) Disintegrate include/drm) will be the way forward.

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/