Re: Lookup intents

["Steve French (IBM LTC)" <smfltc@us.ibm.com>]

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 <smfltc@us.ibm.com> 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