On Sun, 2014-07-20 at 02:38 +0900, sf...@users.sourceforge.net wrote: > Hello Ian, > > Ian Campbell: > > This include is added by aufs3-mmap.patch but causes circular > > dependencies on arm64 as seen with the Debian kernel packages in > ::: > > According to http://article.gmane.org/gmane.linux.ports.arm.kernel/342042 > > > The added mm.h->fs.h looks like a mistake, it should not be there, and we= > > have > > > in the past worked hard to separate mm.h, sched.h and fs.h from one anoth= > > er. > > Hmm, I didn't know such history... > Anyway I agree mmap approach in aufs is ugly in the terms of its logic > and looking. And I am afraid converting into macros looks still > bad-looking. Do you think can we do this? > - create a new file mm/aufs_mmap.c > - move the inline funcs to the new file. > - the calling macros are left in mm.h. > - function delarations are added in mm.h.
That sounds like a plausible plan to me. > > Also take the opportunity to wrap the vmr_* macros in ifndef CONFIG_MMU > > Is it necessary? > struct vm_regin is defined regardless CONFIG_MMU, isn't it? It is defined but not used except when !CONFIG_MMU and the comment preceding the definition confirms it is !MMU specifc. The type is only used in fs/proc/nommu.c, fs/proc/task_nommu.c and mm/nommu.c. The only users of the two vmr_* macros/inlines are in mm/nommu.c. Ian. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1405798845.27009.30.ca...@dagon.hellion.org.uk