From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 1576D45E8E; Fri, 13 Dec 2024 14:38:56 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0F24F409FA; Fri, 13 Dec 2024 14:38:54 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 82CB4402BB for ; Fri, 13 Dec 2024 14:38:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1734097131; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=EAEQbPzCwiQ/JJgxvMzMiHQ1mF9W1arvYOVOWVC7dms=; b=Lb1RMafsGDCk3k30fHXBF2ZRlZkUm6M0Pb0/bN0jHkD9rO1PmVdJQlxYLuBMurujVWVPik Tuu/vMjgpQWueb4BPmVFXxXN9CeXae5wdJfoGAGL8RoqmZjtkfsMLDKkfeGnvuc7Q/JE1P U/if1tGFs6F4w1e7CqJhi7KeEtA+wxk= Received: from mail-lj1-f198.google.com (mail-lj1-f198.google.com [209.85.208.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-588-J0P5LOqaPBGNBuaDIX77HA-1; Fri, 13 Dec 2024 08:38:50 -0500 X-MC-Unique: J0P5LOqaPBGNBuaDIX77HA-1 X-Mimecast-MFC-AGG-ID: J0P5LOqaPBGNBuaDIX77HA Received: by mail-lj1-f198.google.com with SMTP id 38308e7fff4ca-3023f0f1852so8943601fa.1 for ; Fri, 13 Dec 2024 05:38:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734097129; x=1734701929; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=EAEQbPzCwiQ/JJgxvMzMiHQ1mF9W1arvYOVOWVC7dms=; b=aEQ6TAf7IJgl50E5UhUzZEaOrcrvSSTwSsdvWrvn1TQ8nw+yQ43Z6miOI1ABJwCih8 A4C4cQ7iZ2Jr1nP89w8sWc3mrdCFnHlrkbl6JQGU2HQvEQk2fP56n/FP11JPm9i4QGHI WQvNymbGWNaDEOEnD+YIKg6M5kp/Dkoc5dUdnn7mG3DdWn0eP7zt8BoUtbe7y1unr8GI fP4PhxwNU3+/+LgzT89GpBmcu7fKEkvIBbmVgXc6iN7UsFgpYq9erVrN1f5iKRI81qJE sAdvHv2tpFIHpmEAnckp/Pegdv287Em5xz/poU7xSt+l9NMaH4QOFfyFyOIbQFtulFgh rOew== X-Gm-Message-State: AOJu0YxuoU1iQOSMDzF9KX0DeBoUqR/Vm4UaFabDyw2da4kZ3/Lq7JhJ 6PAUnYSeSzikHLhGRlg+4Y1aLrZeeOIGbGVo1GmgcNNf3AyteT8rTnxq5182kpChLXxfP+lpqHt LzxetEHmMl0g8uSVIGMWsNj7QO9amf90Oti9Xe64Y8xBRa8o4eOKpDJxp81CywPSxRmKss3Q90R ukOtJ5elBJH4/sYEc= X-Gm-Gg: ASbGncuP6ho1YuupyHzEI6+76JQBKKwZ9+nob6jwef1wOjRmOWVqj3wRma8ncFBZlt3 O8+pHCQWC9jZC5j0VIIEGM7V3ADU1+mmCaGQME+xS X-Received: by 2002:a05:6512:3b8d:b0:540:2a76:57f8 with SMTP id 2adb3069b0e04-5408ad80c59mr674120e87.12.1734097128868; Fri, 13 Dec 2024 05:38:48 -0800 (PST) X-Google-Smtp-Source: AGHT+IF2fati0CpR8kqPwNF1TR5Amvo0sLSG1MMGBEdG/fnircHUqj1pUztb4I0aJ0bg73C6xF5ycQeIN3NhgOtNoqE= X-Received: by 2002:a05:6512:3b8d:b0:540:2a76:57f8 with SMTP id 2adb3069b0e04-5408ad80c59mr674113e87.12.1734097128449; Fri, 13 Dec 2024 05:38:48 -0800 (PST) MIME-Version: 1.0 References: <20241127112617.1331125-1-david.marchand@redhat.com> <20241213105010.1527683-1-david.marchand@redhat.com> In-Reply-To: From: David Marchand Date: Fri, 13 Dec 2024 14:38:36 +0100 Message-ID: Subject: Re: [PATCH v2 0/6] Add a stricter headers check To: Bruce Richardson Cc: dev@dpdk.org, thomas@monjalon.net X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: aQ99F1mjj41OxdJY9F-NuCLNvrQ2HQUTtzh6eyp2VAQ_1734097129 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Fri, Dec 13, 2024 at 12:27=E2=80=AFPM Bruce Richardson wrote: > > On Fri, Dec 13, 2024 at 11:50:04AM +0100, David Marchand wrote: > > As explained in patch 6, the current headers check can not catch > > issues when a public header includes an internal header. > > Fixing this from meson does not seem an easy task. > > > > This series approach is to reimplement the check in a Makefile invoked > > out of DPDK (like what is done for external compilation of examples). > > This has the advantage of being simple, and avoiding any (non intention= al) > > implicit include path coming from the meson framework. > > > > As there was no easy way to distinguish "indirect" headers in an > > installed DPDK, I chose to move those headers in a new sub directory > > (patch 5). > > > > Patch 1-4 fixes have not been marked as backport material as those bugs > > seems minor/easy to fix externally (by either including missing headers= , > > or enabling enable_driver_sdk option). > > > > For now, I left the check_includes=3D option untouched, as there may be > > users of this check and this check still catches issues without > > requiring to install DPDK. > > > For patches 5 & 6, I wonder if we can find a slightly different way to do > this. I like the idea of using make to build chkincs free from possible > environmental contamination from meson, but I really don't like the > complexity of the resulting makefile! Well, I am no makefile expert, though I find this one straightforward. Thomas could probably enhance it :-). > Rather than having to move the indirect headers to a subdirectory, and th= en > have a makefile run a scan from the headers directory, how about instead > generating the makefile (or possibly a build.ninja file) directly from > meson itself? This means the makefile can already have the list of header= s > and C files necessary - no need for an extra subdirectory - and no need f= or > large amounts of wildcard matching and replacements. Scanning a staging directory insulates from bugs in meson and this is the main point of this series. If we add a new framework in meson (a list of headers or whatever), any driver can still add some install_headers() somewhere and we are back with a new hole. What will ensure that nobody introduce a bug back with some include path to the sources, being passed into the generated Makefile? Headers should be checked from an installed directory (like a final user) with minimal (ideally no) knowledge of what header is safe to include. > The downside is that the makefile is no longer with the source, but in th= e > build directory. However, since the most likely use for this makefile is > from the test-meson-builds script and from automated CIs, I don't see thi= s > being a major issue. This part is not an issue. --=20 David Marchand