On Thu, 11 May 2000, Deven T. Corzine wrote:
>
> If it doesn't seem inherently obvious that the parameter could be NULL (and
> I'm not disputing that),
Note that as far as the VFS proper is concerned, at this point in time the
parameter really never _is_ NULL. For all the native downcalls the VFS
layerwill actually supply a "struct file" to the filesystem.
The only case for a NULL "file" pointer is actually brought on by the
filesystem itself: the symlink helper functions will create a "readpage()"
(or prepare_write/commit_write) call with a NULL file pointer.
But I want to point out that this does not happen on the behalf of the
real VFS layer. It's really only just a few helper functions (that a
filesystem doesn't _have_ to use at all) that "misuse" the read/write
callbacks in situations where there is no "struct file" available.
So a filesystem can simply choose to not use the
"page_symlink_inode_operations" at all. There are filesystems that do this
(autofs comes to mind, as does /proc), because the "symlink data in the
page cache" approach simply doesn't make sense for them.
So we should definitely _not_ document that "file can be NULL". In fact,
under normal circumstances it really cannot. Instead, the documentation
should say that "if you're using the page_symlink_inode_operations helper
functions, the address space operations associated with the symlink have
to be able to handle a NULL file pointer".
Note that the readpage" case for symlinks can be an entirely different
"readpage" thanfor regular files. In fact, it usually is, except for
bog-standard block-based filesystems.
Also note that the regular "symlink in page cache" helper routines might
notbe appropriate even for "normal" filesystems. Somebody mentioned the
"symlink depends on user" issue with some NFS servers. That could be
handled by using the page cache and indexing it on the "uid", instead of
always using index 0. But it would mean that the page cache helper
functions couldn't be used directly for such a symlink setup.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:18 EST