From mboxrd@z Thu Jan  1 00:00:00 1970
From: Chris Mason <mason@suse.com>
Subject: Re: [PATCH] icreate-7
Date: 02 May 2002 10:22:36 -0400
Sender: linux-fsdevel-owner@vger.kernel.org
Message-ID: <1020349356.1510.36.camel@tiny>
References: <20020501225904.GA16058@mentor.odyssey.cs.cmu.edu>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Cc: linux-fsdevel@vger.kernel.org
Return-path: <linux-fsdevel-owner@vger.kernel.org>
To: Jan Harkes <jaharkes@cs.cmu.edu>
In-Reply-To: <20020501225904.GA16058@mentor.odyssey.cs.cmu.edu>
List-Id: linux-fsdevel.vger.kernel.org

On Wed, 2002-05-01 at 18:59, Jan Harkes wrote:
> Another day another update,
> 
> Fixed the documentation error, thanks Kai, and tried to follow Al's
> advice by not including ino separately, but using *(ino_t *)data for
> the inode hash calculation. Don't really like it myself, but who am
> I to argue and it might end up making life a bit simpler for NFS and
> Intermezzo because we end up having only a single identifier for an
> object. OTOH, if everything switches to icreate the filesystems will
> have to provide a lookup mechanism through export_ops.

Hmmm, a void * implies the FS can put whatever garbage it wants there,
I'd rather see the FS cast its own icreate_args struct into one that
specifies what the FS is expected to include.

Something like this:

struct icreate_args {
	ino_t ino;
}

and

struct foofs_create_args {
	ino_t ino; 
        < other foofs stuff >
}

struct inode *icreate(struct super_block *sb, unsigned long ino,
                      int (*test)(struct inode *, void *),
                      int (*set)(struct inode *, void *),
                      struct icreate_args *);

-chris