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:	Sat, 21 Mar 2015 14:17:06 +0200
From:	Mikko Rapeli <mikko.rapeli@....fi>
To:	Emil Velikov <emil.l.velikov@...il.com>
Cc:	David Howells <dhowells@...hat.com>,
	Daniel Vetter <daniel@...ll.ch>,
	Dave Airlie <airlied@...il.com>,
	"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 Fri, Mar 20, 2015 at 08:25:40PM +0000, Emil Velikov wrote:
> 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 ?

Yes, new series with these changes is on the way. I'm trying to follow up to
all other review comments as well and get down to 100% compiling uapi
headers; 35 failures to go...

> 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.

Ok, I'll follow what is available in Linus' tree (or -next, not shure which
one I should track for these changes).

-Mikko
--
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/