From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752717AbbFDLes (ORCPT ); Thu, 4 Jun 2015 07:34:48 -0400 Received: from mail-vn0-f54.google.com ([209.85.216.54]:38640 "EHLO mail-vn0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750938AbbFDLeq (ORCPT ); Thu, 4 Jun 2015 07:34:46 -0400 MIME-Version: 1.0 In-Reply-To: References: <1433000370-19509-1-git-send-email-mikko.rapeli@iki.fi> <1433000370-19509-10-git-send-email-mikko.rapeli@iki.fi> Date: Thu, 4 Jun 2015 12:34:45 +0100 Message-ID: Subject: Re: [PATCH 09/98] via_drm.h: include linux/types.h instead of non-existing via_drmclient.h From: Emil Velikov To: Mikko Rapeli Cc: "Linux-Kernel@Vger. Kernel. Org" , ML dri-devel , linux-api@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3 June 2015 at 18:16, Emil Velikov wrote: > Hi Mikko, > > On 30 May 2015 at 16:38, Mikko Rapeli wrote: >> Fixes compiler error: >> >> drm/via_drm.h:36:27: fatal error: via_drmclient.h: No such file or directory >> >> Signed-off-by: Mikko Rapeli >> --- >> include/uapi/drm/via_drm.h | 4 +--- >> 1 file changed, 1 insertion(+), 3 deletions(-) >> >> diff --git a/include/uapi/drm/via_drm.h b/include/uapi/drm/via_drm.h >> index 8b0533c..791531e 100644 >> --- a/include/uapi/drm/via_drm.h >> +++ b/include/uapi/drm/via_drm.h >> @@ -24,6 +24,7 @@ >> #ifndef _VIA_DRM_H_ >> #define _VIA_DRM_H_ >> >> +#include > As mentioned elsewhere one could avoid this, and just use drm.h to > manage the approapriate types (uint32_t vs __u32 and so on). > >> #include >> >> /* WARNING: These defines must be the same as what the Xserver uses. >> @@ -33,9 +34,6 @@ >> #ifndef _VIA_DEFINES_ >> #define _VIA_DEFINES_ >> >> -#ifndef __KERNEL__ >> -#include "via_drmclient.h" >> -#endif >> > I fear that this one is a particular example of a nasty legacy from > the UMS days. The file is available/provided in very old mesa versions > and at the very same time mesa requires via_drm.h. So I would kindly > ask that you: > > - Grab the libdrm userspace package, and apply a similar change. > - Rebuild/install the above. > - Fetch mesa 7.11, and try building the via dri module. Ideally > things will continue to build, alternatively we might need to add > another/additional guard for this include. > So the situation is "funnier" than expected: - There are at least two users of via_drm.h (mesa and xf86-video-via) with each providing different via_drmclient.h. - Neither of the two projects includes the latter header, despite that it uses the macros defined within. - via_drm.h is included via multiple headers, so adding extra ifdef guards sounds like a bad idea. - While new version of the ddx can be released, a mesa one is unlikely - 7.11.2 was released ~4 years ago. - Even if we cover the above two project, other projects (how many, where are they hosted, etc.) may need the same treatment. With the above said I'd suspect that we're safer leaving the include as is ? Yes, it is busted if one tries to use the standalone header, jet (most/all?) official users rely on that behaviour :-\ Cheers Emil