From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751629AbbCTUZo (ORCPT ); Fri, 20 Mar 2015 16:25:44 -0400 Received: from mail-yk0-f174.google.com ([209.85.160.174]:36832 "EHLO mail-yk0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751045AbbCTUZl convert rfc822-to-8bit (ORCPT ); Fri, 20 Mar 2015 16:25:41 -0400 MIME-Version: 1.0 In-Reply-To: <20150223103548.GT12550@lakka.kapsi.fi> References: <1424127948-22484-1-git-send-email-mikko.rapeli@iki.fi> <1424127948-22484-6-git-send-email-mikko.rapeli@iki.fi> <54EB0072.8020909@gmail.com> <20150223103548.GT12550@lakka.kapsi.fi> Date: Fri, 20 Mar 2015 20:25:40 +0000 Message-ID: Subject: Re: [PATCH 05/45] drm.h: include stdlib.h in userspace From: Emil Velikov To: Mikko Rapeli , David Howells , Daniel Vetter , Dave Airlie Cc: "Linux-Kernel@Vger. Kernel. Org" , ML dri-devel , linux-api@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 23 February 2015 at 10:35, Mikko Rapeli wrote: > On Mon, Feb 23, 2015 at 10:26:58AM +0000, Emil Velikov wrote: >> On 16/02/15 23:05, Mikko Rapeli wrote: >> > Fixes 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Emil Velikov Subject: Re: [PATCH 05/45] drm.h: include stdlib.h in userspace Date: Fri, 20 Mar 2015 20:25:40 +0000 Message-ID: References: <1424127948-22484-1-git-send-email-mikko.rapeli@iki.fi> <1424127948-22484-6-git-send-email-mikko.rapeli@iki.fi> <54EB0072.8020909@gmail.com> <20150223103548.GT12550@lakka.kapsi.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20150223103548.GT12550-dqH1CgrzRhOk/eJAJmRu5A@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Mikko Rapeli , David Howells , Daniel Vetter , Dave Airlie Cc: "Linux-Kernel@Vger. Kernel. Org" , ML dri-devel , linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-api@vger.kernel.org On 23 February 2015 at 10:35, Mikko Rapeli wrote: > On Mon, Feb 23, 2015 at 10:26:58AM +0000, Emil Velikov wrote: >> On 16/02/15 23:05, Mikko Rapeli wrote: >> > Fixes compilation error: >> > >> > drm/drm.h:132:2: error: unknown type name =E2=80=98size_t=E2=80=99 >> > >> 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 ni= ce >> 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