openg and path_to_handle

[Rob Ross <rross@mcs.anl.gov>]

David Chinner wrote:
> On Tue, Dec 05, 2006 at 05:47:16PM +0100, Latchesar Ionkov wrote:
>> On 12/5/06, Rob Ross <rross@mcs.anl.gov> 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