On Thu, Feb 8, 2024 at 10:08 AM Pasha Tatashin <pasha.tatashin@xxxxxxxxxx> wrote: > > > > I am not closely following this series, but I just wanted to point out > > > that this is not always true. We are actively extending > > > NR_SECONDARY_PAGETABLE to add IOMMU page tables in addition to KVM > > > page tables [1]. In that case as well, the name was left open-ended > > > exactly for this purpose [2]. > > > > I think you're glossing over quite some nuance here. > > > > Sure there might be highly specific scenarios where you can get away > > with it. Like with a very recently introduced counter for somewhat > > niche audiences, and bucketing/grouping that was IIRC planned from the > > start. It's probably not reasonable to advocate nondescript interface > > names as a strategy for getting out of ABI commitments. > > > > My point was that "memmap" is the established term for what the author > > describes. And that this concept is sufficiently first-class that > > mixing it with other things later is unlikely to be acceptable. I > > didn't know WHY a new name for this was chosen, so I provided > > arguments for two motivations that I could think of, that's all. > > Sure, we can rename it to NR_MEMMAP_BOOT / NR_MEMMAP. We picked > NR_PAGE_METADATA_BOOT/NR_PAGE_METADATA as we thought it was a clearer > choice. It directly conveys the concept of page metadata overhead, > eliminating ambiguity about future potential structures. Today, it is > "struct page", and "pag_ext", tomorrow memdesc and more. Technically, page_ext is not part of memmap if we go by the kernel code, right? > Pasha
