On Thu, Feb 20, 2020 at 06:43:31PM -0800, John Hubbard wrote: > Yes. But I think these files also need a similar change: > > fs/btrfs/disk-io.c That gets pagemap.h through ctree.h, so I think it's fine. It's already using mapping_set_gfp_mask(), so it already depends on pagemap.h. > fs/nfs/super.c That gets it through linux/nfs_fs.h. I was reluctant to not add it to blk-core.c because it doesn't seem necessarily intuitive that the block device core would include pagemap.h. That said, blkdev.h does include pagemap.h, so maybe I don't need to include it here. > ...because they also use VM_READAHEAD_PAGES, and do not directly include > pagemap.h yet. > > +#define VM_READAHEAD_PAGES (SZ_128K / PAGE_SIZE) > > + > > +void page_cache_sync_readahead(struct address_space *, struct file_ra_state *, > > + struct file *, pgoff_t index, unsigned long req_count); > > Yes, "struct address_space *mapping" is weird, but I don't know if it's > "misleading", given that it's actually one of the things you have to learn > right from the beginning, with linux-mm, right? Or is that about to change? > > I'm not asking to restore this to "struct address_space *mapping", but I thought > it's worth mentioning out loud, especially if you or others are planning on > changing those names or something. Just curious. No plans (on my part) to change the name, although I have heard people grumbling that there's very little need for it to be a separate struct from inode, except for the benefit of coda, which is not exactly a filesystem with a lot of users ... Anyway, no plans to change it. If there were something _special_ about it like a theoretical: void mapping_dedup(struct address_space *canonical, struct address_space *victim); then that's useful information and shouldn't be deleted. But I don't think the word 'mapping' there conveys anything useful (other than the convention is to call a 'struct address_space' a mapping, which you'll see soon enough once you look at any of the .c files).
