I was planning on doing #3, but since you guys need to access .., my plan is to have 'a/b' refer to $cwd/a/b while /a/b is the absolute path, and allow read and eventfd but no write to any parent dirs. Quoting Tim Hockin (thockin@xxxxxxxxxx): > I see three models: > > 1) Don't "virtualize" the cgroup path. This is what lmctfy does, > though we have discussed changing to: > > 2) Virtualize to an "administrative root" - I get to tell you where > your root is, and you can't see anythign higher than that. > > 3) Virtualize to CWD root - you can never go up, just down. > > > #1 seems easy, but exposes a lot. #3 is restrictive and fairly easy - > could we live with that? #2 seems ideal, but it's not clear to me how > to actually implement it. > > On Tue, Nov 26, 2013 at 1:31 PM, Victor Marmol <vmarmol@xxxxxxxxxx> wrote: > > I think most of our usecases have only wanted to know about the parent, but > > I can see people wanting to go further. Would it be much different to > > support both? I feel like it'll be simpler to support all if we go that > > route. > > > > > > On Tue, Nov 26, 2013 at 1:28 PM, Serge E. Hallyn <serge@xxxxxxxxxx> wrote: > >> > >> Quoting Tim Hockin (thockin@xxxxxxxxxx): > >> > lmctfy literally supports ".." as a container name :) > >> > >> So is ../.. ever used, or does noone every do anything beyond ..? > > > > -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
