Re: openg and path_to_handle

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

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