From mboxrd@z Thu Jan  1 00:00:00 1970
From: Trond Myklebust <trond.myklebust@fys.uio.no>
Subject: Re: Use of nameidata in 2.6
Date: 25 Nov 2003 19:03:48 -0500
Sender: linux-fsdevel-owner@vger.kernel.org
Message-ID: <shsad6kvvvf.fsf@charged.uio.no>
References: <Pine.LNX.4.33.0311222037170.770-100000@wombat.indigo.net.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from pat.uio.no ([129.240.130.16]:64965 "EHLO pat.uio.no")
	by vger.kernel.org with ESMTP id S263733AbTKZADy (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Tue, 25 Nov 2003 19:03:54 -0500
To: Ian Kent <raven@themaw.net>
In-Reply-To: <Pine.LNX.4.33.0311222037170.770-100000@wombat.indigo.net.au>
List-Id: linux-fsdevel.vger.kernel.org

>>>>> " " == Ian Kent <raven@themaw.net> writes:

     > Any comments on the intended use and what it should contain
     > during differnt function calls would be welcome.

The nameidata+intents are there in order to provide hints to
filesystems like NFS and Lustre as to what is the ultimate purpose of
the call to lookup(). This allows the filesystem to perform
optimizations in certain cases.
It also will tell NFSv4 when to use the OPEN call rather than LOOKUP
on the wire (patches not yet merged).

I suggest you treat the nameidata as a read-only structure in this
case unless you are planning on bypassing the VFS and calling the
newly mounted filesystem directly (but why would you want to do that?).

Cheers,
  Trond