From: Ram Pai <linuxram@us.ibm.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Andrew Morton <akpm@osdl.org>,
viro@parcelfarce.linux.theplanet.co.uk,
Avantika Mathur <mathurav@us.ibm.com>,
mike@waychison.com, janak@us.ibm.com,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/7] shared subtree
Date: Fri, 29 Jul 2005 12:54:54 -0700 [thread overview]
Message-ID: <1122666893.4715.279.camel@localhost> (raw)
In-Reply-To: <E1Dy58Z-0002qL-00@dorka.pomaz.szeredi.hu>
On Thu, 2005-07-28 at 02:57, Miklos Szeredi wrote:
> > > This is an example, where having struct pnode just complicates things.
> > > If there was no struct pnode, this function would be just one line:
> > > setting the shared flag.
> > So your comment is mostly about getting rid of pnode and distributing
> > the pnode functionality in the vfsmount structure.
>
> Yes, sorry if I didn't make it clear.
>
> > I know you are thinking of just having the necessary propogation list in
> > the vfsmount structure itself. Yes true with that implementation the
> > complication is reduced in this part of the code, but really complicates
> > the propogation traversal routines.
>
> On the contrary, I think it will simplify the traversal routines.
>
> Here's an iterator function I coded up. Not tested at all (may not
> even compile):
Your suggested code has bugs. But I understand what you are aiming at.
Maybe you are right. I will try out a implementation using your idea.
Hmm.. lots of code change, and testing.
>
> struct vfsmount {
> /* ... */
>
> struct list_head mnt_share; /* circular list of shared mounts */
> struct list_head mnt_slave_list; /* list of slave mounts */
> struct list_head mnt_slave; /* slave list entry */
> struct vfsmount *master; /* slave is on master->mnt_slave_list */
> };
>
> static inline struct vfsmount *next_shared(struct vfsmount *p)
> {
> return list_entry(p->mnt_share.next, struct vfsmount, mnt_share);
> }
>
> static inline struct vfsmount *first_slave(struct vfsmount *p)
> {
> return list_entry(p->mnt_slave_list.next, struct vfsmount, mnt_slave);
> }
>
> static inline struct vfsmount *next_slave(struct vfsmount *p)
> {
> return list_entry(p->mnt_slave.next, struct vfsmount, mnt_slave);
> }
>
> static struct vfsmount *propagation_next(struct vfsmount *p,
> struct vfsmount *base)
> {
> /* first iterate over the slaves */
> if (!list_empty(&p->mnt_slave_list))
> return first_slave(p);
I think this code should be
if (!list_empty(&p->mnt_slave))
return next_slave(p);
Right? I think I get the idea.
RP
>
> while (1) {
> struct vfsmount *q;
>
> /* more vfsmounts belong to the pnode? */
> if (!list_empty(&p->mnt_share)) {
> p = next_shared(p);
> if (list_empty(&p->mnt_slave) && p != base)
> return p;
> }
> if (p == base)
> break;
>
> BUG_ON(list_empty(&p->mnt_slave));
>
> /* more slaves? */
> q = next_slave(p);
> if (p->master != q)
> return q;
>
> /* back at master */
> p = q;
> }
>
> return NULL;
> }
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2005-07-29 19:55 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-25 22:44 Ram Pai
2005-07-25 22:44 ` (unknown) Ram Pai
2005-07-25 22:44 ` (unknown) Ram Pai
2005-07-25 22:44 ` Ram Pai
2005-07-27 19:54 ` [PATCH 1/7] shared subtree Miklos Szeredi
2005-07-27 21:39 ` Ram Pai
2005-07-28 7:35 ` mount behavior question Ram Pai
2005-07-28 11:56 ` Miklos Szeredi
2005-07-28 15:02 ` Ram Pai
2005-07-28 15:58 ` Miklos Szeredi
2005-07-28 18:22 ` Ram Pai
2005-07-28 19:30 ` Miklos Szeredi
2005-07-28 20:09 ` Ram Pai
2005-07-28 20:44 ` Miklos Szeredi
2005-07-28 20:59 ` Ram Pai
2005-07-28 18:27 ` Bryan Henderson
2005-07-28 19:01 ` Miklos Szeredi
2005-07-28 20:35 ` Bryan Henderson
2005-07-28 20:42 ` Ram Pai
2005-07-28 22:27 ` Bryan Henderson
2005-07-28 22:59 ` Ram Pai
2005-07-28 20:53 ` Miklos Szeredi
2005-07-28 22:51 ` Bryan Henderson
2005-07-28 9:57 ` [PATCH 1/7] shared subtree Miklos Szeredi
2005-07-29 19:54 ` Ram Pai [this message]
2005-07-30 5:39 ` Miklos Szeredi
2005-07-31 0:45 ` Ram Pai
2005-07-31 7:52 ` Miklos Szeredi
2005-07-31 8:25 ` Miklos Szeredi
2005-07-25 22:44 ` Ram Pai
2005-07-25 22:44 ` (unknown) Ram Pai
2005-07-25 22:44 ` Ram Pai
2005-07-27 19:13 ` [PATCH 3/7] shared subtree Miklos Szeredi
2005-07-27 20:30 ` Ram Pai
2005-07-28 8:34 ` Miklos Szeredi
2005-07-25 22:44 ` (unknown) Ram Pai
2005-07-25 22:44 ` Ram Pai
2005-07-25 22:44 ` (unknown) Ram Pai
2005-07-25 22:44 ` Ram Pai
2005-07-25 22:44 ` (unknown) Ram Pai
2005-07-25 22:44 ` (unknown) Ram Pai
2005-07-25 22:44 ` Ram Pai
2005-07-25 22:44 ` Ram Pai
2005-07-25 22:44 ` (unknown) Ram Pai
2005-07-26 2:53 ` supposed to be shared subtree patches Ram Pai
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=1122666893.4715.279.camel@localhost \
--to=linuxram@us.ibm.com \
--cc=akpm@osdl.org \
--cc=janak@us.ibm.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathurav@us.ibm.com \
--cc=mike@waychison.com \
--cc=miklos@szeredi.hu \
--cc=viro@parcelfarce.linux.theplanet.co.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.