lkml.org 
[lkml]   [2002]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] iget_locked [1/6]
From
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/

\
 
 \ /
  Last update: 2005-03-22 13:22    [W:0.163 / U:0.672 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site