From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: Lookup intents Date: 11 Jul 2003 01:15:50 +0200 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: References: <1057884659.13932.11.camel@stevef95.austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from pat.uio.no ([129.240.130.16]:32990 "EHLO pat.uio.no") by vger.kernel.org with ESMTP id S269678AbTGJXBP (ORCPT ); Thu, 10 Jul 2003 19:01:15 -0400 To: Steve French In-Reply-To: <1057884659.13932.11.camel@stevef95.austin.ibm.com> List-Id: linux-fsdevel.vger.kernel.org >>>>> " " == Steve French writes: > Any ideas on the best way with the new lookup/create intents > that Trond added to 2.5 recently to save away a network file > handle? There is no file struct to put them in at the time of > create, so they could either be stored in a linked list off the > inode or a new field could be added to the intent to store fs > specific info for the operation (in this case the 32 bit > network file handle). I noticed that the older intents patch > had a much bigger intents structure in the nameidata struct. I was thinking of adding in a 'private data' field into the nameidata (together with an associated 'destroy' method). In the end I found I didn't need one for NFS. Adding it in is fairly trivial though... Do you need to pass that file handle on to the struct file? If so then the most obvious solution would be to pass the same nameidata down as an argument to the open() method. It's a lot of work to chase down all those open() calls littered around the kernel, but... Cheers, Trond