Date: Wed, 30 Sep 1998 12:46:52 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: David Greenman <dg@root.com> Cc: Terry Lambert <tlambert@primenet.com>, current@FreeBSD.ORG Subject: Re: VM mmap file extension bug still exists? Message-ID: <Pine.BSF.3.95.980930123944.13393B-100000@current1.whistle.com> In-Reply-To: <199809300920.CAA04277@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
well, yes, I considered doing that. but couldn't convince myself that there was no case where the user is mapping only PART of a file, and that 'size' might represent the mapped region size (in pages) where "size_in_bytes" is the filesize. In many cases these are the same, but I wasn't confident enough in my understanding of this code to state publically that one value could always be derived from the other. In fact I managed to0 convince myself that it was likely that this was not always the case, and took the safe route. julian On Wed, 30 Sep 1998, David Greenman wrote: > >> It's definitely a workaround. The real fix is to add a parementer to > >> the mapping function. > > > >Ok here's the patch done the 'correct way' > >I have looked at the problem with terry and he has convinced me that > >there IS a problem there. > > Well, as I said in previous email, I'm not convinced that adding another > argument to the pager_alloc functions is "correct", and I think your patches > pretty well demonstrate that. It appears to me that in every case, the > "size_in_bytes" is just the non-rounded/indexed version of the original > "size" parameter, so why don't we simply change the definition of "size" to > be an off_t number of bytes and then do the OFF_TO_IDX translation in the > pager(s) as necessary, instead of at the caller? > > -DG > > David Greenman > Co-founder/Principal Architect, The FreeBSD Project > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.980930123944.13393B-100000>