On Fri, Mar 20, 2015 at 08:25:40PM +0000, Emil Velikov wrote: > On 23 February 2015 at 10:35, Mikko Rapeli <mikko.rapeli@xxxxxx> 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-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
