From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Ross Subject: Re: openg and path_to_handle Date: Thu, 14 Dec 2006 15:00:41 -0600 Message-ID: <4581BB79.4070201@mcs.anl.gov> References: <6.2.3.4.2.20061127213243.04f786c0@cic-mail.lanl.gov> <20061129090450.GA16296@infradead.org> <20061129122313.GG14315@parisc-linux.org> <20061129123913.GA15994@infradead.org> <4570ACD1.7060800@mcs.anl.gov> <4574BF52.6090600@mcs.anl.gov> <20061206094805.GB33919298@melbourne.sgi.com> <4576E783.7020402@mcs.anl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Chinner , Christoph Hellwig , Matthew Wilcox , Gary Grider , linux-fsdevel@vger.kernel.org Return-path: Received: from mailgw.mcs.anl.gov ([140.221.9.4]:34993 "EHLO mailgw.mcs.anl.gov" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751704AbWLNV1W (ORCPT ); Thu, 14 Dec 2006 16:27:22 -0500 To: Latchesar Ionkov In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Latchesar Ionkov wrote: > On 12/6/06, Rob Ross 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