Re: Process for doing early internal type review on the list

[Sean Christopherson <seanjc@google.com>]

On Thu, Aug 27, 2026, Rick P Edgecombe wrote:
> Arg, fix Kiryl's email address.
> 
> On Wed, 2026-08-26 at 16:59 -0700, Rick Edgecombe wrote:
> > Sean has long been pushing TDX developers to review less internally and capture
> > everything on the list. For several reasons:
> >  - Avoid thrash by hashing out things internally that are just overturned later.
> >  - Capture all the design decisions in lore history.
> >  - Help developers grow by getting comfortable working and making mistakes in   
> >    public.
> >  - A strong personal conviction that through some confluence of intangibles,
> >    working in public produces better outcomes for the kernel?

As evidence, I submit the myriad historical KVM commits with godawful changelogs
and no meaningful on-list review/discussion.  When things go wrong, knowing the
intent and being able to retroactively assess the review process that yielded the
final commit is extremely valuable.

E.g. KVM added 600+ lines of code to (very poorly) virtualize MTRR memtypes, and
carried it for more than 15 years, all because of misdiagnosed #MC issues that
showed up in early EPT + VTd enabling.

Even with the few breadcrumbs provided by on-list review, it took me for freaking
ever to piece together what happened[*].  If all of the review had been done in
private, and all we saw was the final result, then it's entirely possible we'd
still be carrying the MTRR virtualization horrors.

Another way to look at it: would anyone (seriously) argue that changelogs are a
waste of time?  People can read the code, why do we need to explain what it does
and why?  Because anytime future developers are forced to make assumptions or
guesses due to lack of information, the probability of a mistake being and/or a
bug being introduced goes up.  And has been proven a hilarious number of times
this year by AI, humans make a lot of mistakes, and the more information that's
available, the easier it is to decipher and remedy those mistakes.

"Documenting" mistakes is also extremely valuable for helping others avoid those
same mistakes.  E.g. look at all the bajlilion edge cases and wrinkles Sashiko is
pointing out.  Having a public record of exactly what can go wrong, or what sharp
edges exist, is a huge benefit to future developers.  How many times have folks
ended up on Stack Overflow trying to figure out how to do some obsurce thing with
e.g. inline asm?  This is the same thing, just specific to the kernel.  It's a
public, searchable record of potential/common issues and in many cases, the cures
for those issues.

[*] https://lore.kernel.org/all/20240309010929.1403984-2-seanjc@google.com