From: David Woodhouse <dwmw2@infradead.org>
To: Frederic Gobry <frederic.gobry@smartdata.ch>
Cc: linux-mtd@lists.infradead.org
Subject: Re: mmap question
Date: Fri, 12 Jul 2002 16:21:19 +0100 [thread overview]
Message-ID: <10934.1026487279@redhat.com> (raw)
In-Reply-To: <20020712075715.GA9952@rhin>
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
prev parent reply other threads:[~2002-07-12 15:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-04 13:22 mmap question Frederic Gobry
2002-07-01 13:14 ` Frederic Gobry
2002-07-11 16:19 ` Frederic Gobry
2002-07-11 19:15 ` Jörn Engel
2002-07-12 7:57 ` Frederic Gobry
2002-07-12 15:08 ` Jörn Engel
2002-07-15 7:41 ` Frederic Gobry
2002-07-12 15:21 ` David Woodhouse [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=10934.1026487279@redhat.com \
--to=dwmw2@infradead.org \
--cc=frederic.gobry@smartdata.ch \
--cc=linux-mtd@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox