Re: [PATCH 00/32] x86/msr: Drop 32-bit MSR interfaces

Sean Christopherson <[email protected]>
Newsgroups org.kernel.vger.linux-fbdev,dev.linux.lists.linux-coco,dev.linux.lists.virtualization,org.freedesktop.lists.dri-devel,org.infradead.lists.linux-mtd,org.kernel.vger.kvm,org.kernel.vger.linux-acpi,org.kernel.vger.linux-crypto,org.kernel.vger.linux-edac,org.kernel.vger.linux-gpio,org.kernel.vger.linux-hwmon,org.kernel.vger.linux-hyperv,org.kernel.vger.linux-ide,org.kernel.vger.linux-kernel,org.kernel.vger.linux-pci,org.kernel.vger.linux-perf-users,org.kernel.vger.linux-pm,org.kernel.vger.platform-driver-x86,org.xenproject.lists.xen-devel
Message-ID <[email protected]>
On Mon, Jun 29, 2026, Ingo Molnar wrote:
> * Arnd Bergmann <[email protected]> wrote:
> 
> > >>> Note that most patches of this series are independent from each other.
> > >>> Only the patches removing a specific interface (patches 7, 15, 26 and
> > >>> 30) and the last two patches of the series depend on all previous
> > >>> patches.
> > >> 
> > >> It looks like you are touching most files twice or more here, to
> > >> first convert from rdmsr to rdmsrq and then to change the
> > >> two-argument rdmsrq() macro to a single-argument inline. If you
> > >> introduce the inline version of rdmsrq() first, you should be
> > >> able to skip the second step (patch 31) as they could be able
> > >> to coexist.
> > >
> > > I've discussed how to structure the series with Ingo Molnar before [1]. The
> > > current approach was his preference.
> > 
> > Ok.
> 
> Note that the individual patches are IMO significantly easier to review
> through the actual 32-bit => 64-bit variable assignment changes done
> in isolation (which sometimes include minor cleanups), while
> the Coccinelle semantic patch:
> 
>    { a(b,c) => c = a(b) }
> 
> which changes both the function signature and the order of terms as
> well, is just a single add-on treewide patch.

Is the plan for subsystem maintainers to pick up the relevant patches, and then
do the treewide change one release cycle later?
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.