On 2/17/11 12:13 PM, Daniel Wagner wrote: > On 02/17/2011 05:38 PM, Grant Erickson wrote: >> 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, >> >> 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?
Were I writing this anew, I think I'd have skipped the mmap altogether, maintained the statistics in memory and flushed things out to a file at the appropriate times. Working with what's there, I think I'd do away with MAP_SHARED, convert the mapping to MAP_PRIVATE and then call msync within the _stats_update path. All that is said, however, without a savvy perspective on how statistic are used within connman. Best, Grant _______________________________________________ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
