David Chinner wrote:
On Tue, Dec 05, 2006 at 05:47:16PM +0100, Latchesar Ionkov wrote:
On 12/5/06, Rob Ross <rross@xxxxxxxxxxx> wrote:
Hi,
I agree that it is not feasible to add new system calls every time
somebody has a problem, and we don't take adding system calls lightly.
However, in this case we're talking about an entire *community* of
people (high-end computing), not just one or two people. Of course it
may still be the case that that community is not important enough to
justify the addition of system calls; that's obviously not my call to make!
I have the feeling that openg stuff is rushed without looking into all
solutions, that don't require changes to the current interface.
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.
One difference is that they appear to perform permission checking on the
open_by_handle(), which means that the entire path needs to be encoded
in the handle, and makes it difficult to eliminate the path traversal
overhead on N open_by_handle() operations.
Regards,
Rob
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
