From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Steve French (IBM LTC)" Subject: Re: Lookup intents Date: Thu, 10 Jul 2003 18:45:15 -0500 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <3F0DFA8B.9E6722AD@us.ibm.com> References: <1057884659.13932.11.camel@stevef95.austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from e2.ny.us.ibm.com ([32.97.182.102]:27028 "EHLO e2.ny.us.ibm.com") by vger.kernel.org with ESMTP id S269709AbTGJXfl (ORCPT ); Thu, 10 Jul 2003 19:35:41 -0400 To: Trond Myklebust List-Id: linux-fsdevel.vger.kernel.org A private data field in nameidata would work but would require adding a new parm to open (which as you note is painful). Probably a better solution would be for me to add a "pending create" linked list off the struct cifsInodeInfo for that inode. I would have to store network file id, pid and open flags - As long as the pid & open flags (saved at cifs_create) are found to match later by cifs_open I can put the netfid from the pending create entry in my file struct (which will make my cifs_open code a lot faster since another network open will not have to be issued to get the network fid). This makes a couple of assumptions though - 1) that the Trond Myklebust wrote: > >>>>> " " == 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