Latchesar Ionkov wrote:
On 12/6/06, Rob Ross <[EMAIL PROTECTED]> wrote:
David Chinner wrote:
>
> I also get the feeling that interfaces that already do this
> open-by-handle stuff haven't been explored either.
>
> Does anyone here know about the XFS libhandle API? This has been
> around for years and it does _exactly_ what these proposed syscalls
> are supposed to do (and more).
>
> See:
>
>
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=linux&db=man&fname=/usr/share/catman/man3/open_by_handle.3.html&srch=open_by_handle
>
> For the libhandle man page. Basically:
>
> openg == path_to_handle
> sutoc == open_by_handle
>
> And here for the userspace code:
>
> http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libhandle/
>
> Cheers,
>
> Dave.
Thanks for pointing these out Dave. These are indeed along the same
lines as the openg()/openfh() approach.
The open-by-handle makes a little more sense, because the "handle" is
not opened, it only points to a resolved file. As I mentioned before,
it doesn't make much sense to bundle in openg name resolution and file
open.
I don't think that I understand what you're saying here. The openg()
call does not perform file open (not that that is necessarily even a
first-class FS operation), it simply does the lookup.
When we were naming these calls, from a POSIX consistency perspective it
seemed best to keep the "open" nomenclature. That seems to be confusing
to some. Perhaps we should rename the function "lookup" or something
similar, to help keep from giving the wrong idea?
There is a difference between the openg() and path_to_handle() approach
in that we do permission checking at openg(), and that does have
implications on how the handle might be stored and such. That's being
discussed in a separate thread.
Thanks,
Rob
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
