On Thu, 2021-03-18 at 00:15 +0000, Matthew Wilcox wrote: > On Wed, Mar 17, 2021 at 04:19:06PM -0700, James Bottomley wrote: > > On Wed, 2021-03-17 at 22:54 +0000, Matthew Wilcox wrote: > > > On Wed, Mar 17, 2021 at 03:15:12PM -0700, > > > akpm@xxxxxxxxxxxxxxxxxxxx > > > wrote: > > > > Several architectures already have definition of PMD_ORDER as > > > > the size of second level page table, so to avoid conflict with > > > > these definitions use PMD_PAGE_ORDER name and update DAX > > > > respectively. > > > > > > I thought I NACKed this patch already? > > > > I don't think anyone understands why. DAX won't build on several > > architectures, including parisc, because of this existing symbol > > clash. > > > > > The architectures should be updated to not use > > > PMD_ORDER. PMD_ORDER is clearly the right name for what is now > > > PMD_PAGE_ORDER. The architectures should be using > > > PMD_ALLOC_ORDER or some such. > > https://lore.kernel.org/linux-fsdevel/20201204034843.GM11935@xxxxxxxxxxxxxxxxxxxx/ > was where I said what I wanted. Well that's nothing to do with this patch. This patch is just trying to extract the DAX definition up into a global header. Could we agree on PAGE_PMD_ORDER since the hugepage equivalent is called HPAGE_PMD_ORDER? That would at least make the naming consistent and also solve the symbol clash ... then we can separately argue who wants to go and ask all the architectures to rename their PMD_ORDER definitions. > > Well I had a patch renaming the dax specific one to DAX_PMD_ORDER > > which you also didn't like. Why don't you just propose the patch > > you do like because this is a build failure on several > > architectures currently. > > > > I don't really care what colour the bike shed is ... I do care that > > my builds fail. > > I was expecting you to do the rename, since it's inconveniencing you. > It doesn't cause me any trouble at all. I fixed it by not building dax in the default parisc configs. James
