Hi Junio,
In the commit f48000fcbe100, you've forced the caller to use
MAP_PRIVATE in the alternative mmap implementation dropping write-back
support. Could you kindly explain the rationale for this? David's SVN
exporter uses mmap with MAP_SHARED, and we figured that the merge
immediately breaks this functionality.
Noticed-by: Jonathan Nieder [off-list ref]
-----------------------------------------------------------------------------------------------------------
commit f48000fcbe1009c18f1cc46e56cde2cb632071fa
Author: Junio C Hamano [off-list ref]
Date: Sat Oct 8 15:54:36 2005 -0700
Yank writing-back support from gitfakemmap.
We do not write through our use of mmap(), so make sure callers pass
MAP_PRIVATE and remove support for writing changes back.
Signed-off-by: Junio C Hamano [off-list ref]
-----------------------------------------------------------------------------------------------------------
Thanks.
-- Ram
Ramkumar Ramachandra [off-list ref] wrote:
In the commit f48000fcbe100, you've forced the caller to use
MAP_PRIVATE in the alternative mmap implementation dropping write-back
support. Could you kindly explain the rationale for this? David's SVN
exporter uses mmap with MAP_SHARED, and we figured that the merge
immediately breaks this functionality.
Noticed-by: Jonathan Nieder [off-list ref]
-----------------------------------------------------------------------------------------------------------
commit f48000fcbe1009c18f1cc46e56cde2cb632071fa
Author: Junio C Hamano [off-list ref]
Date: Sat Oct 8 15:54:36 2005 -0700
Yank writing-back support from gitfakemmap.
We do not write through our use of mmap(), so make sure callers pass
MAP_PRIVATE and remove support for writing changes back.
Signed-off-by: Junio C Hamano [off-list ref]
-----------------------------------------------------------------------------------------------------------
It got dropped because we never really used it. In almost every
location we were only mapping a file for reading, but were writing
through normal IO write functions. The Windows emulation code at
that time was using malloc()+read() to emulate mmap(), and thus
any modifications made to the buffer would not be flushed back.
The one place where we were doing both was fast-import, but it was
playing loose with the mmap consistency rules. I think we have
fixed that code since then to ensure the data stays consistent on
all platforms.
I would strongly suggest finding another way to implement the SVN
exporter, without using MAP_SHARED.
--
Shawn.