On Wed, Oct 12, 2022 at 12:21 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > On Wed, Oct 12, 2022, David Matlack wrote: > > Rename the perf_test_util.[ch] files to memstress.[ch]. Symbols are > > renamed in the following commit to reduce the amount of churn here in > > Heh, "following commit" is now stale. This is why I encourage using ambiguous > phrases, e.g. "in a future commit". > > This should also be phrased as a command, not a statement of truth. E.g. in the > extremely unlikely scenario that symbols are never renamed, this statement is > wrong, whereas something like > > Defer renaming symbols to a future patch to reduce the amount of churn > here in the hopes of playing nice with git's file rename detection. > > states only what is done in the context of this patch while still calling out > that the intent is to rename symbols in the (near) future. > > To be 100% clear, I'm not saying don't describe future changes, there's a _lot_ > of value in knowing that a patch is prep work for the future. I'm saying don't > explicitly predict the future, because occassionally the prediction will be wrong > and the changelog ends up confusing archaeologists. That makes a lot of sense -- will do in the future. Thanks! > > > hopes of playiing nice with git's file rename detection. > > s/playiing/playing > > > The name "memstress" was chosen to better describe the functionality > > proveded by this library, which is to create and run a VM that > > reads/writes to guest memory on all vCPUs in parallel. > > > > "memstress" also contains the same number of chracters as "perf_test", > > making it a drop-in replacement in symbols, e.g. function names, without > > impacting line lengths. Also the lack of underscore between "mem" and > > "stress" makes it clear "memstress" is a noun. > > > > Signed-off-by: David Matlack <dmatlack@xxxxxxxxxx> > > Changelog nits aside, > > Reviewed-by: Sean Christopherson <seanjc@xxxxxxxxxx>
