| Message ID | 1424127948-22484-6-git-send-email-mikko.rapeli@iki.fi (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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. Thanks Emil
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 -Mikko
On 23 February 2015 at 10:35, Mikko Rapeli <mikko.rapeli@iki.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
On Fri, Mar 20, 2015 at 08:25:40PM +0000, Emil Velikov wrote: > On 23 February 2015 at 10:35, Mikko Rapeli <mikko.rapeli@iki.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
Hi Mikko Pardon for the late response, On 21 March 2015 at 12:17, Mikko Rapeli <mikko.rapeli@iki.fi> wrote: > On Fri, Mar 20, 2015 at 08:25:40PM +0000, Emil Velikov wrote: >> On 23 February 2015 at 10:35, Mikko Rapeli <mikko.rapeli@iki.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... > Glad to hear that it's getting there. Might be a bit slower than expected but we'll get there :-) Can you please Cc me on the next iteration ? >> 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). > After discussing (more like annoying) our DRM maintainer we got to the conclusion that the headers will stay exposed to userspace. So any and all of your work will be greatly appreciated. Thanks Emil
On Thu, Apr 09, 2015 at 05:00:48PM +0100, Emil Velikov wrote: > Hi Mikko > > Pardon for the late response, > > On 21 March 2015 at 12:17, Mikko Rapeli <mikko.rapeli@iki.fi> wrote: > > On Fri, Mar 20, 2015 at 08:25:40PM +0000, Emil Velikov wrote: > >> On 23 February 2015 at 10:35, Mikko Rapeli <mikko.rapeli@iki.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... > > > Glad to hear that it's getting there. Might be a bit slower than > expected but we'll get there :-) Can you please Cc me on the next > iteration ? Yes will Cc you too, and sorry life is getting on the way of this work. Draft version is visible at https://github.com/torvalds/linux/compare/master...mcfrisk:headers_test_v03 -Mikko
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h index b0b8556..8f4488f 100644 --- a/include/uapi/drm/drm.h +++ b/include/uapi/drm/drm.h @@ -42,6 +42,10 @@ #include <asm/ioctl.h> typedef unsigned int drm_handle_t; +#ifndef __KERNEL__ +#include <stdlib.h> +#endif + #else /* One of the BSDs */ #include <sys/ioccom.h>
Fixes <drm/drm.h> compilation error: drm/drm.h:132:2: error: unknown type name ‘size_t’ Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi> --- include/uapi/drm/drm.h | 4 ++++ 1 file changed, 4 insertions(+)