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=-15.4 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 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 D6F38C433DB for ; Fri, 5 Feb 2021 18:17:01 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (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 3610F64E49 for ; Fri, 5 Feb 2021 18:17:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3610F64E49 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=amsat.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:58104 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l85fA-0007Lb-5t for qemu-devel@archiver.kernel.org; Fri, 05 Feb 2021 13:17:00 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:54322) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l8514-0000Ug-Pr for qemu-devel@nongnu.org; Fri, 05 Feb 2021 12:35:36 -0500 Received: from mail-ed1-x52c.google.com ([2a00:1450:4864:20::52c]:46407) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l850u-0001q4-JO for qemu-devel@nongnu.org; Fri, 05 Feb 2021 12:35:34 -0500 Received: by mail-ed1-x52c.google.com with SMTP id y18so9654337edw.13 for ; Fri, 05 Feb 2021 09:35:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=b7XmjC+j8puZVGqc8/yxuW/1C5OSlZD4jQAl/AxXOyE=; b=bvhf/8wIpOVnSqa3AZcLOpPAvecaD7RXJOHnSBcoqIRHGxHyTsnkC/GgFgOa+yVOfz 9/QqbRLT/JzrOJim93raC9avO3+SoGfnatA2nv7TRpDo0ah1J/NszyJfSFJRaiHCsRso fTIUCwHH1fsnL2ETp7bs2y2Bwi4Afs8jipfDb4vIuGZuXw7nqZdaJnpGOMoebUbJT45S DCWUh2t8sEv4dby9zmW+oOiUoiEiMdGpy3CTofMBNSCr1tcMSqCQaIC74XtWM3KaCc2H n9QfJPuPW3zWBVWSFEU6Y1exPLEZGDWn4uXbagXTc4tF9LWLnhhbl0goCPYVVVoTtNDf UeAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=b7XmjC+j8puZVGqc8/yxuW/1C5OSlZD4jQAl/AxXOyE=; b=bTHF9N0+4Jmd7TqlyLjT1/Jmj+0Vx7NJcezaeb4l6BMfpG2ySInb7BDN/6knuJByIg bZMcEfWIZfLRBfyu64pVEEEEyLNrkxx21jtIXuJT8Wh76z+SNMZEpGwN1zKxjtXJUG28 JMKbPX44Fgyg8EmbD2t7fexwqgq6kVCSVkScO4vi4y5vjD3I1nD5XZwibqG3gPk4t2PQ L4Sm2OFcd3kh3pMpc4e8dBpKvmL4pXwBOqq+q0G6aJHEiLcqLwn/GjhV0nAYyOcU3Zz2 wT+cNLn+O2WMWVHDH5TVaMIlDY2OLzOcgHqZ7fCvmOrpvEOchaZ5V1efZATnpPJ775TO x1qA== X-Gm-Message-State: AOAM5334+XONxEfB6BgvmW+MGQG9XgLe1y4LlMdLaB5jUn99GUMfBD6U kFeRDNNfM4ko7OIsg58u+vU= X-Google-Smtp-Source: ABdhPJwmkisjcIXJqitjDAGargiLiZ5sG+SFq/U4uag5Y9BRAk7SW5CsGcll85eWz6V/5k7q5xiZ8Q== X-Received: by 2002:a05:6402:35ca:: with SMTP id z10mr4683892edc.174.1612546521974; Fri, 05 Feb 2021 09:35:21 -0800 (PST) Received: from [192.168.1.36] (68.red-83-57-175.dynamicip.rima-tde.net. [83.57.175.68]) by smtp.gmail.com with ESMTPSA id f6sm4346934edk.13.2021.02.05.09.35.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 Feb 2021 09:35:21 -0800 (PST) Subject: Re: [PATCH v7 12/35] Hexagon (target/hexagon) instruction attributes To: Taylor Simpson , "qemu-devel@nongnu.org" , Paolo Bonzini References: <1611113349-24906-1-git-send-email-tsimpson@quicinc.com> <1611113349-24906-13-git-send-email-tsimpson@quicinc.com> <11960eff-406b-158c-7fae-61b2e0550268@amsat.org> <55f89e45-c479-e02b-27c6-f2e6a7fb85ed@amsat.org> From: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= Message-ID: Date: Fri, 5 Feb 2021 18:35:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=2a00:1450:4864:20::52c; envelope-from=philippe.mathieu.daude@gmail.com; helo=mail-ed1-x52c.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.33, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ale@rev.ng" , Brian Cain , "richard.henderson@linaro.org" , "laurent@vivier.eu" , "alex.bennee@linaro.org" Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Hi Taylor, +Eric in case I'm wrong. On 1/30/21 12:15 AM, Taylor Simpson wrote: >>>> On 1/20/21 4:28 AM, Taylor Simpson wrote: >>>>> Signed-off-by: Taylor Simpson >>>>> --- >>>>> target/hexagon/attribs.h | 30 ++++++++++++++ >>>>> target/hexagon/attribs_def.h | 95 >>>> ++++++++++++++++++++++++++++++++++++++++++++ >>>>> 2 files changed, 125 insertions(+) >>>>> create mode 100644 target/hexagon/attribs.h >>>>> create mode 100644 target/hexagon/attribs_def.h >>>>> >>>>> diff --git a/target/hexagon/attribs.h b/target/hexagon/attribs.h >>>>> new file mode 100644 >>>>> index 0000000..e88e5eb >>>>> --- /dev/null >>>>> +++ b/target/hexagon/attribs.h >>>>> @@ -0,0 +1,30 @@ >>>>> + >>>>> +enum { >>>>> +#define DEF_ATTRIB(NAME, ...) A_##NAME, >>>>> +#include "attribs_def.h" >>>> >>>> Per QEMU conventions, this file has to be named "attribs_def.h.inc". >>> >>> Didn't know that. Which files should end in .inc? >> >> Oh you are right, it is not documented in CODING_STYLE.rst. >> >> You can see the rationale in commits:139c1837db7 and 0979ed017f0: >> >> meson: rename included C source files to .c.inc >> >> With Makefiles that have automatically generated dependencies, you >> generated includes are set as dependencies of the Makefile, so that they >> are built before everything else and they are available when first >> building the .c files. >> >> Alternatively you can use a fine-grained dependency, e.g. >> >> target/arm/translate.o: target/arm/decode-neon-shared.inc.c >> >> With Meson you have only one choice and it is a third option, namely >> "build at the beginning of the corresponding target"; the way you >> express it is to list the includes in the sources of that target. >> >> The problem is that Meson decides if something is a source vs. a >> generated include by looking at the extension: '.c', '.cc', '.m', '.C' >> are sources, while everything else is considered an include---including >> '.inc.c'. >> >> Use '.c.inc' to avoid this, as it is consistent with our other convention >> of using '.rst.inc' for included reStructuredText files. The editorconfig >> file is adjusted. > > OK, I understand why it's better to have files end .[ch].inc than .inc.[ch]. > > However, I need some confirmation on which files need .inc instead of simply ending in .h. From what I can tell these are the guidelines > - If a file is intended to be included in the middle of another file (as opposed to the top), it should end in .inc. This has to be justified. Usually such file use macro definitions which are defined by the file including them. If you can not justify, there is probably a way to have your file as its own .c/.h unit. > - If a .inc file is intended to be included in a .h file, it should end in .h.inc. Yes, no exception. > - If a .inc file is intended to be included in a .c file, it should end in .c.inc. Not necessarily, you can have .h.inc included in .c.inc: Function prototype declarations -> .h If generated -> .h.inc Function body definitions -> .c These can NOT go in .h, so if generated -> .c.inc Inlined function body definitions -> .h/.c/.h.inc > - The above applies to both human-written and generated files. Yes, although it is harder to justify human-written .inc. Also: Header exposing subsystem X API to other subsystems go in include/..X..h (example include/hw/sd/sd.h) Header sharing prototypes local to a particular subsystem go in X/..h (example hw/sd/sdmmc-internal.h) *.inc must not go in include/ Regards (and sorry for answering late), Phil.