Re: mmap question

David Woodhouse
2002-07-12T15:21:24Z

frederic.gobry@smartdata.ch said:
> I can work around this for my program (I just tested, performing a
> simple read just after the write restores what is seen in the mmapped
> memory), but I still would like to know if the MTD API could be
> augmented in order to handle read-only memory mapped areas (when
> available) in a cleaner way as what I currently do? I don't think
> this would imply lots of changes:

> - a flag indicating if the flash can be mmapped

> - the implementation of mmap (which probably would need a call
> similar to 'point' but with an explicit semantic toward
> mmapping.

Er, ditch the crap 'point' semantics and implement something sane for
mmapping, because that's about the only sane use of point() anyway.

> - possibly another flag to indicate that an area is currently
> mmapped, so that the erase / write operations set the flash in
> read mode once they have finished their duty

That's not sufficient. If you let the erase or write operations happen
while it's mapped, what prevents your app from reading from the flash
_during_ the erase/write operation? You need to either prevent the erases/
writes from happening while the flash is mapped (bad) or arrange for the
pages mapped to userspace to be marked invalid during the erase/write
operation, and faults on those pages have to wait until the flash is back
in read mode again.

We want some kind of mtd_remap() call which has its own struct vm_operations,
with a nopage() which sets a flag in the state of the underlying mtd_info,
and ensure that the page can be found again and made invalid before any
other MTD operations. With the rmap VM the latter is quite simple, without
it we'd need to keep track of all vmas ourselves.

This can be used from userspace via the mtdchar device's mmap() method, and
also from kernelspace so that things like jffs2 can just remap the flash
and read from it directly instead of having to make repeated mtd->read()
calls.

--
dwmw2