I think this is to a lesser degree true in 2.1 than it was in 2.0.
For example, if you use generic_file_mmap, you absolutely have to
have a readpage and writepage operation on the inode. It will not
decide to use generic_readpage on its own.
For other operations, this is still true. You usually don't need to
implement an llseek operation, because if you don't, because llseek
will do the right thing (i.e. call the static function default_llseek).
> Note that this means that, given a bmap() function, a file
> system doesn't have to implement read()! (generic_file_read
> is available and will do all sorts of hairy read-ahead for you.)
You have to put that into your operations vector, though. If you
have a NULL function for read, sys_read will return EBADF.
> ?> Should zeromap_page_range be used on page-sized holes in files?
> ?> I guess generic_readpage() is a little too late, but it could
> ?> have a special return value that could be noticed at the 7 places
> ?> (all in mm/filemap.c) where it's called.
If a file system wants to use zeromap_page_range, it needs to implement
its own vm area operations. Please note that this is usually not what
you want: On a writable mapping, modified pages in a zeromap range
become anonymously mapped, and will not be written back to a file
(except, maybe, to swap). Basically, you have to leave the vm mapping
intact and associated with your inode.
> ?> Is it worth writing a memset_aligned(), or even a zerofill_aligned(),
> ?> which could avoid a lot of tedious checking on, e.g. the Alpha?
I guess the memset inlining finds out rather quickly that the call
is page aligned. Clearing the page will then take significantly more
time.
Regards,
Martin