> On Tue, 21 Dec 1999, Trond Myklebust wrote:
>> This fix has not yet been merged in to the stock kernel, ('cos
>> Linus wanted the patch cleaned up before accepting it) so I
>> can't really blame other people for having messed
>> up. Nevertheless in order to avoid the clumsines of some
>> unwieldy extra (void* opaque)-like arguments to the
>> readpage/writepage functions, I'd really appreciate if we could
>> revert to passing the filp instead of the dentry to
>> readpage/writepage.
> Oh, please. We can turn the first argument into opaque thing -
> normal filesystems shouldn't (and will not) give a toss for it
> anyway (yes, patches are also pending, more or less for the
> same reason).
> However, the idea of holding that in file is _very_ messy -
> just as holding fhandle in dentry.
> Trond, could you look at the (preliminary, but looks like it
> works) patch on ftp.math.psu.edu/pub/viro/as-patch-26b.gz? It
> should give an idea of what I'm trying to do. IMO fhandle of
> regular file should be available in struct address_space
> (you'll need a new field in the union there). Ditto for the
> creds needed to access the thing. I can agree with
-> commit_write() having an opaque parameter, though - we'll need
it when
> we will go for soft-updates anyway. But using struct file for
> that?
No. That doesn't make sense for network-based filesystems. You don't
want a single RPC credential to be shared among all the users, since
that requires the client to choose one that is 'the correct user auth
for reading this file'. If you have some sort of uid/gid mapping, ACLs
or --worse yet-- des/kerberos style authentication, then such a
selection is not obvious. (Imagine if the kerberos token suddenly
expires)
As for holding the file handle in the address_space structure, then
this becomes equivalent to placing it in the inode structure if I
correctly read the scheme you're proposing. This has been discussed,
and the concensus was that it won't work well against Linux servers,
since they encode at least some path info in the file handle. You
don't want your entire inode coming down with a bad case of '-ESTALE'
because somebody on the server deleted the hard link associated to the
fhandle you happen to have selected.
Under Linux, the fhandle is more properly associated to the dentry
rather than the inode.
Cheers,
Trond
-
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/