On Fri, May 10, 2002 at 03:53:17PM -0400, Alexander Viro wrote:
> On Fri, 10 May 2002, Jan Harkes wrote:
> > + if (set)
> > + err = set(inode, data);
> > + if (!err) {
> > + inodes_stat.nr_inodes++;
> > + list_add(&inode->i_list, &inode_in_use);
> > + list_add(&inode->i_hash, head);
> > + inode->i_state = I_LOCK;
> > + }
> > spin_unlock(&inode_lock);
> >
> > + if (err) {
> > + destroy_inode(inode);
> > + return NULL;
> > + }
>
> Please, take that code out of the path - will be cleaner that way.
Ok, a later patch already makes 'set' required, and I was only using the
failure path in Coda. I'll change this so that set never fails.
On Fri, May 10, 2002 at 04:00:54PM -0400, Alexander Viro wrote:
> On Fri, 10 May 2002, Jan Harkes wrote:
> > + *inode = iget_locked(sb, CTL_INO);
> > + if ( *inode && ((*inode)->i_state & I_NEW) ) {
> > (*inode)->i_op = &coda_ioctl_inode_operations;
> > (*inode)->i_fop = &coda_ioctl_operations;
> > (*inode)->i_mode = 0444;
> > + unlock_new_inode(*inode);
>
> Ehhh.... Do we need this guy hashed, in the first place?
Actually we really don't want this guy hashed, I'll use new_inode(sb)
for this one.
> > destroy_inode: reiserfs_destroy_inode,
> > read_inode: reiserfs_read_inode,
> > - read_inode2: reiserfs_read_inode2,
>
> Why do we keep ->read_inode() here?
Just in case someone outside of reiser calls 'iget' on a reiserfs inode.
I guess it's not really necessary to have it around.
> > Here we simply add an argument to insert_inode_hash. If at some
> > point a FS specific getattr method is implemented it will be possible to
> > completely remove all uses of i_ino in the VFS.
>
> How about
>
> static inline void insert_inode_hash(struct inode *inode)
> {
> __insert_inode_hash(inode, inode->i_hash);
Ok, will do that.
Should I create one patch that goes in relative to iget_locked-6, or
resubmit updated patches for each step? I guess an additional patch is
the easiest. Or a -6a that replaces the existing -6.
Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 14 2002 - 12:00:14 EST