Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1949015imm; Sun, 9 Sep 2018 12:17:44 -0700 (PDT) X-Google-Smtp-Source: ANB0Vdaxy0U4gQvXbul0HSmveFFayLTsODWMBCQiZG6Gbwcs1ex+uTJFSAHxNmwWm3WluIlvTGYf X-Received: by 2002:a62:938e:: with SMTP id r14-v6mr20121648pfk.55.1536520664400; Sun, 09 Sep 2018 12:17:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536520664; cv=none; d=google.com; s=arc-20160816; b=lfTFX5NXtj/V2wfYkNkCRw4E0/WgwkRs0+rcIFX21x5rwjK7CJAl20JzTdnzlMJcmg Lv1xfDNQ6mVUQYXKTR6jS1xADBbU3+PU+pG1dRN2m3ZepdjqeQH1ZWFs42XuB0UfS7Mo txbfBy0OyyedKsHHDwizEm36h12VFeHoXh2NnaedYuXrdlO0+6wpXhwDzLcF4SfwZZAs MmN9ofn9Fx9R89hgUMYumLE0QtO3lP2WfMxH1idkvvXWTlfogABiRAwD1XjEquZXgikT bYZHdecXxU2wBTO05zu8KFNysNmjWM0iUj/IyrUkhY2DTL6UpjcwTeiLcBNn9Jb/hfvj DYIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature; bh=8IM5HXX9iALCld5TYo2W5XXVQyoI596FJPC67mSYCDs=; b=zJlC37lPc3PZtZC9e6gnvXtHDek+T4QESXFGSlA0qDThkbCc7a+mOyXsd1E3UL1Aba XHJuUNJ1jXwaMYFa2i8Fj2zXD2mthSugRflaku6wl9hLlkYFT5tBE+PtF32w+JgWCCm1 C1jXhpNvg7qR6EjPkNjwWOnaPfZbpRU5mzNnMWbAtAHerZMVEye/HTtFUumeJpgCqO9x T+S3WJTI68y3c5KIDcpj0i6Rqqgtcz8dtnbB60R7YzACecCcPjuwJQYouE9fzVjOUA9f bpc7I7kSmyym0fJMkrBhiQ3LnOSqAEzstROyE6b12Yw7wj0l8MwGwdtA8+j5Tq0HF3i6 0xGQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=XPokKagq; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 62-v6si13853724ply.520.2018.09.09.12.17.28; Sun, 09 Sep 2018 12:17:44 -0700 (PDT) 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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=XPokKagq; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726708AbeIJAG7 (ORCPT + 99 others); Sun, 9 Sep 2018 20:06:59 -0400 Received: from mail-qt0-f172.google.com ([209.85.216.172]:38032 "EHLO mail-qt0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726599AbeIJAG7 (ORCPT ); Sun, 9 Sep 2018 20:06:59 -0400 Received: by mail-qt0-f172.google.com with SMTP id x7-v6so21836658qtk.5; Sun, 09 Sep 2018 12:16:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8IM5HXX9iALCld5TYo2W5XXVQyoI596FJPC67mSYCDs=; b=XPokKagqRcIPDXMEn2hQvuTIA8B47TStgaInL/obr3VXQql7Klisk6fBYOx95f83RS HnNxddMMnbDykaNgm2jav+7QX5FKYW0d3DZ34msPiO6q+fB4wZXpy02/hrN6Wd/bPdpf hQXFSbbqMwyR7IoNu7+C9NHQ7+N9JmFoLKUv8c30uhTfYxz4FoSjLcL0XxG5YEDNNgqQ WYMUZ8xqhwLXn48a7yvCuyN9Msjn5sUd4V/eomzFdbbs6uhbLpj5xGfkINGY1MUy8Mu8 ShMSu3kW1pnT6qUJ2D3kRF5pAVIPGRQPGQXGXpnN+EPo2KQKYBngi2t0Typd3Cm73yUk k9bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8IM5HXX9iALCld5TYo2W5XXVQyoI596FJPC67mSYCDs=; b=oUweI9vunyrq0g0oeUfHU0X4pL8wtAOQmRjM9HZqu/HaRgXRdV/4iDbSpniiTaGPJ1 3S0bj4d+h4LTFVyTyfvHVR7WUpA8F2KSaXkcCnPYyb82G3Yws5YneXvKpbZGuRmi4kSb oIE8US0jX2ikzqNpddDpSRYwteWkTnXn98HM6RgMtIpUFsRyz3J8O/Tql6SO2YmQpc5w XFCWkNY6bV4gacth76MOMUwFaaqkPDtCZcEmCOd5mnE5Ein5FbB7BGIto4OjdGNrcR1W rH026o9wqeMoC+Bb96sqocd0hObJLajeNs0LjVWVxpeEl9YLHsbDcJCQhNrau8Nc4sMb mtGg== X-Gm-Message-State: APzg51ACHO26kHZ9Ln5lisl7Jb98XeShr0hIZWcnrr8j2QgIrWVtbzbr IW2XvvtA9QPtZ4cyG/SqFGUKz27dqdMNwCi10wY= X-Received: by 2002:a0c:abca:: with SMTP id k10-v6mr12123994qvb.140.1536520578750; Sun, 09 Sep 2018 12:16:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:7494:0:0:0:0:0 with HTTP; Sun, 9 Sep 2018 12:15:58 -0700 (PDT) In-Reply-To: <20180909121901.5a36d0fd@lwn.net> References: <20180908212459.19736-1-miguel.ojeda.sandonis@gmail.com> <20180908212459.19736-13-miguel.ojeda.sandonis@gmail.com> <20180909121901.5a36d0fd@lwn.net> From: Miguel Ojeda Date: Sun, 9 Sep 2018 21:15:58 +0200 Message-ID: Subject: Re: [PATCH v4 12/13] Compiler Attributes: add Doc/process/programming-language.rst To: Jonathan Corbet Cc: Linus Torvalds , linux-kernel , Rasmus Villemoes , Luc Van Oostenryck , Eli Friedman , Christopher Li , Kees Cook , Ingo Molnar , Geert Uytterhoeven , Arnd Bergmann , Greg Kroah-Hartman , Masahiro Yamada , Joe Perches , Dominique Martinet , Nick Desaulniers , linux-sparse@vger.kernel.org, Linux Doc Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jonathan, On Sun, Sep 9, 2018 at 8:19 PM, Jonathan Corbet wrote: > On Sat, 8 Sep 2018 23:24:58 +0200 > Miguel Ojeda wrote: > >> Documentation/process/index.rst | 1 + >> .../process/programming-language.rst | 45 +++++++++++++++++++ >> 2 files changed, 46 insertions(+) >> create mode 100644 Documentation/process/programming-language.rst >> > So I have some overall thoughts on the documentation; my apologies for > not getting to this until you got to v4... No problem at all! :-) > > 1) I think the document is mistitled. It's not really about the language > that the kernel used, it's about compiler attributes. So I would make > both the name of the document and it introduction reflect that. The idea here is to create a document explaining the programming language that the kernel uses (which we hadn't), taking the chance to describe the attributes (which in a way are extensions to the C language); in the future expanding it with other (non-attribute) extensions that we use. Of course, that is not done, but I thought starting it was a nice idea (meant for people coming from a C background that do not know the "dialect" used in Linux). Also other kind of very commonly used macros and functions used throughout the kernel could be summarized there as a summary for newcomers (e.g. stuff like `printk`/`pr_*`, `likely`/`unlikely`, `panic`, `EXPORT_SYMBOL`, `BUG_ON`/`WARN_ON`...), without writing full documentation there (but pointing to where they are described, either in the Docs or a source code if not). What do you think? > > 2) This is an ideal opportunity to document what all of those attributes > actually mean. I would guess that is the information many developers I thought about that, but the issue is that compilers already describe them: in the case of GCC, all of them are documented; some are in clang; icc is not well documented --- see the previous threads about this), so we would be duplicating that information (and it will become outdated as compilers are released and improve the documentation). This is the reason why the series removes most of the copy-pasted documentation from gcc and instead supplies a link for each attribute compiler_attributes.h to gcc & clang online docs. > will come here looking for, and they'll go away frustrated. The ideal > thing to do, IMO, would be do say what each attribute means (rather > than just which compilers support it) in a DOC section in the new > compiler_attributes.h header, then use RST directives to pull all that > information into this document. Initially my idea was to provide a table with the name and the links to each compiler docs; so that it could be easily used. However, when thinking about it, it seems that most people consulting such file would come from the actual source code, so they would have to move from there to the Doc/ file; so I did it the other way around (IIRC Nick also mentioned his preference for keeping them in the source code). Now, the idea of keeping them in the header but pulling them to the RST can be a good idea but I was unsure how to do it best. I took a look at how other RST files did it (the pull), but I thought (maybe wrongly) that I wouldn't be able to create a nice table (i.e. instead it would be a long list of attributes, which most people will not use -- and in my idea of a document describing all the extensions, it would be taking most of the space), so I discarded it. I am not sure about the future goals for the Docs/, so excuse me if I have the completely wrong idea, but in a way, in the current state, I see the kernel docs as articles/chapters/book on high-level concepts about the kernel, rather than a technical reference (i.e. the source code with a better formatting). Thanks a lot for reviewing! Cheers, Miguel