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 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


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,

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at