Re: [PATCH] mm: Convert memory block states (MEM_*) macros to enum

Lorenzo Stoakes <[email protected]> Tue, 28 Oct 2025 19:13:37 +0000
Newsgroups org.kernel.vger.linux-debuggers,org.kvack.linux-mm
Message-ID <[email protected]>
On Tue, Oct 28, 2025 at 07:06:00PM +0000, Israel Batista wrote:
>
>
> On 10/28/25 13:34, Lorenzo Stoakes wrote:
> > On Mon, Oct 27, 2025 at 11:53:57PM +0000, Israel Batista wrote:
> > >
> > >
> > > On 10/27/25 16:46, Lorenzo Stoakes wrote:
> > >
> > > >
> > > > So why are we naming the type... does drgn require it?
> > > >
> > >
> > > It doesn't need to be named, but as David pointed out, we could find
> > > where these values are being used and replace the type with the proper
> > > enum. I quickly grepped the codebase and it seems doable, I'm probably
> > > adding these changes to the next version of this patch since there are
> > > some things to fix anyway.
> >
> > I mean we're getting a little out of scope here but fine, if these are not
> > in fact used as flags, I don't mind, just remove the silly 1 << x values
> > while you do it.
>
> Could you also point me to what tree is preferred to base the patches
> for the mm subsystem, please? There are differences between linux-next
> and the current version of mainline regarding these values.
> (MEM_PREPARE_OFFLINE and MEM_FINISH_OFFLINE are being removed on
> linux-next).
>
> So I would appreciate if you could indicate what tree is the best to
> base my changes, as I'm not that familiar with this subsystem.

Sure it's not at all obvious atm (mea culpa mm :)

So the tree is at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/

The best branch is mm-new, however this is the 'crazy' branch where _every
ongoing series_ that isn't found to be broken is taken as a testing ground and
base point for development to avoid conflicts.

I tend to base all my series on mm-new, as series must apply against it to be
taken there of course (though Andrew may resolve simpler conflicts).

The more stable ground (despite the name) is mm-unstable, which is everything
that has sat in mm-new long enough to be likely to be sent to Linus for the next
release, and it's mm-unstable that gets set to linux-next.

_Generally speaking_ your series should apply against both. If it doesn't, I'd
base it on mm-new.

So in general TL;DR mm-new is the way to go.

Cheers, Lorenzo