Hi Grant,
On 02/17/2011 05:38 PM, Grant Erickson wrote:
On 1/31/11 1:47 AM, Daniel Wagner wrote:
On Fri, Jan 28, 2011 at 08:13:28PM -0800, Grant Erickson wrote:
As far as I can see, the stats mapping is not published or shared outside of
connman. If so, there's no reason to map it SHARED versus PRIVATE.
From the mmap man pages:
MAP_SHARED
Share this mapping. Updates to the mapping are visible to
other processes that map this file, and are carried through
to the underlying file. The file may not actually be
updated until msync(2) or munmap() is called.
MAP_PRIVATE
Create a private copy-on-write mapping. Updates to the
mapping are not visible to other processes mapping the same
file, and are not carried through to the underlying file.
It is unspecified whether changes made to the file after
the mmap() call are visible in the mapped region.
The reason for picking MAP_SHARED was to be sure the changes in buffer
really hits the file. I read that MAP_PRIVATE does not garantee this.
This is reason I was picking MAP_SHARED together with msync.
Daniel:
Thanks for taking the time to submit a comment for the code detailing the
motivation for selecting MAP_PRIVATE.
I have done some more research to determine why the MAP_SHARED fails on my
platform. From what I can see, this is a limitation of JFFS2. For it's mmap
method, it specifies:
% grep 'mmap' linux/fs/jffs2/*.c
linux/fs/jffs2/file.c: .mmap = generic_file_readonly_mmap,
Also, the "TODO" comment is instructive. From linux/fs/jffs2/TODO:
- support asynchronous operation -- add a per-fs 'reserved_space' count,
let each outstanding write reserve the _maximum_ amount of physical
space it could take. Let GC flush the outstanding writes because the
reservations will necessarily be pessimistic. With this we could even
do shared writable mmap, if we can have a fs hook for do_wp_page() to
make the reservation.
So, in short, for JFFS2 users in a top-of-tree kernel, connman statistics
will never work with a PROT_WRITE + MAP_SHARED mapping.
Thanks for tracking this down. In this case, it might make sense to add
some fallback. My idea is to use MAP_PRIVATE and write the whole
contents into a file after a certain period. The whole idea behind
MAP_SHARED is to make sure the data really hits the disk. But until now,
nobody with deep understanding of filesystem under Linux has done a
review. So the current approach might be bogus.
So if you are fine with having a fallback to MAP_PRIVATE + periodic
write a file, then we should add this feature.
Opinions?
cheers,
daniel
_______________________________________________
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman
