Messages in this thread | | | Date | Fri, 20 Feb 2004 06:01:16 -0800 | From | "Paul E. McKenney" <> | Subject | Re: Non-GPL export of invalidate_mmap_range |
| |
On Fri, Feb 20, 2004 at 03:37:26PM -0500, Daniel Phillips wrote: > Hi Paul, > > > I cannot think of any reasonable alternative to passing the parameter > > down either, as it certainly does not be reasonable to duplicate the > > code... > > Yes, it's simply the (small) price that has to be paid in order to be able to > boast about our accurate semantics.
;-)
> > How about something like "private_too" instead of "zap"? > > How about just "all", which is what we mean.
Fair enough, certainly keeps a few more lines of code within 80 columns.
> > > -void zap_page_range(struct vm_area_struct *vma, > > > - unsigned long address, unsigned long size) > > > +void invalidate_page_range(struct vm_area_struct *vma, > > > > Would it be useful for this to be inline? (Wouldn't seem so, > > zapping mappings has enough overhead that an extra level of > > function call should be deep down in the noise...) > > Yes, it doesn't seem worth it just to save a stack frame. > > Actually, I erred there in that invalidate_mmap_range should not export the > flag, because it never makes sense to pass in non-zero from a DFS.
Doesn't vmtruncate() want to pass non-zero "all" in to invalidate_mmap_range() in order to maintain compatibility with existing Linux semantics?
> > Doesn't the new argument need to be passed down through > > invalidate_mmap_range_list()? > > It does, thanks for the catch. Please bear with me for a moment while I > reroll this, then hopefully we can move on to the more interesting discussion > of whether it's worth it. (Yes it is :)
;-)
Thanx, Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |