Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp1099791iob; Thu, 12 May 2022 11:04:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyUIflsOviJTX2P0ULSHjX2Aq6/yfvKS/8FubwoInWMfDqQwbPZzTa04rK1pl7qG2JZEjMx X-Received: by 2002:a17:902:bf06:b0:14d:8c72:96c6 with SMTP id bi6-20020a170902bf0600b0014d8c7296c6mr891691plb.156.1652378684536; Thu, 12 May 2022 11:04:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652378684; cv=none; d=google.com; s=arc-20160816; b=J0UF2O2eP0fjh0MMcbIHBKGCOn3LpchXKeN+kb9uCYRN5FY6iPhdSHadnc4R7ypg1E O35VaRfz3nzrLEwvGso8Vr8Gxw0tPThYE3RD2ecCkWNmMcEYf9WuiEbjWMXoYpy0h6nE G5VQhTkCyY13r+Z/5a9s2i9+9FFwhuO/5sfhNTmpV7st10NeZDV7d6T4gAi9Y7vm6khc 3jlYt9PTEPh5mpP/TjBb6RUjwiBpEGWdVdr9o9QqqX2cwO+joyFdNCRUwc3XJ144x+ey ETQhZmI7N8M1/cbCJgedmcX/rDd05XbaVOvPqO8gIYRKKPq1cXdErv+uSdm0784JjFHZ 3fwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=PPfAjhXsI/sCAXElGiIAWLNhfWDNEi+ZtaHTtSxHBEQ=; b=qxQHJpP6926I6JV3HFJELTwB9KfDw05GCnmS90ByozVLuYtCki1ZBKWChCpkSFZXV0 QySvLiUEbfz1y/CRGs4QJPYSpyaNzPrmJ8QGTs6bW98Jx9pRogmy3bnizleYiBOdwZRJ jz/QAPkYfmjhFcU0bJ8qx51rGelaeGXzczwnOvN7X79fnDQJ1yfKwIwd6CQr9kPF3QQQ zpPmU3WTzQczSTMHGFIQ8r64G9RXAZ27U9siizFWFAqeuOYajBjBcT/bsEZjm5/DlLuK g6kd/g8YbDPicalazJCNSiQutfvCiSBhKwhRrG2ONt7C0Qr8tMdTRZZrYgUBsRi31Hv4 AKFw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=aGnZg3AT; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i132-20020a636d8a000000b003db79f638fasi41641pgc.807.2022.05.12.11.04.30; Thu, 12 May 2022 11:04:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=aGnZg3AT; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S244156AbiEKNuI (ORCPT + 99 others); Wed, 11 May 2022 09:50:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45924 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244138AbiEKNuF (ORCPT ); Wed, 11 May 2022 09:50:05 -0400 Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4A2B6239782; Wed, 11 May 2022 06:50:03 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id s23so2072854iog.13; Wed, 11 May 2022 06:50:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PPfAjhXsI/sCAXElGiIAWLNhfWDNEi+ZtaHTtSxHBEQ=; b=aGnZg3AT2GqkRlrytHTaN/NZj7se3UweBltQbTucUz8qfefhYRjX8D58C1r2q954R4 6DJFBBvHMc/JilfjHyQ5aqY01UN/ab0jVIyzAY5dvdvZIeqaRUit6kQHk967vXUAo93I pB8FjpEP39N8d0YPKBUtmkAzGQERpADWAWEHzgZkXpmv8coKTSst29t7IYGwSgZONziv oI4+fIjhM3bVr2+UA+VQvZRxk3miTrNxlZjLwaex+qmsOl01vetgxC5dI5YMOWpvQjc3 XxgpabVXskv3rcn9yXJv3653A48xMi9ZFSBhEqXtI3PP5+XcVG1qaW97tIAzZBRusZCS SidQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PPfAjhXsI/sCAXElGiIAWLNhfWDNEi+ZtaHTtSxHBEQ=; b=Nb95y87xAS8rQvsrczlKK9ref94YMGImjeT860oZAusxTWJZCeC/7LKrvIBdnRAgku +OBgPVBg8X189lH5+5WI1cKzBXyE+TBQPAoUOhCDSXsQmNcCs9zf7tIJe/5mORktkyVy 9ZDSIEgk5bqc7XZVIrl7bK151Wvq5L0h+98iMgpZ9uBaltOKmZYvlHenrH048G0193TM qK9r4QsWMcjLxLcHQjA/SCxvNuLzScZFO1IkEQ+NCCqzuHXt2J1w6K/Cy+mSoroajxWm QqWsgVzmAulJ73LVaH8X2ow6QgVi0VxzJr3doOEfE+k7pX4Z+e3svLSAOhAAABcMmuaV 97DA== X-Gm-Message-State: AOAM5302gSaDbJjhrWq6yyXyegCrGL26Wa3fQxMRaJ6n/sWw05ltk8w3 1zL5kd3TsWfGU0aTrFBe1M3c5JdzwmSEicY6Fio= X-Received: by 2002:a02:8624:0:b0:32b:397d:eeb1 with SMTP id e33-20020a028624000000b0032b397deeb1mr12780202jai.264.1652277001693; Wed, 11 May 2022 06:50:01 -0700 (PDT) MIME-Version: 1.0 References: <20220507052451.12890-1-ojeda@kernel.org> <20220507052451.12890-19-ojeda@kernel.org> <875ymecp6f.fsf@meer.lwn.net> In-Reply-To: <875ymecp6f.fsf@meer.lwn.net> From: Miguel Ojeda Date: Wed, 11 May 2022 15:49:50 +0200 Message-ID: Subject: Re: [PATCH v6 18/23] docs: add Rust documentation To: Jonathan Corbet Cc: Miguel Ojeda , Linus Torvalds , Greg Kroah-Hartman , rust-for-linux , linux-kernel , Jarkko Sakkinen , Alex Gaynor , Finn Behrens , Adam Bratschi-Kaye , Wedson Almeida Filho , Michael Ellerman , Sven Van Asbroeck , Wu XiangCheng , Gary Guo , Boris-Chengbiao Zhou , Yuki Okushi , Wei Liu , Daniel Xu , Julian Merkle , Masahiro Yamada , Michal Marek , Nick Desaulniers , Linux Doc Mailing List , Linux Kbuild mailing list Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 10, 2022 at 12:32 AM Jonathan Corbet wrote: > > Trying to take a closer look this time... > > I foresee merge conflicts, but so it goes. Trying to split this apart > would not make a lot of sense. Is there a big change coming to docs? (there are not conflicts in linux-next within the docs). Or what do you mean? > Please use normal tables rather than list-table; this kind of thing is > really unreadable in the source form. Will do! > I foresee disagreements over coding style conventions in the > future... I don't plan to be part of that conversation :) Do you mean with the tool settings? I guess we may get some proposals about tweaking them, yeah, but one reason to stick to the defaults is to avoid that! :) If you mean enforcing `rustfmt`, please see below. > I will ask whether we want this, though. Why would anybody want to > mass-reformat the entire body of kernel code? This seems like something > that would generate an endless stream of "helpful" patches and a lot of > churn. So the idea is that, since everything is already formatted, the output of this is empty (in mainline), like Gaelan/Josh mentioned. Thus nobody should be sending any formatting patches since there is nothing to change. Now, for those developing and not running `rustfmt` automatically in some way (e.g. in their editors), it can be useful to run it before submitting the patches: the output should only show changes to whatever you changed since everything else should be already formatted. Of course, as soon as others start submitting patches independently, mistakes may slip through, but we are enforcing this in our CI (and it could be done more centrally), so we should notice quickly. There could be, of course, bugs in the tool; and there are a few situations where the tool may not guarantee formatting stability, but hopefully those are rare and small enough so that we can keep enforcing this. I think it is worth trying. Cheers, Miguel