On Wed, 10 Aug 2005, Daniel Phillips wrote: > On Tuesday 09 August 2005 10:15, Nick Piggin wrote: > > Daniel Phillips wrote: > > > Why don't you pass the vma in zap_details? > > > > Possibly. I initially did it that way, but it ended up fattening > > paths that don't use details. > > It should not, it only affects, hmm, less than 10 places, each at the > beginning of a massive call chain, e.g., in madvise_dontneed: > > - zap_page_range(vma, start, end - start, NULL); > + zap_page_range(start, end - start, &(struct zap){ .vma = vma }); > > > And this way is less intrusive. > > Nearly the same I think, and makes forward progress in controlling this > middle-aged belly roll of an internal API.
I much prefer how Nick has it, with vma passed separately as a regular argument. details is for packaging up some details only required in unlikely circumstances, normally it's NULL and not filled in at all. You can argue that (vma->vm_flags & VM_RESERVED) is precisely that kind of detail. But personally I find it rather odd that vma isn't an explicit argument to zap_pte_range already - I find it very useful when trying to shed light on the rmap.c:BUG, for example. There might be a case for packaging repeated arguments into structures (though several of these levels are inlined anyway), but that's some other exercise entirely, shouldn't get in the way of removing Reserved. Hugh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/