| Message ID | 1458499278-1516-2-git-send-email-kirill.shutemov@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sun, Mar 20, 2016 at 11:54:56AM -0700, Linus Torvalds wrote: > I'm OK with this, but let's not do this as a hundred small patches, OK? > > It doesn't help legibility or testing, so let's just do it in one big go. Might make sense splitting it by the thing being removed, though - easier to visually verify that it's doing the right thing when all replacements are of the same sort... -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Mar 20, 2016 at 12:00 PM, Al Viro <viro@zeniv.linux.org.uk> wrote: >> >> It doesn't help legibility or testing, so let's just do it in one big go. > > Might make sense splitting it by the thing being removed, though - easier > to visually verify that it's doing the right thing when all replacements > are of the same sort... Yeah, that might indeed make each patch easier to read, and if something goes wrong (which looks unlikely, but hey, shit happens), it also makes it easier to see just what went wrong. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Mar 20, 2016 at 12:13:47PM -0700, Linus Torvalds wrote: > On Sun, Mar 20, 2016 at 12:00 PM, Al Viro <viro@zeniv.linux.org.uk> wrote: > >> > >> It doesn't help legibility or testing, so let's just do it in one big go. > > > > Might make sense splitting it by the thing being removed, though - easier > > to visually verify that it's doing the right thing when all replacements > > are of the same sort... > > Yeah, that might indeed make each patch easier to read, and if > something goes wrong (which looks unlikely, but hey, shit happens), it > also makes it easier to see just what went wrong. Hm. Okay. Re-split this way would take some time. I'll post updated patchset tomorrow.
On Sun, Mar 20, 2016 at 12:34 PM, Kirill A. Shutemov <kirill.shutemov@linux.intel.com> wrote: > > Hm. Okay. Re-split this way would take some time. I'll post updated > patchset tomorrow. Oh, I was assuming this was automated with coccinelle or at least some simple shell scripting.. Generally, for things like this, automation really is great. In fact, I like it when people attach the scripts to the commit message, further clarifying exactly what they did (even if the end result then often includes manual fixups for patterns that didn't _quite_ match, or where the automated script just generated ugly indentation or similar). Linus -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 20 Mar 2016, Linus Torvalds wrote: > On Sun, Mar 20, 2016 at 12:34 PM, Kirill A. Shutemov > <kirill.shutemov@linux.intel.com> wrote: > > > > Hm. Okay. Re-split this way would take some time. I'll post updated > > patchset tomorrow. > > Oh, I was assuming this was automated with coccinelle or at least some > simple shell scripting.. > > Generally, for things like this, automation really is great. > > In fact, I like it when people attach the scripts to the commit > message, further clarifying exactly what they did (even if the end > result then often includes manual fixups for patterns that didn't > _quite_ match, or where the automated script just generated ugly > indentation or similar). Fine by me to make these changes - once upon a time I had a better grip than most of when and how to use PAGE_CACHE_blah; but have long lost it, and agree with all those who find the imaginary distinction now a drag. Just a plea, which I expect you already intend, to apply these changes either just before 4.6-rc1 or just before 4.7-rc1 (I think I'd opt for 4.6-rc1 myself), without any interim of days or months in linux-next, where a period of divergence would be quite tiresome. Holding back Kirill's 71/71 until the coast is clear just a little later. Thanks, Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arc/mm/cache.c b/arch/arc/mm/cache.c index b65f797e9ad6..d9bacb4199ea 100644 --- a/arch/arc/mm/cache.c +++ b/arch/arc/mm/cache.c @@ -621,7 +621,7 @@ void flush_dcache_page(struct page *page) /* kernel reading from page with U-mapping */ phys_addr_t paddr = (unsigned long)page_address(page); - unsigned long vaddr = page->index << PAGE_CACHE_SHIFT; + unsigned long vaddr = page->index << PAGE_SHIFT; if (addr_not_cache_congruent(paddr, vaddr)) __flush_dcache_page(paddr, vaddr);
PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} macros were introduced *long* time ago with promise that one day it will be possible to implement page cache with bigger chunks than PAGE_SIZE. This promise never materialized. And unlikely will. We have many places where PAGE_CACHE_SIZE assumed to be equal to PAGE_SIZE. And it's constant source of confusion on whether PAGE_CACHE_* or PAGE_* constant should be used in a particular case, especially on the border between fs and mm. Global switching to PAGE_CACHE_SIZE != PAGE_SIZE would cause to much breakage to be doable. Let's stop pretending that pages in page cache are special. They are not. The changes are pretty straight-forward: - <foo> << (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>; - PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} -> PAGE_{SIZE,SHIFT,MASK,ALIGN}; - page_cache_get() -> get_page(); - page_cache_release() -> put_page(); Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Vineet Gupta <vgupta@synopsys.com> --- arch/arc/mm/cache.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)