Serge E. Hallyn wrote:
> Quoting Pavel Emelyanov ([EMAIL PROTECTED]):
>> Dave Hansen wrote:
>>> On Tue, 2008-01-15 at 11:25 +0300, Pavel Emelyanov wrote:
Hmm. I have an idea how to make this w/o a new system call. This might
look wierd, but. Why not stopple the last bit with a CLONE_NEWCL
Quoting Pavel Emelyanov ([EMAIL PROTECTED]):
> Dave Hansen wrote:
> > On Tue, 2008-01-15 at 11:25 +0300, Pavel Emelyanov wrote:
> >> Hmm. I have an idea how to make this w/o a new system call. This might
> >> look wierd, but. Why not stopple the last bit with a CLONE_NEWCLONE and
> >> consider the
Quoting Cedric Le Goater ([EMAIL PROTECTED]):
> Serge E. Hallyn wrote:
> > Quoting Cedric Le Goater ([EMAIL PROTECTED]):
> >> to be more precise :
> >>
> >>long sys_clone_something(struct clone_something_args args)
> >>
> >> and
> >>
> >>long sys_unshare_something(struct unshare_something
Cedric Le Goater wrote:
> Pavel Emelyanov wrote:
>> Cedric Le Goater wrote:
>>> Pavel Emelyanov wrote:
Dave Hansen wrote:
> On Mon, 2008-01-14 at 16:36 -0500, Oren Laadan wrote:
>> I second the concern of running out of 64 bits of flags. In fact, the
>> problem with the flags is li
Pavel Emelyanov wrote:
> Cedric Le Goater wrote:
>> Pavel Emelyanov wrote:
>>> Dave Hansen wrote:
On Mon, 2008-01-14 at 16:36 -0500, Oren Laadan wrote:
> I second the concern of running out of 64 bits of flags. In fact, the
> problem with the flags is likely to be valid outside our con
Dave Hansen wrote:
> On Tue, 2008-01-15 at 11:25 +0300, Pavel Emelyanov wrote:
>> Hmm. I have an idea how to make this w/o a new system call. This might
>> look wierd, but. Why not stopple the last bit with a CLONE_NEWCLONE and
>> consider the parent_tidptr/child_tidptr in this case as the pointer
On Tue, 2008-01-15 at 11:25 +0300, Pavel Emelyanov wrote:
> Hmm. I have an idea how to make this w/o a new system call. This might
> look wierd, but. Why not stopple the last bit with a CLONE_NEWCLONE and
> consider the parent_tidptr/child_tidptr in this case as the pointer to
> an array of extra
Cedric Le Goater wrote:
> Pavel Emelyanov wrote:
>> Dave Hansen wrote:
>>> On Mon, 2008-01-14 at 16:36 -0500, Oren Laadan wrote:
I second the concern of running out of 64 bits of flags. In fact, the
problem with the flags is likely to be valid outside our context, and
general to the
Pavel Emelyanov wrote:
> Dave Hansen wrote:
>> On Mon, 2008-01-14 at 16:36 -0500, Oren Laadan wrote:
>>> I second the concern of running out of 64 bits of flags. In fact, the
>>> problem with the flags is likely to be valid outside our context, and
>>> general to the linux kernel soon. Should we no
Dave Hansen wrote:
> On Mon, 2008-01-14 at 16:36 -0500, Oren Laadan wrote:
>> I second the concern of running out of 64 bits of flags. In fact, the
>> problem with the flags is likely to be valid outside our context, and
>> general to the linux kernel soon. Should we not discuss it there
>> too ?
Serge E. Hallyn wrote:
> Quoting Cedric Le Goater ([EMAIL PROTECTED]):
>> to be more precise :
>>
>> long sys_clone_something(struct clone_something_args args)
>>
>> and
>>
>> long sys_unshare_something(struct unshare_something_args args)
>>
>> The arg passing will be slower bc of the
On Mon, 2008-01-14 at 16:36 -0500, Oren Laadan wrote:
> I second the concern of running out of 64 bits of flags. In fact, the
> problem with the flags is likely to be valid outside our context, and
> general to the linux kernel soon. Should we not discuss it there
> too ?
It would be pretty easy
Serge E. Hallyn wrote:
> Quoting Pavel Emelyanov ([EMAIL PROTECTED]):
>> Serge E. Hallyn wrote:
>>> Quoting Cedric Le Goater ([EMAIL PROTECTED]):
to be more precise :
long sys_clone_something(struct clone_something_args args)
and
long sys_unshare_somethi
Quoting Pavel Emelyanov ([EMAIL PROTECTED]):
> Serge E. Hallyn wrote:
> > Quoting Cedric Le Goater ([EMAIL PROTECTED]):
> >> to be more precise :
> >>
> >>long sys_clone_something(struct clone_something_args args)
> >>
> >> and
> >>
> >>long sys_unshare_something(struct unshare_something_
Serge E. Hallyn wrote:
> Quoting Cedric Le Goater ([EMAIL PROTECTED]):
>> to be more precise :
>>
>> long sys_clone_something(struct clone_something_args args)
>>
>> and
>>
>> long sys_unshare_something(struct unshare_something_args args)
>>
>> The arg passing will be slower bc of the
Quoting Cedric Le Goater ([EMAIL PROTECTED]):
> to be more precise :
>
> long sys_clone_something(struct clone_something_args args)
>
> and
>
> long sys_unshare_something(struct unshare_something_args args)
>
> The arg passing will be slower bc of the copy_from_user() but we will
>>> I started looking at PTYs/TTYs/Console to make the appropriate
>>> namespace and suddenly remembered that we have already
>>> exhausted all the CLONE_ bits in 32-bit mask.
>> yes nearly. 1 left with the mq_namespace i'm going to send.
>
> Yup. That's why I think that we should first solve thi
Cedric Le Goater wrote:
> Hello Pavel !
>
> Pavel Emelyanov wrote:
>> Hi, guys!
>>
>> I started looking at PTYs/TTYs/Console to make the appropriate
>> namespace and suddenly remembered that we have already
>> exhausted all the CLONE_ bits in 32-bit mask.
>
> yes nearly. 1 left with the mq_namesp
Hello Pavel !
Pavel Emelyanov wrote:
> Hi, guys!
>
> I started looking at PTYs/TTYs/Console to make the appropriate
> namespace and suddenly remembered that we have already
> exhausted all the CLONE_ bits in 32-bit mask.
yes nearly. 1 left with the mq_namespace i'm going to send.
> So, I recall
19 matches
Mail list logo
