lkml.org 
[lkml]   [2006]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 001 of 4] Update some VFS documentation.
From
Date
Did a quick scan - some minor corrections in text.

On Mon, 2006-03-13 at 10:53 +1100, NeilBrown wrote:
<snip>

> destroy_inode: this method is called by destroy_inode() to release
> - resources allocated for struct inode.
> + resources allocated for struct inode. It is only required of

"of" -> "if"

> + ->alloc_inode was defined and simply does a deallocate.

"simply does a deallocate" -> "undoes anything done by ->alloc_inode"

<snip>

> +The first can be used independantly to the others. The vm can try to

"independantly" -> "independently"

<snip>

> - writepage: called by the VM write a dirty page to backing store.
> + writepage: called by the VM to write a dirty page to backing store.
> + This may happen for data integrity reason (i.e. 'sync'), or
> + to free up memory (flush). The difference can be seen in
> + wbc->sync_mode.
> + The PG_Dirty flag has been cleared and PageLocked is true.
> + writepage should start writeout, should set PG_Writeback,
> + and should make sure the page is Unlocked, either synchronously

"Unlocked" -> "unlocked"

<snip>

>
> sync_page: called by the VM to notify the backing store to perform all
> queued I/O operations for a page. I/O operations for other pages
> - associated with this address_space object may also be performed.
> + associated with this address_space object may also be
> + performed.

Why did this line get split?

<snip>

> set_page_dirty: called by the VM to set a page dirty.
> + This is particularly needed if an address space attaches
> + private data to a page, and that data needs to be updated when
> + a page is dirtied. This is called, for example, when a memory
> + mapped page gets modified.
> + If defined, it should set the PageDirty flag, and the
> + PAGECACHE_TAG_DIRTY tag in the radix tree.

Indentation is off by one.

> readpages: called by the VM to read pages associated with the address_space
> - object.
> + object. This is essentailly just a vector version of

"essentailly" -> "essentially"

> + readpage. Instead of just one page, several pages are
> + requested.
> + readpages is only used for readahead, so read errors are
> + ignored. If anything goes wrong, feel free to give up.
>
> prepare_write: called by the generic write path in VM to set up a write
> - request for a page.
> -
> - commit_write: called by the generic write path in VM to write page to
> - its backing store.
> + request for a page. This indicates to the address space that
> + the given range of bytes are about to be written. The
> + address_space should check that the write will be able to
> + complete, by allocating space if necessary and doing any other
> + internal house keeping. If the write will update parts some
> + some basic-blocks on storage, then those blocks should be
> + pre-read (if they haven't been read already) so that the
> + update will not leave half-blocks that need to be written out.

"some" appears twice in a row in this last sentence. Anyway, it is
confusing. I would re-word it to something like:
"If the write will update partial storage blocks, those blocks should be
read at this point (if they haven't been already) so that the updated
blocks can be properly written out."

<snip>


Avishay Traeger
http://www.fsl.cs.sunysb.edu/~avishay/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-03-13 01:26    [W:0.325 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site