From: Carsten Otte <cotte@de.ibm.com>
To: "Jörn Engel" <joern@lazybastard.org>
Cc: carsteno@de.ibm.com, Christoph Hellwig <hch@infradead.org>,
Jared Hulbert <jaredeh@gmail.com>,
Nick Piggin <nickpiggin@yahoo.com.au>,
Andrew Morton <akpm@linux-foundation.org>,
richard.griffiths@windriver.com,
Richard Griffiths <res07ml0@verizon.net>,
Linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2.6.21] cramfs: add cramfs Linear XIP
Date: Sat, 09 Jun 2007 09:55:15 +0200 [thread overview]
Message-ID: <466A5CE3.7060307@de.ibm.com> (raw)
In-Reply-To: <20070608193606.GH20718@lazybastard.org>
Jörn Engel wrote:
> Whenever writes/erases to the device happen, the device driver would
> need to call a function like
>
> /**
> * unmap_page_range - remove all mapping to the given range of an address space
> * @mapping - the address space in question
> * @start_index - index of the first page in the range
> * @no_pages - number of pages to get unmapped
> *
> * Returns 0 on success or a negative errno value.
> */
> int unmap_page_range(struct address_space *mapping, loff_t start_index,
> loff_t no_pages);
>
> or implement something equivalent itself. Your filesystem callback
> looks like it would be just that, although I may be misreading you.
No. That's how the callback could look alike.
> Either that or using standard mtd->read() and mtd->write() calls. I see
> some advantages to mtd->write() in particular, as the device driver
> needs some notification to trigger unmap_page_range() before the actual
> write and chip state transitions happen. mtd->write() seems much easier
> than something like
>
> mtd->pre_write()
> get_xip_page()
> ...
> put_page()
> mtd->post_write()
>
> If get_xip_page() only has userland consumers all the locking can be
> kept inside device drivers.
Hmmh. We won't need mtd->pre_write(), because the file system's
get_xip_page aop will have to ask mtd for the address anyway similar
to the way ext2_get_xip_page does call bdev_ops->direct_access.
If that call would pass the information whether the future access is
read-only or read+write, the device driver could do its housekeeping.
I think we should also cover put_page() plus mtd->post_write() inside
a put_xip_page() address space operation provided by the fs. This way
calls are balanced, and we have stuff in a single place rather then
duplicating code. The fs could rely on a generic implementation in
filemap_xip in case it does'nt need to do its own magic here.
>> - the device driver can access page->count via a helper function
>> provided by mm. This way, it can identify which pages are in use.
>
> One of us is confused here. The driver would have to check page->count
> for a large range of pages, usually the whole chip. And it would have
> to tear down every single mapping before starting to write. Is that
> possible and desirable to do with page->count? Unsure.
That point was indeed confusing. Let my try again:
The only way, how an initial reference to a page can be retrieved, is
from the driver by using a bdev_ops->direct_access alike call. The
driver has to be able to check, if all references have been returned.
That would be done in three steps:
1. stop handing out new references
2. use the unmap_page_range callback to get references for page table
entries back
3. check if other (temporary) references are still handed out, wait
until they get returned.
Using a helper function to look into page->count is a possible
implementation for #3. And because the page->count cannot get changed
while noone has a reference, I don't see a race condition in looping
over all pages and checking page->count. This implementation has an
advantage, if the device driver wants to make sure that a small page
range is not accessed.
If the device driver needs to ensure that there are no references to
any page on the enitre flash media, it might use a global counter to
count the sum of references and save looping over all pages.
so long,
Carsten
next prev parent reply other threads:[~2007-06-09 7:55 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-22 22:09 [PATCH 2.6.21] cramfs: add cramfs Linear XIP Richard Griffiths
2007-05-22 22:49 ` Andrew Morton
2007-05-22 22:58 ` Richard Griffiths (wrs)
2007-05-23 7:51 ` Carsten Otte
2007-05-23 15:25 ` Richard Griffiths (wrs)
2007-05-24 6:46 ` Carsten Otte
2007-05-23 17:21 ` Jared Hulbert
2007-05-24 6:57 ` Carsten Otte
2007-05-29 5:10 ` Nick Piggin
2007-06-02 0:48 ` Jared Hulbert
2007-06-02 8:42 ` Nick Piggin
2007-06-04 13:32 ` Carsten Otte
2007-06-06 11:13 ` Jared Hulbert
2007-06-06 11:33 ` Christoph Hellwig
2007-06-06 15:17 ` Richard Griffiths
2007-06-06 15:50 ` Christoph Hellwig
2007-06-06 16:09 ` Jared Hulbert
2007-06-06 16:07 ` Jared Hulbert
2007-06-06 16:16 ` Christoph Hellwig
2007-06-06 18:26 ` Jared Hulbert
2007-06-07 19:37 ` Christoph Hellwig
2007-06-07 19:40 ` Christoph Hellwig
2007-06-07 20:27 ` Jared Hulbert
2007-06-08 7:39 ` Carsten Otte
2007-06-07 21:11 ` Jared Hulbert
2007-06-07 21:15 ` Christoph Hellwig
2007-06-07 22:59 ` Jared Hulbert
2007-06-08 13:19 ` Jörn Engel
2007-06-08 13:10 ` Jörn Engel
2007-06-06 16:15 ` Carsten Otte
2007-06-06 16:23 ` Christoph Hellwig
2007-06-06 18:40 ` Jared Hulbert
2007-06-06 22:59 ` Matt Mackall
2007-06-07 17:07 ` Carsten Otte
2007-06-07 19:38 ` Christoph Hellwig
2007-06-07 20:34 ` Jared Hulbert
2007-06-08 7:28 ` Christoph Hellwig
2007-06-08 16:02 ` Jared Hulbert
2007-06-08 7:17 ` Carsten Otte
2007-06-08 7:26 ` Christoph Hellwig
2007-06-08 7:50 ` Carsten Otte
2007-06-08 7:57 ` Christoph Hellwig
2007-06-08 7:59 ` Carsten Otte
2007-06-08 8:04 ` Christoph Hellwig
2007-06-08 16:05 ` Jared Hulbert
2007-06-08 16:09 ` Christoph Hellwig
2007-06-08 16:11 ` Jared Hulbert
2007-06-08 16:15 ` Christoph Hellwig
2007-06-08 17:51 ` Jörn Engel
2007-06-08 19:04 ` Carsten Otte
2007-06-08 19:06 ` Carsten Otte
2007-06-08 19:36 ` Jörn Engel
2007-06-09 7:55 ` Carsten Otte [this message]
2007-06-09 10:37 ` Jörn Engel
2007-06-08 23:02 ` Jared Hulbert
2007-06-07 21:19 ` Jared Hulbert
2007-06-06 12:05 ` Carsten Otte
2007-06-06 19:01 ` Jared Hulbert
2007-06-07 1:00 ` Justin Treon
2007-06-13 0:11 ` Jared Hulbert
2007-06-14 13:57 ` Carsten Otte
2007-06-14 16:53 ` Jared Hulbert
2007-06-15 9:22 ` Carsten Otte
2007-06-15 11:49 ` Heiko Carstens
2007-06-15 17:30 ` Jared Hulbert
2007-06-18 7:38 ` Carsten Otte
2007-06-15 13:53 ` Carsten Otte
2007-06-15 21:46 ` Jared Hulbert
2007-05-23 8:21 ` Alistair John Strachan
2007-05-24 20:22 ` Jared Hulbert
2007-05-24 20:52 ` Richard Griffiths
2007-05-24 21:21 ` Jared Hulbert
[not found] <337240.79058.qm@web59309.mail.re1.yahoo.com>
2007-06-09 8:09 ` Carsten Otte
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=466A5CE3.7060307@de.ibm.com \
--to=cotte@de.ibm.com \
--cc=Linux-kernel@vger.kernel.org \
--cc=akpm@linux-foundation.org \
--cc=carsteno@de.ibm.com \
--cc=hch@infradead.org \
--cc=jaredeh@gmail.com \
--cc=joern@lazybastard.org \
--cc=nickpiggin@yahoo.com.au \
--cc=res07ml0@verizon.net \
--cc=richard.griffiths@windriver.com \
/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;
as well as URLs for NNTP newsgroup(s).