From: Valerie Aurora <vaurora@redhat.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: viro@zeniv.linux.org.uk, hch@infradead.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
jblunck@suse.de
Subject: Re: [PATCH 1/6] union-mount: Introduce union_mount structure and basic operations
Date: Tue, 9 Mar 2010 14:49:16 -0500 [thread overview]
Message-ID: <20100309194916.GB10605@shell> (raw)
In-Reply-To: <E1NnDr7-00067s-NJ@pomaz-ex.szeredi.hu>
On Thu, Mar 04, 2010 at 05:24:57PM +0100, Miklos Szeredi wrote:
> On Wed, 3 Mar 2010, Valerie Aurora wrote:
> > On Wed, Mar 03, 2010 at 06:33:20PM +0100, Miklos Szeredi wrote:
> > > On Tue, 2 Mar 2010, Valerie Aurora wrote:
> > > > +struct union_mount *union_alloc(struct dentry *this, struct vfsmount *this_mnt,
> > > > + struct dentry *next, struct vfsmount *next_mnt)
> > >
> > >
> > > Why doesn't union_alloc, append_to_union, union_lookup,
> > > union_down_one, etc use "struct path *" arg instead of separate
> > > vfsmount and dentry pointers?
> >
> > I'd prefer that too, but it isn't a clear win. For append_to_union(),
> > the reason is that we call it when a file system is mounted, using mnt
> > and mnt->mnt_root as the first args:
> >
> > int attach_mnt_union(struct vfsmount *mnt, struct vfsmount *dest_mnt,
> > struct dentry *dest_dentry)
> > {
> > if (!IS_MNT_UNION(mnt))
> > return 0;
> >
> > return append_to_union(mnt, mnt->mnt_root, dest_mnt, dest_dentry);
> > }
> >
> > Same thing happens in detach_mnt_union() with union_lookup(). That
> > trickles down into the rest. I suppose I could create a temporary
> > path variable for those two functions and then we'd be paths
> > everywhere else. What do you think?
>
> If it's just two temporary vars, then IMO it's a win. It's much
> easier to read the functions if it has half the arguments.
I agree, I'll make that change.
> > > > + um = kmem_cache_alloc(union_cache, GFP_ATOMIC);
> > > > + if (!um)
> > > > + return NULL;
> > > > +
> > > > + atomic_set(&um->u_count, 1);
> > >
> > > Why is u_count not a "struct kref"?
> >
> > We stole this from the inode cache code, so for the same reason inodes
> > have i_count as atomic_t instead of a kref (whatever that is). :)
>
> i_count does some tricky things. If you just want plain an simple
> refcounting then you should be using krefs.
Could you elaborate more? I don't see what's so tricky about an
atomic counter.
Thanks,
-VAL
next prev parent reply other threads:[~2010-03-09 19:49 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-02 22:11 [RFC PATCH 0/6] Union mount core rewrite v1 Valerie Aurora
2010-03-02 22:11 ` [PATCH 1/6] union-mount: Introduce union_mount structure and basic operations Valerie Aurora
2010-03-02 22:11 ` [PATCH 2/6] union-mount: Drive the union cache via dcache Valerie Aurora
2010-03-02 22:11 ` [PATCH 3/6] union-mount: Implement union lookup Valerie Aurora
2010-03-02 22:11 ` [PATCH 4/6] union-mount: Support for mounting union mount file systems Valerie Aurora
2010-03-02 22:11 ` [PATCH 5/6] union-mount: Call do_whiteout() on unlink and rmdir in unions Valerie Aurora
2010-03-02 22:11 ` [PATCH 6/6] union-mount: Copy up directory entries on first readdir() Valerie Aurora
2010-03-03 21:53 ` Multiple read-only layers in union mounts (was Re: [PATCH 6/6] union-mount: Copy up directory entries on first readdir()) Valerie Aurora
2010-03-03 17:35 ` [PATCH 2/6] union-mount: Drive the union cache via dcache Miklos Szeredi
2010-03-03 21:49 ` Valerie Aurora
2010-03-04 16:34 ` Miklos Szeredi
2010-03-09 19:22 ` Valerie Aurora
2010-03-03 17:33 ` [PATCH 1/6] union-mount: Introduce union_mount structure and basic operations Miklos Szeredi
2010-03-03 20:45 ` Valerie Aurora
2010-03-04 16:24 ` Miklos Szeredi
2010-03-09 19:49 ` Valerie Aurora [this message]
2010-03-03 17:28 ` [RFC PATCH 0/6] Union mount core rewrite v1 Miklos Szeredi
2010-03-03 20:31 ` Valerie Aurora
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=20100309194916.GB10605@shell \
--to=vaurora@redhat.com \
--cc=hch@infradead.org \
--cc=jblunck@suse.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=viro@zeniv.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.