On Thu, 26 Apr 2007 23:43:32 +0530 "Amit K. Arora" <aarora@linux.vnet.ibm.com> wrote:
Please always format multiline comments like this:
/*
* ext4_can_extents_be_merged should have checked that either
* both extents are uninitialized, or both aren't. Thus we
* need to check only one of them here.
*/
This description is rather thin. What is the filesystem's actual behaviour
here? If the file is using extents then the implementation will do
<something>. If the file is using bitmaps then we will do <something else>.
But what? Here is where it should be described.
So we don't implement fallocate on bitmap-based files! Well that's huge
news. The changelog would be an appropriate place to communicate this,
along with reasons why, or a description of the plan to fix it.
Also, posix says nothing about fallocate() returning ENOTTY.
Now I'm mystified. Given that we're allocating an arbitrary amount of disk
space, and that this disk space will require an arbitrary amount of
metadata, how can we work out how much journal space we'll be needing
without at least looking at `len'?
Please always put spaces around "="
And around "+"
BUG_ON is vicious. Is it really justified here? Possibly a WARN_ON and
ext4_error() would be safer and more useful here.
Use buffer_new() here. A separate patch which fixes the three existing
instances of open-coded BH_foo usage would be appreciated.
Check for wrap though the sign bit and through zero please.
Fix comment layout.
Both the lhs and the rhs here are signed. Please review for possible
overflows through the sign bit and through zero. Perhaps a comment
explaining why it's correct would be appropriate.
The above two comments should be indented one additional tabstop.
Maybe a comment describing what this does? Probably it's obvious enough.
I think it could use the standard ALIGN macro.
Is blkbits sufficiently parenthesised here? Even if it is, adding the
parens would be better practice.
Please convert all newly-added multiline comments to the preferred layout.
argh. And feel free to give these args some useful names.
inlined C functions are preferred, and I think these could be implemented
that way.