From: Tim Hockin <thockin-Rl2oBbRerpQdnm+yROfE0A@public.gmane.org> To: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> Cc: jpoimboe <jpoimboe-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Containers <containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>, Kay Sievers <kay.sievers-tD+1rO4QERM@public.gmane.org>, lpoetter <lpoetter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, workman-devel <workman-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, dawnchen-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, "dhaval.giani" <dhaval.giani-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Paul Turner <pjt-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> Subject: Re: cgroup: status-quo and userland efforts Date: Fri, 28 Jun 2013 11:44:23 -0700 [thread overview] Message-ID: <CAAAKZwtOnpATCmRcOpsXaLZ8sQDs2Z=iZb8FrqG=bajNAOBnRg@mail.gmail.com> (raw) In-Reply-To: <20130627210445.GA22860-9pTldWuhBndy/B6EtB590w@public.gmane.org> On Thu, Jun 27, 2013 at 2:04 PM, Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote: > Hello, > > On Thu, Jun 27, 2013 at 01:46:18PM -0700, Tim Hockin wrote: >> So what you're saying is that you don't care that this new thing is >> less capable than the old thing, despite it having real impact. > > Sort of. I'm saying, at least up until now, moving away from > orthogonal hierarchy support seems to be the right trade-off. It all > depends on how you measure how much things are simplified and how > heavy the "real impacts" are. It's not like these things can be > determined white and black. Given the current situation, I think it's > the right call. I totally understand where you're coming from - trying to get back to a stable feature set. But it sucks to be on the losing end of that battle - you're cutting things that REALLY matter to us, and without a really viable alternative. So we'll keep fighting. >> If controller C is enabled at level X but disabled at level X/Y, does >> that mean that X/Y uses the limits set in X? How about X/Y/Z? > > Y and Y/Z wouldn't make any difference. Tasks belonging to them would > behave as if they belong to X as far as C is concerened. OK, that *sounds* sane. It doesn't solve all our problems, but it alleviates some of them. >> So take away some of the flexibility that has minimal impact and >> maximum return. Splitting threads across cgroups - we use it, but we >> could get off that. Force all-or-nothing joining of an aggregate > > Please do so. Splitting threads is sort of important for some cgroups, like CPU. I wonder if pjt is paying attention to this thread. >> construct (a container vs N cgroups). >> >> But perform surgery with a scalpel, not a hatchet. > > As anything else, it's drawing a line in a continuous spectrum of > grey. Right now, given that maintaining multiple orthogonal > hierarchies while introducing a proper concept of resource container > involves addition of completely new constructs and complexity, I don't > think that's a good option. If there are problems which can't be > resolved / worked around in a reasonable manner, please bring them up > along with their contexts. Let's examine them and see whether there > are other ways to accomodate them. You're arguing that the abstraction you want is that of a "container" but that it's easier to remove options than to actually build a better API. I think this is wrong. Take the opportunity to define the RIGHT interface that you WANT - a container. Implement it in terms of cgroups (and maybe other stuff!). Make that API so compelling that people want to use it, and your war of attrition on direct cgroup madness will be won, but with net progress rather than regress.
WARNING: multiple messages have this Message-ID (diff)
From: Tim Hockin <thockin@hockin.org> To: Tejun Heo <tj@kernel.org> Cc: Li Zefan <lizefan@huawei.com>, Containers <containers@lists.linux-foundation.org>, Cgroups <cgroups@vger.kernel.org>, bsingharora <bsingharora@gmail.com>, "dhaval.giani" <dhaval.giani@gmail.com>, Kay Sievers <kay.sievers@vrfy.org>, jpoimboe <jpoimboe@redhat.com>, "Daniel P. Berrange" <berrange@redhat.com>, lpoetter <lpoetter@redhat.com>, workman-devel <workman-devel@redhat.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, dawnchen@google.com, Paul Turner <pjt@google.com> Subject: Re: cgroup: status-quo and userland efforts Date: Fri, 28 Jun 2013 11:44:23 -0700 [thread overview] Message-ID: <CAAAKZwtOnpATCmRcOpsXaLZ8sQDs2Z=iZb8FrqG=bajNAOBnRg@mail.gmail.com> (raw) In-Reply-To: <20130627210445.GA22860@mtj.dyndns.org> On Thu, Jun 27, 2013 at 2:04 PM, Tejun Heo <tj@kernel.org> wrote: > Hello, > > On Thu, Jun 27, 2013 at 01:46:18PM -0700, Tim Hockin wrote: >> So what you're saying is that you don't care that this new thing is >> less capable than the old thing, despite it having real impact. > > Sort of. I'm saying, at least up until now, moving away from > orthogonal hierarchy support seems to be the right trade-off. It all > depends on how you measure how much things are simplified and how > heavy the "real impacts" are. It's not like these things can be > determined white and black. Given the current situation, I think it's > the right call. I totally understand where you're coming from - trying to get back to a stable feature set. But it sucks to be on the losing end of that battle - you're cutting things that REALLY matter to us, and without a really viable alternative. So we'll keep fighting. >> If controller C is enabled at level X but disabled at level X/Y, does >> that mean that X/Y uses the limits set in X? How about X/Y/Z? > > Y and Y/Z wouldn't make any difference. Tasks belonging to them would > behave as if they belong to X as far as C is concerened. OK, that *sounds* sane. It doesn't solve all our problems, but it alleviates some of them. >> So take away some of the flexibility that has minimal impact and >> maximum return. Splitting threads across cgroups - we use it, but we >> could get off that. Force all-or-nothing joining of an aggregate > > Please do so. Splitting threads is sort of important for some cgroups, like CPU. I wonder if pjt is paying attention to this thread. >> construct (a container vs N cgroups). >> >> But perform surgery with a scalpel, not a hatchet. > > As anything else, it's drawing a line in a continuous spectrum of > grey. Right now, given that maintaining multiple orthogonal > hierarchies while introducing a proper concept of resource container > involves addition of completely new constructs and complexity, I don't > think that's a good option. If there are problems which can't be > resolved / worked around in a reasonable manner, please bring them up > along with their contexts. Let's examine them and see whether there > are other ways to accomodate them. You're arguing that the abstraction you want is that of a "container" but that it's easier to remove options than to actually build a better API. I think this is wrong. Take the opportunity to define the RIGHT interface that you WANT - a container. Implement it in terms of cgroups (and maybe other stuff!). Make that API so compelling that people want to use it, and your war of attrition on direct cgroup madness will be won, but with net progress rather than regress.
next prev parent reply other threads:[~2013-06-28 18:44 UTC|newest] Thread overview: 205+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-04-06 1:21 cgroup: status-quo and userland efforts Tejun Heo 2013-04-06 1:21 ` Tejun Heo [not found] ` <20130406012159.GA17159-9pTldWuhBndy/B6EtB590w@public.gmane.org> 2013-04-08 13:46 ` Glauber Costa 2013-04-08 13:46 ` Glauber Costa 2013-04-08 23:32 ` Lennart Poettering 2013-04-08 23:32 ` Lennart Poettering 2013-04-09 7:37 ` Glauber Costa 2013-04-09 7:37 ` Glauber Costa [not found] ` <51635371.7070104-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2013-04-09 7:37 ` Glauber Costa 2013-04-09 19:11 ` Tejun Heo 2013-04-09 19:11 ` Tejun Heo [not found] ` <5162CA21.4060108-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> 2013-04-08 18:00 ` [Workman-devel] " Vivek Goyal 2013-04-08 18:00 ` Vivek Goyal 2013-04-08 18:26 ` Tejun Heo 2013-04-08 18:26 ` Tejun Heo 2013-04-08 23:32 ` Lennart Poettering 2013-04-08 17:59 ` [Workman-devel] " Vivek Goyal 2013-04-08 17:59 ` Vivek Goyal [not found] ` <20130408175925.GE28292-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2013-04-08 18:16 ` Tejun Heo 2013-04-08 18:16 ` Tejun Heo [not found] ` <20130408181607.GI3021-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org> 2013-04-08 18:49 ` Tejun Heo 2013-04-08 18:49 ` Tejun Heo 2013-04-08 19:11 ` Vivek Goyal 2013-04-08 19:11 ` Vivek Goyal [not found] ` <20130408191105.GG28292-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2013-04-08 19:20 ` Tejun Heo 2013-04-08 19:20 ` Tejun Heo [not found] ` <20130408192024.GL3021-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org> 2013-04-08 19:46 ` Vivek Goyal 2013-04-08 19:46 ` Vivek Goyal 2013-04-08 20:02 ` Tejun Heo 2013-04-08 20:02 ` Tejun Heo [not found] ` <20130408194630.GH28292-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2013-04-08 20:02 ` Tejun Heo 2013-04-09 9:50 ` Daniel P. Berrange 2013-04-09 9:50 ` Daniel P. Berrange [not found] ` <20130409095024.GI25576-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2013-04-09 19:38 ` Tejun Heo 2013-04-09 19:38 ` Tejun Heo [not found] ` <20130409193851.GJ6186-9pTldWuhBndy/B6EtB590w@public.gmane.org> 2013-04-09 19:46 ` Tejun Heo 2013-04-09 19:46 ` Tejun Heo [not found] ` <20130409194640.GK6186-9pTldWuhBndy/B6EtB590w@public.gmane.org> 2013-04-09 21:04 ` Serge Hallyn 2013-04-09 21:04 ` Serge Hallyn 2013-04-09 21:11 ` Tejun Heo 2013-04-09 21:11 ` Tejun Heo 2013-04-09 21:11 ` Tejun Heo 2013-04-16 11:17 ` Li Zefan 2013-04-22 21:26 ` Tim Hockin 2013-04-16 11:17 ` Li Zefan 2013-04-16 11:17 ` Li Zefan [not found] ` <516D333D.4040703-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> 2013-04-16 17:10 ` Tejun Heo 2013-04-16 17:10 ` Tejun Heo 2013-04-17 1:29 ` Li Zefan 2013-04-17 1:29 ` Li Zefan [not found] ` <20130416171056.GA2874-9pTldWuhBndy/B6EtB590w@public.gmane.org> 2013-04-17 1:29 ` Li Zefan 2013-04-22 21:26 ` Tim Hockin 2013-04-22 21:26 ` Tim Hockin [not found] ` <CAAAKZwvh_R2Xz--bmSLiN33fsqKanOJMq_6+6hoFWFRx38O4gA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-04-22 21:41 ` Tejun Heo 2013-04-22 21:41 ` Tejun Heo [not found] ` <20130422214159.GG12543-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org> 2013-04-22 22:33 ` Tim Hockin 2013-04-22 22:33 ` Tim Hockin 2013-04-22 22:33 ` Tim Hockin [not found] ` <CAAAKZwuXJwwyj7KSqb7rZ+nrTwBWEaUCWfa7kWecTBnHL8koGw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-06-22 23:13 ` Tim Hockin 2013-06-22 23:13 ` Tim Hockin 2013-06-22 23:13 ` Tim Hockin [not found] ` <CAAAKZwvP_7wBBYMmtFuiE2hZt=ByaLrnTyiR83CZr3OMip63Gg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-06-25 0:01 ` Tejun Heo 2013-06-25 0:01 ` Tejun Heo 2013-06-25 4:07 ` Tim Hockin 2013-06-25 4:07 ` Tim Hockin [not found] ` <CAAAKZwt09k-qUwLCnMpAQeYJ-S0XtkjXe4=bJ-G_fcrkAqEzoA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-06-26 21:20 ` Tejun Heo 2013-06-26 21:20 ` Tejun Heo 2013-06-27 0:06 ` Tim Hockin 2013-06-27 0:06 ` Tim Hockin 2013-06-26 23:14 ` David Lang [not found] ` <CAAAKZws1qkSik4G4pRr7z+067Jp9-jHfpx9-euqbvmdHjoN_Zg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-06-26 23:14 ` David Lang 2013-06-27 1:04 ` Tejun Heo 2013-06-27 1:04 ` Tejun Heo [not found] ` <20130627010427.GF4536-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org> 2013-06-27 3:42 ` Tim Hockin 2013-06-27 3:42 ` Tim Hockin [not found] ` <CAAAKZwsMT7FRccyVxSn77GR8+9JsSeqmDO6oOy7ycNCY7Desnw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-06-27 17:38 ` Tejun Heo 2013-06-27 17:38 ` Tejun Heo 2013-06-27 20:46 ` Tim Hockin 2013-06-27 20:46 ` Tim Hockin [not found] ` <CAAAKZwvabGRsce43ymru7OBr0LX93DRnTVkzn-nhahTR6yMUZw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-06-27 21:04 ` Tejun Heo 2013-06-27 21:04 ` Tejun Heo [not found] ` <20130627210445.GA22860-9pTldWuhBndy/B6EtB590w@public.gmane.org> 2013-06-28 18:44 ` Tim Hockin [this message] 2013-06-28 18:44 ` Tim Hockin [not found] ` <CAAAKZwtOnpATCmRcOpsXaLZ8sQDs2Z=iZb8FrqG=bajNAOBnRg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-06-29 16:40 ` Tejun Heo 2013-06-29 16:40 ` Tejun Heo 2015-03-03 21:53 ` Luke Leighton [not found] ` <20130627173809.GB5599-9pTldWuhBndy/B6EtB590w@public.gmane.org> 2013-06-27 20:46 ` Tim Hockin 2015-03-03 21:38 ` Luke Leighton 2015-03-03 21:17 ` Luke Leighton 2015-03-04 5:08 ` David Lang 2015-03-04 11:27 ` Luke Kenneth Casson Leighton 2015-03-04 20:08 ` David Lang [not found] ` <20130626212047.GB4536-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org> 2013-06-27 0:06 ` Tim Hockin 2013-06-27 5:45 ` Mike Galbraith 2013-06-27 5:45 ` Mike Galbraith 2013-06-27 5:45 ` Mike Galbraith 2013-06-27 13:22 ` Serge Hallyn 2013-06-27 13:22 ` Serge Hallyn 2013-06-27 15:29 ` Tim Hockin 2013-06-27 15:29 ` Tim Hockin 2013-06-27 15:29 ` Tim Hockin 2013-06-27 16:18 ` Serge Hallyn 2013-06-27 16:18 ` Serge Hallyn 2015-03-03 22:00 ` Luke Leighton [not found] ` <CAAAKZwt9QdddFrEjvdBsi3sbQXScKyzY=vZpYXqTwjGUebH1Ag-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-06-27 16:18 ` Serge Hallyn 2013-06-27 17:48 ` Tejun Heo 2013-06-27 17:48 ` Tejun Heo [not found] ` <20130627174850.GC5599-9pTldWuhBndy/B6EtB590w@public.gmane.org> 2013-06-27 18:14 ` Serge Hallyn 2013-06-27 18:14 ` Serge Hallyn 2013-06-27 18:14 ` Serge Hallyn 2013-06-27 18:45 ` Tejun Heo 2013-06-27 18:45 ` Tejun Heo [not found] ` <20130627184541.GA6400-9pTldWuhBndy/B6EtB590w@public.gmane.org> 2013-06-27 18:51 ` Serge Hallyn 2013-06-27 18:51 ` Serge Hallyn 2013-06-27 18:51 ` Serge Hallyn 2013-06-27 18:52 ` Tejun Heo 2013-06-27 18:52 ` Tejun Heo 2013-06-27 18:52 ` Tejun Heo 2013-06-27 20:52 ` Tim Hockin 2013-06-27 20:52 ` Tim Hockin 2015-03-03 22:08 ` Luke Leighton 2013-06-28 9:09 ` [Workman-devel] " Daniel P. Berrange 2013-06-28 9:09 ` Daniel P. Berrange 2013-06-28 15:53 ` Serge Hallyn 2013-06-28 15:53 ` Serge Hallyn 2013-06-28 18:58 ` Tim Hockin 2013-06-28 18:58 ` Tim Hockin 2015-03-03 22:20 ` Luke Leighton [not found] ` <20130628090910.GB2507-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2013-06-28 15:53 ` Serge Hallyn [not found] ` <1372311907.5871.78.camel-YqMYhexLQo31wTEvPJ5Q0F6hYfS7NtTn@public.gmane.org> 2013-06-27 13:22 ` Serge Hallyn 2013-06-27 18:01 ` Tejun Heo 2013-06-27 18:01 ` Tejun Heo 2013-06-27 18:01 ` Tejun Heo 2013-06-28 3:46 ` Mike Galbraith 2013-06-28 3:46 ` Mike Galbraith [not found] ` <1372391198.5989.110.camel-YqMYhexLQo31wTEvPJ5Q0F6hYfS7NtTn@public.gmane.org> 2013-06-28 4:09 ` Tejun Heo 2013-06-28 4:09 ` Tejun Heo 2013-06-28 4:09 ` Tejun Heo 2013-06-28 4:49 ` Mike Galbraith 2013-06-28 4:49 ` Mike Galbraith [not found] ` <1372394950.5989.128.camel-YqMYhexLQo31wTEvPJ5Q0F6hYfS7NtTn@public.gmane.org> 2013-06-28 5:01 ` Tejun Heo 2013-06-28 5:01 ` Tejun Heo 2013-06-28 5:01 ` Tejun Heo [not found] ` <20130628050138.GD2500-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org> 2013-06-28 6:00 ` Mike Galbraith 2013-06-28 6:00 ` Mike Galbraith 2013-06-28 15:05 ` Michal Hocko 2013-06-28 15:05 ` Michal Hocko 2013-06-28 15:05 ` Michal Hocko [not found] ` <20130628150513.GD5125-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org> 2013-06-28 18:01 ` [Workman-devel] " Vivek Goyal 2013-06-28 18:01 ` Vivek Goyal [not found] ` <20130628180155.GD16483-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2013-06-28 19:59 ` Daniel P. Berrange 2013-06-28 19:59 ` Daniel P. Berrange [not found] ` <20130628195917.GG2507-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2013-06-28 22:40 ` Serge Hallyn 2013-06-28 22:40 ` Serge Hallyn 2013-06-28 22:40 ` Serge Hallyn 2013-06-28 22:43 ` Tejun Heo 2013-06-28 22:43 ` Tejun Heo 2013-06-28 22:43 ` Tejun Heo 2013-06-30 18:38 ` Michal Hocko 2013-06-30 18:38 ` Michal Hocko 2013-06-30 18:38 ` Michal Hocko [not found] ` <20130630183838.GB23731-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org> 2013-07-15 18:49 ` Vivek Goyal 2013-07-15 18:49 ` Vivek Goyal [not found] ` <20130715184940.GG27338-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2013-07-23 14:48 ` Michal Hocko 2013-07-23 14:48 ` Michal Hocko 2013-07-23 14:48 ` Michal Hocko 2013-06-28 18:30 ` Tejun Heo 2013-06-28 18:30 ` Tejun Heo 2013-06-28 18:53 ` Tim Hockin 2013-06-28 18:53 ` Tim Hockin [not found] ` <CAAAKZwtqYe-c0bfkgHFbzsOKVHifjTwkqcpci=uS1JwqS9TJHQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-06-28 19:01 ` Vrijendra (वृजेन्द्र) Gokhale 2013-06-29 1:48 ` Lennart Poettering 2013-06-29 1:48 ` Lennart Poettering [not found] ` <51CE3CE0.9010506-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2013-06-29 3:05 ` Tim Hockin 2013-06-29 3:05 ` Tim Hockin [not found] ` <CAAAKZwuzhSzPj99HZW=KD4emGXZbcsjsUu=+TCpafhs9MKD2JA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-06-30 19:39 ` Lennart Poettering 2013-06-30 19:39 ` Lennart Poettering 2013-07-02 23:57 ` Thomas Gleixner 2013-07-02 23:57 ` Thomas Gleixner [not found] ` <alpine.DEB.2.02.1307030021480.4013-3cz04HxQygjZikZi3RtOZ1XZhhPuCNm+@public.gmane.org> 2013-07-03 0:44 ` Kay Sievers 2013-07-03 17:11 ` James Bottomley 2013-07-03 0:44 ` Kay Sievers 2013-07-03 0:44 ` Kay Sievers 2013-07-03 7:37 ` Borislav Petkov 2013-07-03 7:37 ` Borislav Petkov 2013-07-03 9:30 ` Thomas Gleixner 2013-07-03 9:30 ` Thomas Gleixner 2013-07-09 23:12 ` Jiri Kosina 2013-07-09 23:12 ` Jiri Kosina [not found] ` <CAPXgP12AyogbFX_hPPmQD5GFG0-+_crsnHF3epDZSRds3-WNtQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-07-03 7:37 ` Borislav Petkov 2013-07-03 9:30 ` Thomas Gleixner 2013-07-09 23:12 ` Jiri Kosina 2013-07-03 17:11 ` James Bottomley 2013-07-03 17:11 ` James Bottomley [not found] ` <51D08976.6040005-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2013-07-01 6:06 ` Tim Hockin 2013-07-01 6:06 ` Tim Hockin 2013-07-02 23:57 ` Thomas Gleixner [not found] ` <20130628040930.GC2500-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org> 2013-06-28 4:49 ` Mike Galbraith [not found] ` <20130627180143.GD5599-9pTldWuhBndy/B6EtB590w@public.gmane.org> 2013-06-28 3:46 ` Mike Galbraith 2013-06-28 19:18 ` Andy Lutomirski 2013-06-28 19:18 ` Andy Lutomirski [not found] ` <51CDE18E.8080009-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> 2013-06-28 19:36 ` Serge Hallyn 2013-06-28 19:36 ` Serge Hallyn 2013-06-28 19:36 ` Serge Hallyn [not found] ` <20130625000118.GT1918-9pTldWuhBndy/B6EtB590w@public.gmane.org> 2013-06-25 4:07 ` Tim Hockin
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='CAAAKZwtOnpATCmRcOpsXaLZ8sQDs2Z=iZb8FrqG=bajNAOBnRg@mail.gmail.com' \ --to=thockin-rl2obbrerpqdnm+yrofe0a@public.gmane.org \ --cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \ --cc=dawnchen-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \ --cc=dhaval.giani-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \ --cc=jpoimboe-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \ --cc=kay.sievers-tD+1rO4QERM@public.gmane.org \ --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=lpoetter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \ --cc=pjt-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \ --cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \ --cc=workman-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \ /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: linkBe 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.