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;
Date:   Thu, 28 Jul 2022 11:21:14 +0100
From:   Gary Guo <gary@garyguo.net>
To:     Olliver Schinagl <oliver+list@schinagl.nl>
Cc:     Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
        Miguel Ojeda <ojeda@kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        rust-for-linux <rust-for-linux@vger.kernel.org>,
        Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
        Linux Doc Mailing List <linux-doc@vger.kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 00/13] [RFC] Rust support
Message-ID: <20220728112114.0000003a@garyguo.net>
In-Reply-To: <5c0bb1db-5589-32ca-ac22-4aafb3c15751@schinagl.nl>
References: <20210414184604.23473-1-ojeda@kernel.org>
        <fae4873e-2ff9-df35-0ab9-34bf4417b717@schinagl.nl>
        <CANiq72mRxM-7griYF+0FWqYoSoNL8ad=L-i6a2-GsaCeb0C6qQ@mail.gmail.com>
        <ba8cb315-9d73-2f45-8bf9-d9473d369dca@schinagl.nl>
        <CANiq72kz+Txauo+103_-fN_J8PhhCdJUH5XepShUQmJzW6a4tA@mail.gmail.com>
        <5c0bb1db-5589-32ca-ac22-4aafb3c15751@schinagl.nl>
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?zlDeX/rWCkc5HHGTIjVPDGJ7JuvAtiZBlHoZLscQnOLdDK8eE4GBdfeP7+A+?=
 =?us-ascii?Q?usKQr7k2lob0BlIeozvDg8otcafuvoRIwUHKvjT4g7TiVdvyfQWH8i9XU6f+?=
 =?us-ascii?Q?2h+HidTwQ4Mt+msW+UV5n9rTRbS9wRwf449ZlZyvkl5G8ofhSBij/Q0wj5tp?=
 =?us-ascii?Q?nHCTIKTs4o2hVOwWVHFTeDXzU2edERDTUB9QbQRZnB8TmmlVyc5vF4OP9qDN?=
 =?us-ascii?Q?ZeWGTo4c5wJBzFkJwD5wuJfKAFW6AQ9IHkpyrPSwIps0jGn61WT/27MMmTAM?=
 =?us-ascii?Q?tfJUBQdt8KfCwqz0/VfHLeOxhUf46yY9zzUED19eEPRIwfZNXpTOJ7NI/5lr?=
 =?us-ascii?Q?FHUNT9WHz7b/Zk/Xd++m/aR+Lth5iIAUt3vwDumYC8ygzBDT9Ja98nCiKrm9?=
 =?us-ascii?Q?NdP1depdHEI6g3l/Knjk5phDYcxJ1NeNoax8aoNSoecIiavHaXk+ifaKC+B9?=
 =?us-ascii?Q?IYzP67ijMp5V/rlQKPb5M6uRyi6eIjdJXVxpx2OUgXNOc1KgwNpK+rpaoTHk?=
 =?us-ascii?Q?p7PKyXTevacGxHV3I6ZOIqW19ztSxhd4Uu9+xABpR7/jNmen56S7EhgLlURa?=
 =?us-ascii?Q?66mhAP38k5xhIsjecvNrppviAFFpHI+YcM0Tho3UpZsdgxA/YP6MNXJRNyUX?=
 =?us-ascii?Q?nb0CqmNZO87zSAjB+qyntAfK/w80FMf/2DWXXvv79flbQXk5HhEpvMjk6fmf?=
 =?us-ascii?Q?B6Fof9eKeg62QaNw4x5Y7owmJPLZphNP3fxvSXxpn1KEy0rT4NaFSI0GjGVb?=
 =?us-ascii?Q?VKu9gHk+EB6Ve9G9VYu0wB3f3K0qrdVVMdcJVP4G/a5k5QZJ1ZCxuzAKZbOD?=
 =?us-ascii?Q?hbPTRUdQXLURPrrEQHq0L9UYUSVsqL59naetjpbwgJxKzMr7k/cH/1WmMzZ3?=
 =?us-ascii?Q?08UVicpoRqga2+aX49LYS8t2v1LrYbEIgdBQA4BeUQAb4pH8mtj7mymebcjI?=
 =?us-ascii?Q?TcmP+b4V+SoaEDorPl/ducMFdU1kBzsbvl32HSaj36mNj7KFsqThJZ3PMZcl?=
 =?us-ascii?Q?N+2qXURIYnBIOSsiU040GNNn00rc5PdMNn1453knMX4NOloTik/aYQlqi/E9?=
 =?us-ascii?Q?WwEKwt5R3gA6yulk5fCLExEAF2qFFrWsRCgURaQ5bxnqtJxJCkdnoJyv7hyM?=
 =?us-ascii?Q?yIlDPtgWcczGtScCRT3TMYhrFR8MF3qJaugj6C/wAFcWMJ2ZbiGedpRpjZVd?=
 =?us-ascii?Q?ptq9bx58n5xYUfi2nPA10pMnT03VbHcb1tTpC5PSQgLIK6O4xm9osApwICap?=
 =?us-ascii?Q?6chlW8f87HkcSh48naEmLAyibqaljEfYaFoxxft3eEg6WWW/Cn1tONQofS8Q?=
 =?us-ascii?Q?wiwnopAiJXTC5JcmS9LmzRSRZ0ycAhR/Q+8isFfcGfmH1u39UYMuuHq4nr4D?=
 =?us-ascii?Q?GBlzaPmJhj9jgIYeCsUE4ub1bi3+rYf1w6UepL/6/eb3ef84Y2WB1NR080cy?=
 =?us-ascii?Q?1HESzH6F5U2Gso96mcR/ofFsSVT0+g+Nlaod0ZFkg/XExIUgdscHOjfoV8sm?=
 =?us-ascii?Q?X3+qKy15KDsF7HrP6IyeLRHTc30aSjbgXlnkedVAtfrnFVui48msuxAfxkhr?=
 =?us-ascii?Q?uHB9evzaIOi2Kxgw+rBpI2kn7xKjKZw1qXNXt/eZGA1qNoyRJ+fvodjyKmo8?=
 =?us-ascii?Q?REVq6v0ehSNroc3vB7F45IIy65KdPldfmPe0kIBQ0L62?=
X-OriginatorOrg: garyguo.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 7bda7fe6-2977-42fd-9b6d-08da7082ea4e
X-MS-Exchange-CrossTenant-AuthSource: LO2P265MB5183.GBRP265.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jul 2022 10:21:20.9643
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: bbc898ad-b10f-4e10-8552-d9377b823d45
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: TK5BS8HqUGecU+FTeHMTtgDrt9jr7kAibXrIpWrxZa/+VRpblNI/F/AaI9CNdHhpYHic2bu7lZiqTvDV9m2XlA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO4P265MB4146
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_BL_SPAMCOP_NET,
        RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS
        autolearn=no 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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Olliver,

On Wed, 27 Jul 2022 10:05:31 +0200
Olliver Schinagl <oliver+list@schinagl.nl> wrote:

> Consitency is absolutly important! Zero argument there. My argument
> is, the consistency should be within the kernel tree, not 'but the
> rest of the world is using style X/Y/Z, lets be consistent with that.
> In an utopia, maybe, but the real world doesn't work that way, sadly.
> So in an attempt to standardize (rustfmt) they just "invented" a new
> standard. Which btw is common, we see this happening every so often,
> right?

Difference languages have different characteristics and I don't think
it's necessarily good (and often isn't) to blindly apply coding style
of one language onto another. So I don't see rustfmt as "inventing yet
another standard" really, because there aren't many conflicting coding
style standards in Rust world; almost everyone just settled on using
rustfmt, mostly using the default, maybe with a few small
project-specific configuration tweaks.

A small example for C and Rust differences:

Rust requires braces around branches of if expression, and C doesn't.
So in kernel coding style you often have:

	if (condition) do_something();

Or

	if (condition)
		do_something();

But in Rust it will be:

	if condition {
	    do_something();
	}

That's just an example of one control flow constructions. There are
differences between Rust match and C switch, etc. Rust's official
coding style takes properties of Rust into consideration, so in many
regards it's a more suitable coding style for Rust code in kernel, then
applying kernel's C coding standard directly on kernel's Rust code.

Your earlier email in the thread also mentions about indentation, and I
have a few things to point out as well.

First, Rust code typically requires more levels of indentation than C
code. For example, many functions might be methods and they are inside
an impl block, which creates one extra level of indentation.
Statements inside match arms' block are two levels more indented than
the match statement itself, as opposed to C's switch (as kernel coding
style doesn't indent the case labels). As a result, 8 spaces for 1 level
can be a bit excessive for Rust code, and thus the 4 space indentation
used in rustfmt default.

Secondly, I don't think the argument about tabs being customisable
holds; in kernel coding style tabs are strictly 8 characters. For line
continuation it's not uncommon to use a series of tabs followed by a
few spaces, e.g.

	int function_name(int first_argument,
	< tab  >< tab  >..int second_argument)

changing tab into 4 spaces will break the layout. (and I'll not go into
well-known reasons about non-4-space-tab messing up code in terminal
etc).

> Copy/pasting is known to cause bugs. There's actually research from
> NASA on that. Code-reuse (libraries/functions) are not bad. But
> (worst kind of example) copy paste from stack-overflow, or
> copy/pasting stuff without actually looking at the content and
> forgetting to rename something, causes bugs. Why is this relevant?
> The whole 'lets be consistent with the rust codebase of the wrold'
> argument. E.g. if everybody uses the same style (which is idealistic
> and great) then copy/pasting becomes consistent. Where I say, try to
> be careful when copy/pasting code.

When we vendor in code as a whole (e.g. like we currently do for
alloc crate), it is proper code reuse. With different coding style the
vendored code either diverges from upstream (which makes upstreaming
much more difficult) or diverge from rest of kernel's Rust code base.

> But if that is the case, why not try to follow the kernels existing 
> code-style as close as possible with the rust-fmt configuration? I
> know code-style has been discussed a few times over the decades; but
> not many changes have been done, surely, if there's some codestyle
> changes that are best for the kernel, they would have been 'advised'?
> '4 space indents are better then 8-size tabs, on new code, try to use
> them' for example :p

You do realize that you are creating a new coding style by doing this,
right? It feels like creating problems rather than solving problems.

My personal feeling is that it's easier for me to adapt to different
coding style when switching between languages, but it's rather awkward
for me when trying to use different coding styles with the same
language. I find myself no problem switching between 2 spaces when
coding JavaScript to 4 spaces when coding Rust to 8 spaces(tab) when
coding C, but it's rather painful to switch between C projects with
different coding styles. I certainly don't want to switch between Rust
projects with vastly different coding styles.

> But why? Why should we not be consistent with the kernels' code-base 
> (while yes, that is not rust, but C, but we can follow the same
> style?)

Difference languages have different characteristics, and one size
doesn't fit them all :)

> Sadly, I've seen so much vendor code (yeah, I know) which doesn't
> even have consistency in their own files ...

That's very true. So when all other Rust code currently follow
(roughly) the same coding style and this situation doesn't currently
exist, let's not make it worse...

Best,
Gary