[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiq72mh2_QhHcE65-t+6UEEqe+9XwGQ3gJ1CCQpZ6r3HOcokQ@mail.gmail.com>
Date: Mon, 9 Dec 2024 12:47:46 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Daniel Sedlak <daniel@...lak.dev>
Cc: guilherme giacomo simoes <trintaeoitogc@...il.com>, Wayne Campbell <wcampbell1995@...il.com>, ojeda@...nel.org,
alex.gaynor@...il.com, boqun.feng@...il.com, gary@...yguo.net,
bjorn3_gh@...tonmail.com, benno.lossin@...ton.me, a.hindborg@...nel.org,
aliceryhl@...gle.com, tmgross@...ch.edu, walmeida@...rosoft.com,
fujita.tomonori@...il.com, tahbertschinger@...il.com,
rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [PATCH] rust: macros: add authors
On Sat, Dec 7, 2024 at 11:15 AM Daniel Sedlak <daniel@...lak.dev> wrote:
>
> I think we could fight with the code formatting, because when it comes
> to the rust macros, rustfmt is often very confused and we could end up
> with variations like:
>
> authors: ["author1", "author2",
> "author3"]
>
> or
>
> authors: [
> "author1",
> "author2",
> ]
>
> and rustfmt would be totally ok with both of them.
Yeah, that is a good point. There are hundreds of drivers with 2+
authors, so this could indeed be an issue eventually.
Having said that, we already have e.g. the `alias` and `firmware` keys
that take a list, so I think we already have the potential issue, thus
being consistent in our use of lists sounds simpler (unless we are
discussing migrating those away too).
We could also try to mitigate the formatting issue via e.g.
`checkpatch.pl` if needed.
Thanks!
Cheers,
Miguel
Powered by blists - more mailing lists