H. Peter Anvin wrote:
> [EMAIL PROTECTED] wrote:
>> This is a resend of the patch set Cedric had sent earlier. I ported
>> the patch set to 2.6.25-rc8-mm1 and tested on x86 and x86_64.
>> ---
>>
>> We have run out of the 32 bits in clone_flags !
>>
>> This patchset introduces 2 new system calls whi
Where can I get the source rpm for MAKEDEV-3.3.13-1.3.swsoft.i386.rpm?
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
[EMAIL PROTECTED] wrote:
> Jakub Jelinek [EMAIL PROTECTED] wrote:
> | On Wed, Apr 09, 2008 at 03:34:59PM -0700, [EMAIL PROTECTED] wrote:
> | > From: Cedric Le Goater <[EMAIL PROTECTED]>
> | > Subject: [PATCH 3/3] add the clone64() and unshare64() syscalls
> | >
> | > This patch adds 2 new syscalls
On Wed, Apr 9, 2008 at 7:38 PM, <[EMAIL PROTECTED]> wrote:
>
> But as Jon Corbet pointed out in the the thread above, it looked like
> adding a new system call has been the "traditional" way of solving this
> in Linux so far and there has been no consensus on a newer approach.
>
I thought that
H. Peter Anvin [EMAIL PROTECTED] wrote:
>> Yes, this was discussed before in the context of Pavel Emelyanov's patch
>> http://lkml.org/lkml/2008/1/16/109
>> along with sys_indirect(). While there was no consensus, it looked like
>> adding a new system call was better than open ended interface
Jakub Jelinek [EMAIL PROTECTED] wrote:
| On Wed, Apr 09, 2008 at 03:34:59PM -0700, [EMAIL PROTECTED] wrote:
| > From: Cedric Le Goater <[EMAIL PROTECTED]>
| > Subject: [PATCH 3/3] add the clone64() and unshare64() syscalls
| >
| > This patch adds 2 new syscalls :
| >
| > long sys_clone64(uns
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> On Tue, 2008-04-08 at 17:53 -0700, H. Peter Anvin wrote:
> > [EMAIL PROTECTED] wrote:
> > > Devpts namespace patchset
> > >
> > > In continuation of the implementation of containers in mainline, we need
> > > to
> > > support multiple PTY namespace
[EMAIL PROTECTED] wrote:
>>
>> If you're going to make it a 64-bit pass it in as a 64-bit number, instead
>> of breaking it into two numbers.
>
> Maybe I am missing your point. The glibc interface could take a 64bit
> parameter, but don't we need to pass 32-bit values into the system call
> on 3
H. Peter Anvin [EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
>> This is a resend of the patch set Cedric had sent earlier. I ported
>> the patch set to 2.6.25-rc8-mm1 and tested on x86 and x86_64.
>> ---
>> We have run out of the 32 bits in clone_flags !
>> This patchset introduces 2 new syst
[EMAIL PROTECTED] wrote:
> This is a resend of the patch set Cedric had sent earlier. I ported
> the patch set to 2.6.25-rc8-mm1 and tested on x86 and x86_64.
> ---
>
> We have run out of the 32 bits in clone_flags !
>
> This patchset introduces 2 new system calls which support 64bit clone-flags.
[EMAIL PROTECTED] wrote:
>> I'm just worried about the accumulation of what feels like ad hoc
>> namespaces, causing a very large combination matrix, a lot of which don't
>> make sense.
>
> Hmm, if we were to just call this CLONE_NEWDEV, would that (a) make
> sense and (b) suitably address your
From: Cedric Le Goater <[EMAIL PROTECTED]>
Subject: [PATCH 3/3] add the clone64() and unshare64() syscalls
This patch adds 2 new syscalls :
long sys_clone64(unsigned long flags_high, unsigned long flags_low,
unsigned long newsp);
long sys_unshare64(unsigned long flags_h
From: Sukadev Bhattiprolu <[EMAIL PROTECTED]>
Subject: [PATCH 2/3] add do_unshare()
This patch adds a do_unshare() routine which will be common
to the unshare() and unshare64() syscall.
Signed-off-by: Cedric Le Goater <[EMAIL PROTECTED]>
Signed-off-by: Sukadev Bhattiprolu <[EMAIL PROTECTED]>
---
From: Sukadev Bhattiprolu <[EMAIL PROTECTED]>
Subject: [lxc-dev] [patch -lxc 1/3] change clone_flags type to u64
This is a preliminary patch changing the clone_flags type to 64bits
for all the routines called by do_fork().
It prepares ground for the next patch which introduces an enhanced
versi
This is a resend of the patch set Cedric had sent earlier. I ported
the patch set to 2.6.25-rc8-mm1 and tested on x86 and x86_64.
---
We have run out of the 32 bits in clone_flags !
This patchset introduces 2 new system calls which support 64bit clone-flags.
long sys_clone64(unsigned long
On Tue, 2008-04-08 at 17:53 -0700, H. Peter Anvin wrote:
> [EMAIL PROTECTED] wrote:
> > Devpts namespace patchset
> >
> > In continuation of the implementation of containers in mainline, we need to
> > support multiple PTY namespaces so that the PTY index (ie the tty names) in
> > one container is
Quoting H. Peter Anvin ([EMAIL PROTECTED]):
> [EMAIL PROTECTED] wrote:
>> We want to provide isolation between containers, meaning PTYs in container
>> C1 should not be accessible to processes in C2 (unless C2 is an ancestor).
>
> Yes, I certainly can understand the desire for isolation. That wasn
[EMAIL PROTECTED] wrote:
> We want to provide isolation between containers, meaning PTYs in container
> C1 should not be accessible to processes in C2 (unless C2 is an ancestor).
Yes, I certainly can understand the desire for isolation. That wasn't
what my question was about.
> The other reason
H. Peter Anvin [EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
>> Devpts namespace patchset
>> In continuation of the implementation of containers in mainline, we need
>> to
>> support multiple PTY namespaces so that the PTY index (ie the tty names)
>> in
>> one container is independent of th
All IP addresses that are present in a system are duplicated on
struct sctp_sockaddr_entry. They are linked in the global list
called sctp_local_addr_list. And this struct unions IPv4 and IPv6
addresses.
So, there can be rare case, when a sockaddr_in.sin_addr coincides
with the corresponding par
On Mon, 2008-04-07 at 22:43 -0700, Paul Menage wrote:
> On Mon, Apr 7, 2008 at 10:39 PM, Nikanth Karthikesan <[EMAIL PROTECTED]>
> wrote:
> >
> > Why not provide a interface to add subsystems at run-time instead?
> > Are there any reason for not letting a subsystem to be implemented as a
> > lo
Hi Pavel,
All three patches look perfectly fine to me.
Feel free to add Acked-by: Max Krasnyansky <[EMAIL PROTECTED]>
Pavel Emelyanov wrote:
This is basically means that a net is set for a new device, but
actually this involves two more steps:
1. mark the tun device as "local", i.e. do not all
> On 4/1/08, Pavel Machek <[EMAIL PROTECTED]> wrote:
> > > > > --- a/include/linux/cgroup_subsys.h
> > > > > +++ b/include/linux/cgroup_subsys.h
> > > > > @@ -42,3 +42,9 @@ SUBSYS(mem_cgroup)
> > > > > #endif
> > > > >
> > > > > /* */
> > > > > +
> > > > > +#ifdef CONFIG_CGROUP_DEVICE
> >
> > There were some band-width control patches based on cfq + cgroups, which
> > I guess will mandate cfq to be built-in?
> >
>
> Yes, or else have built-in stubs for the cgroup subsystem that load
> cfq and the code that uses cfq the first time someone tries to mount
> that subsystem.
>
I thi
24 matches
Mail list logo
