public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: viro@parcelfarce.linux.theplanet.co.uk
To: "Peter J. Braam" <braam@clusterfs.com>
Cc: torvalds@osdl.org, akpm@osdl.org, linux-kernel@vger.kernel.org,
	"'Phil Schwan'" <phil@clusterfs.com>
Subject: Re: [PATCH/RFC] Lustre VFS patch
Date: Mon, 24 May 2004 15:19:56 +0100	[thread overview]
Message-ID: <20040524141956.GC17014@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <20040524114009.96CE13100E2@moraine.clusterfs.com>

On Mon, May 24, 2004 at 07:39:50PM +0800, Peter J. Braam wrote:
> vfs-intent_api-vanilla-2.6.patch
>  
>   Introduce intents for other operations.  Add a file system hook to
>   release intent data.  Make a few "intent versions" of functions such
>   as "lookup_one_len_it" and "user_walk_it" available through headers.
>   Arrange that the open intent is visible in the open methods. Add a
>   few missing intent_init calls.

Where is the code using it?  Without examples of use there's no way to
tell whether it's bogus or not.

As it is, it looks like massive hook-adding exercise with no clear goal.
The same goes for ..._raw variants of the methods - yes, something in
that direction would make sense; however, splitting the codepath on the
top level looks like a bloody bad idea.  _IF_ we get hooks of that sort,
the right thing to do is to provide helpers and make normal filesystems
use them, passing current foo_mknod et.al. as callbacks.  And in any
case, that needs discussing - it's not obvious that "let's take over
entire work past lookup of parents" is the best choice here.

Again, without examples of users for that stuff you are asking for blind
change of API I'm really not comfortable with.

  parent reply	other threads:[~2004-05-24 14:20 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-24 11:39 [PATCH/RFC] Lustre VFS patch Peter J. Braam
2004-05-24 11:46 ` Jens Axboe
2004-05-25  1:48   ` braam
2004-05-25  6:47     ` Jens Axboe
2004-05-25  8:21       ` braam
2004-05-25  8:27         ` Jens Axboe
2004-05-25 10:52         ` Lars Marowsky-Bree
2004-05-25 11:45           ` braam
2004-05-25 13:35           ` Kevin Corry
2004-05-25 13:55             ` Jens Axboe
2004-05-24 12:00 ` hch
2004-05-24 12:01 ` hch
2004-05-24 12:03 ` hch
2004-05-24 15:33   ` Horst von Brand
2004-05-25 20:43     ` hch
2004-05-24 12:05 ` hch
2004-05-24 18:06   ` Trond Myklebust
2004-05-25  8:21     ` braam
2004-05-24 12:08 ` hch
2004-05-24 13:44   ` Arjan van de Ven
2004-05-24 13:53     ` viro
2004-05-28 16:56     ` braam
2004-05-28 17:00       ` Christoph Hellwig
2004-05-24 14:19 ` viro [this message]
2004-05-28 23:18 ` Maneesh Soni
2004-05-29 17:53 ` Anton Blanchard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040524141956.GC17014@parcelfarce.linux.theplanet.co.uk \
    --to=viro@parcelfarce.linux.theplanet.co.uk \
    --cc=akpm@osdl.org \
    --cc=braam@clusterfs.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=phil@clusterfs.com \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox