public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
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

      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