| Message ID | 20231116012908.392077-2-peterx@redhat.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | mm/gup: Unify hugetlb, part 2 | expand |
You're (thankfully) not actually exporting anything, so please don't claim that in the subject. > pte_t *huge_pmd_share(struct mm_struct *mm, struct vm_area_struct *vma, > unsigned long addr, pud_t *pud); > +bool hugetlbfs_pagecache_present(struct hstate *h, > + struct vm_area_struct *vma, > + unsigned long address); Can you just follow the much more readable two tab indent of the function above? > -static bool hugetlbfs_pagecache_present(struct hstate *h, > - struct vm_area_struct *vma, unsigned long address) > +bool hugetlbfs_pagecache_present(struct hstate *h, > + struct vm_area_struct *vma, unsigned long address) Same here. The new indentation not only is less readable but also creates a pointlessly overlong line.
On Wed, Nov 22, 2023 at 11:23:07PM -0800, Christoph Hellwig wrote: > You're (thankfully) not actually exporting anything, so please > don't claim that in the subject. Ah, I'll rename the subject to "mm/hugetlb: Declare hugetlbfs_pagecache_present() non-static". > > > pte_t *huge_pmd_share(struct mm_struct *mm, struct vm_area_struct *vma, > > unsigned long addr, pud_t *pud); > > +bool hugetlbfs_pagecache_present(struct hstate *h, > > + struct vm_area_struct *vma, > > + unsigned long address); > > Can you just follow the much more readable two tab indent of the > function above? > > > -static bool hugetlbfs_pagecache_present(struct hstate *h, > > - struct vm_area_struct *vma, unsigned long address) > > +bool hugetlbfs_pagecache_present(struct hstate *h, > > + struct vm_area_struct *vma, unsigned long address) > > Same here. The new indentation not only is less readable but also > creates a pointlessly overlong line. I can easily follow what you suggest for this single patch, but afaict the kernel doesn't document that in the style guide. https://www.kernel.org/doc/html/v4.10/process/coding-style.html#functions And the reality is at least across mm codes it's used in a mixture of ways, even more than these two major forms of indentations. To be explicit, I think 2-tab is Vim's default, while this patch follows Emacs's c-mode default. It means if this patch indents wrongly, probably 99% of Emacs users are doomed. :( Before we have a clear and thorough rule over this, shall we just allow either sane indent to still be accepted? Or maybe there's some rule that I have missed? Personally I actually prefer Emacs's indentations to align with left bracket, but that's just subjective so doesn't count. Thanks,
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index 236ec7b63c54..bb07279b8991 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -174,6 +174,9 @@ u32 hugetlb_fault_mutex_hash(struct address_space *mapping, pgoff_t idx); pte_t *huge_pmd_share(struct mm_struct *mm, struct vm_area_struct *vma, unsigned long addr, pud_t *pud); +bool hugetlbfs_pagecache_present(struct hstate *h, + struct vm_area_struct *vma, + unsigned long address); struct address_space *hugetlb_page_mapping_lock_write(struct page *hpage); diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 6feb3e0630d1..29705e5c6f40 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -6018,8 +6018,8 @@ static vm_fault_t hugetlb_wp(struct mm_struct *mm, struct vm_area_struct *vma, /* * Return whether there is a pagecache page to back given address within VMA. */ -static bool hugetlbfs_pagecache_present(struct hstate *h, - struct vm_area_struct *vma, unsigned long address) +bool hugetlbfs_pagecache_present(struct hstate *h, + struct vm_area_struct *vma, unsigned long address) { struct address_space *mapping = vma->vm_file->f_mapping; pgoff_t idx = linear_page_index(vma, address);
It will be used outside hugetlb.c soon. Signed-off-by: Peter Xu <peterx@redhat.com> --- include/linux/hugetlb.h | 3 +++ mm/hugetlb.c | 4 ++-- 2 files changed, 5 insertions(+), 2 deletions(-)