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