> > 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. Pasha
