Re: [PATCH 00/13] [RFC] Rust support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux