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:54 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-25 22:44 (unknown) Ram Pai
2005-07-25 22:44 ` (unknown) Ram Pai
2005-07-25 22:44 ` (unknown) Ram Pai
2005-07-25 22:44 ` (unknown) Ram Pai
2005-07-25 22:44 ` (unknown) Ram Pai
2005-07-25 22:44 ` (unknown) Ram Pai
2005-07-25 22:44 ` (unknown) Ram Pai
2005-07-25 22:44 ` (unknown) Ram Pai
2005-07-26 2:53 ` supposed to be shared subtree patches Ram Pai
[not found] ` <20050725225908.031752000@localhost>
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
[not found] ` <20050725225907.007405000@localhost>
2005-07-27 19:54 ` [PATCH 1/7] " 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
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).