Re: [PATCH v8 2/2] rust: xarray: Add an abstraction for XArray

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


On Fri, Mar 22, 2024 at 2:20 AM Boqun Feng <boqun.feng@xxxxxxxxx> wrote:
> One more extra point from myself only: if one is using Rust for drivers
> or subsystem they are going to take care of it in the future, it's
> totally fine for them to pick coding styles that they feel comfortable,
> I don't want to make people who do the real work feel frustrated because
> "this is how Rust idioms must be", also I don't believe tools should
> restrict people. But in the "kernel" crate (i.e. for core kernel part),
> I want to make it "Rusty" since it's the point of the experiement ("you
> asked for it ;-)).

We should aim to be as consistent as possible for all the kernel, not
just the "core kernel".

Yes, there should be flexibility. In fact, sometimes it is just
impossible, unreasonable, impractical and/or annoying to be
consistent. And, as you say, we should definitely avoid making people
frustrated for inane reasons.

But we should not introduce flexibility for bad reasons either.

And this is the kind of thing that it is very hard to restrict later.
So even if we are a bit "over the top" in some cases now (the current
compiler/Clippy flags could be already arguably so, at times), the
point is to figure out what makes sense to keep long term. In other
words, instead of discussing how to create local coding styles, we
should be discussing what should be changed for everybody (e.g.
because a particular diagnostic may too annoying now, because a style
is found to be better than another like `if ret < 0 ...` vs.
`to_result` and so on).


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux