Re: [PATCH 2.6.21] cramfs: add cramfs Linear XIP
From: Carsten Otte
Date: Sat Jun 09 2007 - 03:55:29 EST
JÃrn Engel wrote:
Whenever writes/erases to the device happen, the device driver wouldNo. That's how the callback could look alike.
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,
or implement something equivalent itself. Your filesystem callback
looks like it would be just that, although I may be misreading you.
Either that or using standard mtd->read() and mtd->write() calls. I seeHmmh. 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.
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
If get_xip_page() only has userland consumers all the locking can be
kept inside device drivers.
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.
That point was indeed confusing. Let my try again:
- 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.
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
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/