Hey Miguel and others,
Having followed this for a while, I finally decided it best to at least
share some thoughts in the hopes to make life better for us with some
readability/accessibility issues, such as dyslexia for example.
I apologize for being late to the party and for potentially using the
wrong thread, but I recall somewhere in v5 that it was best to respond
to the RFC for general comments.
On 14-04-2021 20:45, ojeda@xxxxxxxxxx wrote:
From: Miguel Ojeda <ojeda@xxxxxxxxxx>
Some of you have noticed the past few weeks and months that
a serious attempt to bring a second language to the kernel was
being forged. We are finally here, with an RFC that adds support
for Rust to the Linux kernel.
This cover letter is fairly long, since there are quite a few topics
to describe, but I hope it answers as many questions as possible
before the discussion starts.
<snip>
Moreover, as explained above, we are taking the chance to enforce
some documentation guidelines. We are also enforcing automatic code
formatting, a set of Clippy lints, etc. We decided to go with Rust's
idiomatic style, i.e. keeping `rustfmt` defaults. For instance, this
means 4 spaces are used for indentation, rather than a tab. We are
happy to change that if needed -- we think what is important is
keeping the formatting automated
Enforcing this is great, but how will you enforce this 'everywhere'?
Right now, you can easily 'bypass' any CI put in place, and while 'for
now' this is only about the Rust infra, where this can be strongly
enforced, once we see actual drivers pop-up; these won't go through the
Rust CI before merging CI forever? A maintainer can 'just merge'
something still, right?
Anyway, what I wanted to criticize, is the so called "keeping with
`rustfmt` defaults". It has been known, that, well Rust's defaults are
pretty biased and opinionated. For the Rust project, that's fair of
course, their code, their rules.
However, there's two arguments against that. For one, using the Rust
'style', now means there's 2 different code styles in the Kernel.
Cognitively alone, that can be quite frustrating and annoying. Having to
go back and forth between two styles can be mentally challenging which
only causes mistakes and frustration. So why change something that
already exists? Also, see my first point. Having to constantly
remember/switch to 'in this file/function the curly brace is on a
different line'. Lets try to stay consistent, the rules may not be
perfect (80 columns ;), but so far consistency is tried. OCD and Autism
etc doesn't help with this ;)
Secondly, and this is really far more important, the Rust default style
is not very inclusive, as it makes readability harder. This has been
brought up by many others in plenty of places, including the `rustfmt`
issue tracker under bug #4067 [0]. While the discussion eventually only
led to the 'fmt-rfcs' [1], where it was basically said 'you could be on
to something, but this ship has sailed 3 years ago (when nobody was
looking caring), and while we hear you, we're not going to change our
defaults anymore.
But I also agree and share these commenters pain. When the tab character
is used for indenting (and not alignment mind you), then visually
impaired (who can still be amazing coders) can more easily read code by
adjusting the width what works best to them.
With even git renaming `master` to `main` to be more inclusive, can we
also be more inclusive to us that have a hard time distinguishing narrow
indentations?
Thanks, and sorry for rubbing any ones nerves, but to "some of us" this
actually matters a great deal.
Olliver
P.S. would we expect inline C/Rust code mixed? What then?
<snip>
[0]: https://github.com/rust-lang/rustfmt/issues/4067#issuecomment-685961408
[1]:
https://github.com/rust-dev-tools/fmt-rfcs/issues/1#issuecomment-911804826
