From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E8BD8C4338F for ; Wed, 28 Jul 2021 02:08:17 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id ADFED60F9C for ; Wed, 28 Jul 2021 02:08:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org ADFED60F9C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 41A7E6EC50; Wed, 28 Jul 2021 02:08:17 +0000 (UTC) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by gabe.freedesktop.org (Postfix) with ESMTPS id 89CED6EA7E; Wed, 28 Jul 2021 02:08:15 +0000 (UTC) X-IronPort-AV: E=McAfee;i="6200,9189,10058"; a="210677173" X-IronPort-AV: E=Sophos;i="5.84,275,1620716400"; d="scan'208";a="210677173" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jul 2021 19:08:13 -0700 X-IronPort-AV: E=Sophos;i="5.84,275,1620716400"; d="scan'208";a="499051644" Received: from adixit-mobl1.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.209.112.82]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jul 2021 19:08:12 -0700 Date: Tue, 27 Jul 2021 19:01:24 -0700 Message-ID: <87fsvznqmj.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Matthew Auld In-Reply-To: <20210726120310.1115522-1-matthew.auld@intel.com> References: <20210726120310.1115522-1-matthew.auld@intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Subject: Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/7] lib/i915/gem_mman: add FIXED mmap mode X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: igt-dev@lists.freedesktop.org, intel-gfx@lists.freedesktop.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Mon, 26 Jul 2021 05:03:04 -0700, Matthew Auld wrote: > > diff --git a/lib/i915/gem_mman.c b/lib/i915/gem_mman.c > index 4b4f2114..e2514f0c 100644 > --- a/lib/i915/gem_mman.c > +++ b/lib/i915/gem_mman.c > @@ -497,6 +497,43 @@ void *gem_mmap_offset__cpu(int fd, uint32_t handle, uint64_t offset, > return ptr; > } > > +#define LOCAL_I915_MMAP_OFFSET_FIXED 4 Cc: @Petri Latvala This use of LOCAL declarations is more related to the methodology we follow in IGT rather than this patch. We have seen in the past that such LOCAL's linger on in the code for months and years till someone decides to clean them so the question is can we prevent these LOCAL's from getting introduced in the first place. One reason for these is that we sync IGT headers with drm-next whereas IGT is used to test drm-tip. So the delta between the two results in such LOCAL's as in this case. My proposal is that even if we don't start sync'ing IGT headers with drm-tip (instead of drm-next) we allow direct modification of the headers when needed to avoid introducing such LOCAL's. So in the above case we would add: #define I915_MMAP_OFFSET_FIXED 4 to i915_drm.h as part of this patch and then just use I915_MMAP_OFFSET_FIXED. If another sync happens from drm-next before this #define has appeared there, the compile will break and whoever syncs will need to add this again to i915_drm.h. What do people think about a scheme such as this? The other, perhaps better, option of course is to sync the headers directly with drm-tip (whenever and as often as needed). But the goal in both cases is to avoid LOCAL's, or other things like #ifndef's distributed throughout multiple source files which we also do in such cases. A centralized internal header to contain such declarations might not be so bad. Thanks. _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx