Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4456556imu; Tue, 8 Jan 2019 00:04:16 -0800 (PST) X-Google-Smtp-Source: ALg8bN4ATckQlEaQI80nBG0fSamwoTghYC5NQx++L5watronBql6kjaWmDHoKB2JdFEhQ3cSnTT1 X-Received: by 2002:a17:902:4523:: with SMTP id m32mr756883pld.53.1546934655937; Tue, 08 Jan 2019 00:04:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546934655; cv=none; d=google.com; s=arc-20160816; b=Ab1dWEWW0Rb25mZy4+dxsFhrbjTueYI2xIEGtGn/DXGhgY3YgWu0mKdafFW4lFS9VO Utb33KRwJzxImQMc3Q4d2Yueyk3OOJGoNSUOeLscw3eiep7RjaBp0h1Tjj5ZstcMKH1F +dBE8QFrWbrMi1D/koq+Bf6O+cwmVe/AeuhS2NpGXXk2mG4lI8EmBaP6+r9fTQWzCzOj MWO4miis6dOCwDj3gP8luq/oL55oWxPKqcAHFWm6y4qi9DGcPc4ilg1pKcvufVIT6/vx CATB9tfp9QB+AgJ7UeZLAVqqKzYLISasfedktTo7JsA1UfEj01jTn4OP1set3k+Z1E8z rkdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=u2p1PTXUiId1jRav5uSPdvb52X3FK2aOtDwZOiJnxV0=; b=WN5tnaKeYEsjtgDVz0QJgNPn+/ihVkSacv/GyTJ2IquMssq3WdwkyyEjbKCavnMhoe kW9aGjb5a58NDRe5nNM9BWlZTev82kTpH1304uqNQpKYDUGqWrvhjd9xGivwvGIxsQ07 PgPiwuQZ1WBtGVokQdRg5zBpJACfTfW79In/ZPx1JFlcrr1xzW9irZB664jpFOHH+g9W qCuXJJ5/0Fz6y9s1rB0kjqunlYqP3Trk2/0vaGbFmMY0Wck0qJ9jphGzfP9Fje7tNyDT zPAIvoez2v7Ugis6yKg3gTixv6GCWvhZBvOkp9HoljSZrP0qL14aT7LnuPNzGnGNkaU0 sW0Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v13si18693640pgn.355.2019.01.08.00.04.00; Tue, 08 Jan 2019 00:04:15 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728001AbfAHIC3 (ORCPT + 99 others); Tue, 8 Jan 2019 03:02:29 -0500 Received: from ozlabs.org ([203.11.71.1]:39727 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727473AbfAHIC2 (ORCPT ); Tue, 8 Jan 2019 03:02:28 -0500 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 43Yl9F5nTqz9sD9; Tue, 8 Jan 2019 19:02:25 +1100 (AEDT) From: Michael Ellerman To: Alex Williamson , Masahiro Yamada Cc: Cornelia Huck , Laura Abbott , Alexey Kardashevskiy , kvm@vger.kernel.org, Linux Kernel Mailing List Subject: Re: [PATCH] vfio_pci: Add local source directory as include In-Reply-To: <20190107131341.00581863@x1.home> References: <20190104195714.30045-1-labbott@redhat.com> <874lakc09x.fsf@concordia.ellerman.id.au> <20190107120716.51d95854.cohuck@redhat.com> <20190107131341.00581863@x1.home> Date: Tue, 08 Jan 2019 19:02:23 +1100 Message-ID: <87pnt7tw4w.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Alex Williamson writes: ... > > Numbering options for clarity: > > 1) >> ccflags-y += -I$(src) >> would add the header search path for all files in drivers/vfio/pci/ >> whereas only the drivers/vfio/pci/vfio_pci_nvlink2.c needs it. >> > > 2) >> CFLAGS_vfio_pci_nvlink2.o += -I$(src) >> is a bit better. >> However, it is not obvious why this extra header search path is needed >> until you find vfio_pci_nvlink2.c including trace.h >> > > 3) >> #define TRACE_INCLUDE_PATH ../../drivers/vfio/pci >> clarifies the intention because the related code is all placed in trace.h Good summary. >> From the comment in include/trace/define_trace.h >> TRACE_INCLUDE_PATH is relative to include/trace/define_trace.h > > In my scan of the tree, the most common solution seems to be 2) as this > is essentially recommended in the sample file. 3) is well represented, > with much fewer examples of 1), though it might depend how liberally > we grep out or examine the use cases. It seems to me that 1 and 2 is overwhelmingly used: $ git grep -F "#define TRACE_INCLUDE_PATH" | wc -l 133 That counts all definitions of TRACE_INCLUDE_PATH. $ git grep -F "#define TRACE_INCLUDE_PATH ." | wc -l 122 That's all files using '.', so only 11 locations use the relative path method (3). Which is unsurprising given that the sample uses '.'. And people often look at existing code for an example, so they're also going to tend to use '.'. I agree with Masahiro that adding include paths to the Makefile for this is a bit gross, and method 3 is much more preferable. Fixing all the existing code to use method 3 would be a good beginner project :) cheers