Re: openg and path_to_handle

["Latchesar Ionkov" <lionkov@lanl.gov>]

On 12/6/06, Rob Ross <rross@mcs.anl.gov> wrote:
> 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.

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.

Still I am not convinced that we need two ways of "finding" files.

Thanks,
    Lucho