linux-kernel - Re: [PATCH v3 1/1] rust: device: rename "Device::from

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAM_RzfbaAQT5cPhx7aB+uqgKcsHq-fnv_Jt63_p9CJ96rs6J9g@mail.gmail.com>
Date: Mon, 30 Sep 2024 13:45:02 -0300
From: Guilherme Giácomo Simões <trintaeoitogc@...il.com>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: Greg KH <gregkh@...uxfoundation.org>, rafael@...nel.org, ojeda@...nel.org, 
	alex.gaynor@...il.com, boqun.feng@...il.com, gary@...yguo.net, 
	bjorn3_gh@...tonmail.com, benno.lossin@...ton.me, mcgrof@...nel.org, 
	russ.weight@...ux.dev, dakr@...hat.com, a.hindborg@...nel.org, 
	rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/1] rust: device: rename "Device::from_raw()"

Alice Ryhl <aliceryhl@...gle.com> wrote:
>
> You can use one of my patches as an example. E.g.:
> https://lore.kernel.org/all/20240930-static-mutex-v4-1-c59555413127@google.com/
>
> Here, the commit message itself has:
> 1. Motivation for why we should add global lock support. (To replace a
> hack I had to use in the Binder driver.)
> 2. Explanation for why I implemented it in a certain way. (Why
> separate initialization step?)
>
> Then, below the --- line and not part of the commit message, I have:
> 1. Information about which patches it depends on.
> 2. A changelog and links to previous versions.
>
> Anything below the --- line will not be part of the commit history
> when your change is merged. So you should think about what people
> would want to see when they look at your patch in the commit history.
> They care about why the change was made, and why it was implemented
> that way. What other things need to be merged first are not relevant
> to people who see the final version after it has been merged.
>
> Similarly, the changelog is important for reviewers so they can
> compare with the previous version, but for people who just see the
> final version, they don't care about which bugs you had in previous
> versions of the patch. Of course, if you change the implementation
> approach, then they might care about why you chose that approach over
> some other approach, but that explanation should be in the commit
> message (and the changelog should just say you changed the approach).
>
> Alice

This really make sense. I will resend a v4 version of this patch,
without 0/1.

Tanks for this Mrs. Ryhl.