On 2017-09-06 09:03, Serge E. Hallyn wrote:
> Quoting Richard Guy Briggs (r...@redhat.com):
> ...
> > > I believe we are going to need a container ID to container definition
> > > (namespace, etc.) mapping mechanism regardless of if the container ID
> > > is provided by userspace or a kernel
On 2017-09-06 09:03, Serge E. Hallyn wrote:
> Quoting Richard Guy Briggs (r...@redhat.com):
> ...
> > > I believe we are going to need a container ID to container definition
> > > (namespace, etc.) mapping mechanism regardless of if the container ID
> > > is provided by userspace or a kernel
On Fri, Aug 18, 2017 at 4:03 AM, Richard Guy Briggs wrote:
> On 2017-08-16 18:21, Paul Moore wrote:
>> On Mon, Aug 14, 2017 at 1:47 AM, Richard Guy Briggs wrote:
>> > Hi David,
>> >
>> > I wanted to respond to this thread to attempt some constructive feedback,
On Fri, Aug 18, 2017 at 4:03 AM, Richard Guy Briggs wrote:
> On 2017-08-16 18:21, Paul Moore wrote:
>> On Mon, Aug 14, 2017 at 1:47 AM, Richard Guy Briggs wrote:
>> > Hi David,
>> >
>> > I wanted to respond to this thread to attempt some constructive feedback,
>> > better late than never. I had
Quoting Richard Guy Briggs (r...@redhat.com):
...
> > I believe we are going to need a container ID to container definition
> > (namespace, etc.) mapping mechanism regardless of if the container ID
> > is provided by userspace or a kernel generated serial number. This
> > mapping should be
Quoting Richard Guy Briggs (r...@redhat.com):
...
> > I believe we are going to need a container ID to container definition
> > (namespace, etc.) mapping mechanism regardless of if the container ID
> > is provided by userspace or a kernel generated serial number. This
> > mapping should be
On 2017-08-16 18:21, Paul Moore wrote:
> On Mon, Aug 14, 2017 at 1:47 AM, Richard Guy Briggs wrote:
> > Hi David,
> >
> > I wanted to respond to this thread to attempt some constructive feedback,
> > better late than never. I had a look at your fsopen/fsmount() patchset(s)
> >
On 2017-08-16 18:21, Paul Moore wrote:
> On Mon, Aug 14, 2017 at 1:47 AM, Richard Guy Briggs wrote:
> > Hi David,
> >
> > I wanted to respond to this thread to attempt some constructive feedback,
> > better late than never. I had a look at your fsopen/fsmount() patchset(s)
> > to
> > support
On Mon, Aug 14, 2017 at 1:47 AM, Richard Guy Briggs wrote:
> Hi David,
>
> I wanted to respond to this thread to attempt some constructive feedback,
> better late than never. I had a look at your fsopen/fsmount() patchset(s) to
> support this patchset which was interesting, but
On Mon, Aug 14, 2017 at 1:47 AM, Richard Guy Briggs wrote:
> Hi David,
>
> I wanted to respond to this thread to attempt some constructive feedback,
> better late than never. I had a look at your fsopen/fsmount() patchset(s) to
> support this patchset which was interesting, but doesn't directly
On 2017-05-22 17:22, David Howells wrote:
> A container is then a kernel object that contains the following things:
>
> (1) Namespaces.
>
> (2) A root directory.
>
> (3) A set of processes, including one designated as the 'init' process.
>
> A container is created and attached to a file
On 2017-05-22 17:22, David Howells wrote:
> A container is then a kernel object that contains the following things:
>
> (1) Namespaces.
>
> (2) A root directory.
>
> (3) A set of processes, including one designated as the 'init' process.
>
> A container is created and attached to a file
A container is then a kernel object that contains the following things:
(1) Namespaces.
(2) A root directory.
(3) A set of processes, including one designated as the 'init' process.
A container is created and attached to a file descriptor by:
int cfd = container_create(const char
A container is then a kernel object that contains the following things:
(1) Namespaces.
(2) A root directory.
(3) A set of processes, including one designated as the 'init' process.
A container is created and attached to a file descriptor by:
int cfd = container_create(const char
14 matches
Mail list logo