OpenVZ Forum - RDF feed
type: channel
items: [PATCH 0/3] clone64() and unshare64() system calls
items: [PATCH 1/3] change clone_flags type to u64
items: [PATCH 2/3] add do_unshare()
items: [PATCH 3/3] add the clone64() and unshare64() syscalls
items: Re: [PATCH 3/3] add the clone64() and unshare64() syscalls
items: Re: [PATCH 0/3] clone64() and unshare64() system calls
items: Re: [PATCH 1/3] change clone_flags type to u64

[PATCH 0/3] clone64() and unshare64() system calls
type: item
description: 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 flags_high, unsigned long flags_low, unsigned long newsp); long sys_unshare64(unsigned long flags_high, unsigned long flags_low); The current version of clone64() does not support CLONE_PARENT_SETTID and CLONE_CHILD_CLEARTID because we would exceed the 6 registers limit of some arches. It's possible to get around this limitation but we might not need it as we already have clone() This is work in progress but already includes support for x86, x86_64, x86_64(32), ppc64, ppc64(32), s390x, s390x(31). ia64 already supports 64bits clone flags through the clone2() syscall. should we harmonize the name to clone2 ? _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Sukadev Bhattiprolu
date: 2008-04-09T22:26:11-00:00

[PATCH 1/3] change clone_flags type to u64
type: item
description: From: Sukadev Bhattiprolu <sukadev@us.ibm.com> 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 version of clone() supporting 64bits flags. This is work in progress. All conversions might not be done yet. Signed-off-by: Cedric Le Goater <clg@fr.ibm.com> Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> --- arch/alpha/kernel/process.c | 2 +- arch/arm/kernel/process.c | 2 +- arch/avr32/kernel/process.c | 2 +- arch/blackfin/kernel/process.c | 2 +- arch/cris/arch-v10/kernel/process.c | 2 +- arch/cris/arch-v32/kernel/process.c | 2 +- arch/frv/kernel/process.c | 2 +- arch/h8300/kernel/process.c | 2 +- arch/ia64/ia32/sys_ia32.c | 2 +- arch/ia64/kernel/process.c | 2 +- arch/m32r/kernel/process.c | 2 +- arch/m68k/kernel/process.c | 2 +- arch/m68knommu/kernel/process.c | 2 +- arch/mips/kernel/process.c | 2 +- arch/mn10300/kernel/process.c | 2 +- arch/parisc/kernel/process.c | 2 +- arch/powerpc/kernel/process.c | 2 +- arch/s390/kernel/process.c | 2 +- arch/sh/kernel/process_32.c | 2 +- arch/sh/kernel/process_64.c | 2 +- arch/sparc/kernel/process.c | 2 +- arch/sparc64/kernel/process.c | 2 +- arch/um/kernel/process.c | 2 +- arch/v850/kernel/process.c | 2 +- arch/x86/kernel/process_32.c | 2 +- arch/x86/kernel/process_64.c | 2 +- arch/xtensa/kernel/process.c | 2 +- fs/namespace.c | 2 +- include/linux/ipc_namespace.h | 4 ++-- include/linux/key.h | 2 +- include/linux/mnt_namespace.h | 2 +- include/linux/nsproxy.h | 4 ++-- include/linux/pid_namespace.h | 4 ++-- include/linux/sched.h | 6 ++++-- include/linux/security.h | 6 +++--- include/linux/sem.h | 4 ++-- include/linux/user_namespace.h | 4 ++-- include/linux/utsname.h | 4 ++-- include/net/net_namespace.h | 4 ++-- ipc/namespace.c | 2 +- ipc/sem.c | 2 +- kernel/fork.c | 36 ++++++++++++++++++------------------ kernel/nsproxy.c | 6 +++---…
creator: Sukadev Bhattiprolu
date: 2008-04-09T22:32:31-00:00

[PATCH 2/3] add do_unshare()
type: item
description: From: Sukadev Bhattiprolu <sukadev@us.ibm.com> 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 <clg@fr.ibm.com> Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> --- kernel/fork.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) Index: 2.6.25-rc2-mm1/kernel/fork.c =================================================================== --- 2.6.25-rc2-mm1.orig/kernel/fork.c +++ 2.6.25-rc2-mm1/kernel/fork.c @@ -1696,7 +1696,7 @@ static int unshare_semundo(u64 unshare_f * constructed. Here we are modifying the current, active, * task_struct. */ -asmlinkage long sys_unshare(unsigned long unshare_flags) +static long do_unshare(u64 unshare_flags) { int err = 0; struct fs_struct *fs, *new_fs = NULL; @@ -1790,3 +1790,8 @@ bad_unshare_cleanup_thread: bad_unshare_out: return err; } + +asmlinkage long sys_unshare(unsigned long unshare_flags) +{ + return do_unshare(unshare_flags); +} -- --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "lxc-dev" group. To post to this group, send email to lxc-dev@googlegroups.com To unsubscribe from this group, send email to lxc-dev-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/lxc-dev?hl=en -~----------~----~----~----~------~----~------~--~--- _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Sukadev Bhattiprolu
date: 2008-04-09T22:34:06-00:00

[PATCH 3/3] add the clone64() and unshare64() syscalls
type: item
description: From: Cedric Le Goater <clg@fr.ibm.com> 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_high, unsigned long flags_low); The current version of clone64() does not support CLONE_PARENT_SETTID and CLONE_CHILD_CLEARTID because we would exceed the 6 registers limit of some arches. It's possible to get around this limitation but we might not need it as we already have clone() Signed-off-by: Cedric Le Goater <clg@fr.ibm.com> Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> --- arch/powerpc/kernel/entry_32.S | 8 ++++++++ arch/powerpc/kernel/entry_64.S | 5 +++++ arch/powerpc/kernel/process.c | 15 +++++++++++++++ arch/s390/kernel/compat_linux.c | 16 ++++++++++++++++ arch/s390/kernel/compat_wrapper.S | 6 ++++++ arch/s390/kernel/process.c | 15 +++++++++++++++ arch/s390/kernel/syscalls.S | 2 ++ arch/x86/ia32/ia32entry.S | 4 ++++ arch/x86/ia32/sys_ia32.c | 12 ++++++++++++ arch/x86/kernel/entry_64.S | 1 + arch/x86/kernel/process_32.c | 14 ++++++++++++++ arch/x86/kernel/process_64.c | 15 +++++++++++++++ arch/x86/kernel/syscall_table_32.S | 2 ++ include/asm-powerpc/systbl.h | 2 ++ include/asm-powerpc/unistd.h | 4 +++- include/asm-s390/unistd.h | 4 +++- include/asm-x86/unistd_32.h | 2 ++ include/asm-x86/unistd_64.h | 4 ++++ include/linux/syscalls.h | 3 +++ kernel/fork.c | 7 +++++++ kernel/sys_ni.c | 3 +++ 21 files changed, 142 insertions(+), 2 deletions(-) Index: 2.6.25-rc2-mm1/arch/s390/kernel/syscalls.S =================================================================== --- 2.6.25-rc2-mm1.orig/arch/s390/kernel/syscalls.S 2008-02-27 15:17:34.000000000 -0800 +++ 2.6.25-rc2-mm1/arch/s390/kernel/syscalls.S 2008-03-06 22:08:49.000000000 -0800 @@ -330,3 +330,5 @@ SYSCALL(sys_eventfd,sys_eventfd,sys_even SYSCALL(sys_timerfd_create,sys_timerfd_create,sys_timerfd_create_wrapper) SYSCALL(sys_timerfd_settime,sy…
creator: Sukadev Bhattiprolu
date: 2008-04-09T22:34:59-00:00

Re: [PATCH 3/3] add the clone64() and unshare64() syscalls
type: item
description: On Wed, Apr 09, 2008 at 03:34:59PM -0700, sukadev@us.ibm.com wrote: > From: Cedric Le Goater <clg@fr.ibm.com> > 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_high, unsigned long flags_low); Can you explain why are you adding it for 64-bit arches too? unsigned long is there already 64-bit, and both sys_clone and sys_unshare have unsigned long flags, rather than unsigned int. Jakub _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Jakub Jelinek
date: 2008-04-09T23:07:34-00:00

Re: [PATCH 0/3] clone64() and unshare64() system calls
type: item
description: sukadev@us.ibm.com 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. > > long sys_clone64(unsigned long flags_high, unsigned long flags_low, > unsigned long newsp); > > long sys_unshare64(unsigned long flags_high, unsigned long flags_low); > > The current version of clone64() does not support CLONE_PARENT_SETTID and > CLONE_CHILD_CLEARTID because we would exceed the 6 registers limit of some > arches. It's possible to get around this limitation but we might not > need it as we already have clone() > I really dislike this interface. 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. Better yet, IMO, would be to pass a pointer to a structure like: struct shared { unsigned long nwords; unsigned long flags[]; }; ... which can be expanded indefinitely. -hpa _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: hpa
date: 2008-04-10T00:00:25-00:00

Re: [PATCH 0/3] clone64() and unshare64() system calls
type: item
description: H. Peter Anvin [hpa@zytor.com] wrote: > sukadev@us.ibm.com 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. >> long sys_clone64(unsigned long flags_high, unsigned long flags_low, >> unsigned long newsp); >> long sys_unshare64(unsigned long flags_high, unsigned long >> flags_low); >> The current version of clone64() does not support CLONE_PARENT_SETTID and >> CLONE_CHILD_CLEARTID because we would exceed the 6 registers limit of some >> arches. It's possible to get around this limitation but we might not >> need it as we already have clone() > > I really dislike this interface. > > 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 32 bit systems ? > Better yet, IMO, would be to pass a pointer to a structure like: > > struct shared { > unsigned long nwords; > unsigned long flags[]; > }; > > ... which can be expanded indefinitely. 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 interfaces. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Sukadev Bhattiprolu
date: 2008-04-10T01:07:17-00:00

Re: [PATCH 0/3] clone64() and unshare64() system calls
type: item
description: sukadev@us.ibm.com 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 32 bit systems ? Not as such, no. The ABI handles that. To make the ABI clean on some architectures, it's good to consider a 64-bit value only in positions where they map to an even:odd register pair once slotted in. > 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 interfaces. That's not really an open-ended interface, it's just an expandable bitmap. -hpa _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: hpa
date: 2008-04-10T01:10:57-00:00

Re: [PATCH 0/3] clone64() and unshare64() system calls
type: item
description: H. Peter Anvin [hpa@zytor.com] 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 interfaces. > > That's not really an open-ended interface, it's just an expandable bitmap. Yes, we liked such an approach earlier too and its conceivable that we will run out of the 64-bits too :-) 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. Sukadev _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Sukadev Bhattiprolu
date: 2008-04-10T02:38:18-00:00

Re: [PATCH 0/3] clone64() and unshare64() system calls
type: item
description: On Wed, Apr 9, 2008 at 7:38 PM, <sukadev@us.ibm.com> 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 the consensus was that adding a new system call was better than trying to force extensibility on to the existing non-extensible system call. But if we are adding a new system call, why not make the new one extensible to reduce the need for yet another new call in the future? Paul _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Paul Menage
date: 2008-04-10T02:43:30-00:00

Re: [PATCH 0/3] clone64() and unshare64() system calls
type: item
description: H. Peter Anvin wrote: > sukadev@us.ibm.com 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. >> >> long sys_clone64(unsigned long flags_high, unsigned long flags_low, >> unsigned long newsp); >> >> long sys_unshare64(unsigned long flags_high, unsigned long >> flags_low); >> >> The current version of clone64() does not support CLONE_PARENT_SETTID >> and CLONE_CHILD_CLEARTID because we would exceed the 6 registers limit >> of some arches. It's possible to get around this limitation but we >> might not >> need it as we already have clone() >> > > I really dislike this interface. > > 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. Better yet, IMO, would be to > pass a pointer to a structure like: > > struct shared { > unsigned long nwords; > unsigned long flags[]; > }; > > ... which can be expanded indefinitely. ok. What about the copy_from_user() overhead ? is this something we care about for a clone like syscall ? If not, this would certainly make our life simpler to extend clone flags. I'm ready to implement anything if someone would just tell me in which direction. Thanks ! C. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Cedric Le Goater
date: 2008-04-10T06:48:50-00:00

Re: [PATCH 1/3] change clone_flags type to u64
type: item
description: sukadev@us.ibm.com writes: > From: Sukadev Bhattiprolu <sukadev@us.ibm.com> > 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(). I must admit I was always a little sceptical of giving every tiny namespaceable kernel feature its own CLONE flag (and it's own CONFIG option). What was the rationale for that again? With your current strategy are you sure that even 64bit will be enough in the end? For me it rather looks like you'll go through those quickly too as more and more of the kernel is namespaced. Also I think the user interface is very unfriendly. How is a non kernel hacker supposed to make sense of these myriads of flags? You'll be creating another CreateProcess123_extra_args_extended() in the end I fear. Wouldn't it be better to just partition all this into fewer more understandable larger feature groups? I think that would be much nicer from pretty much all perspectives (kernel maintenance, user interface sanity, not needing clone128/256 in the end etc.) Some consolidation on the CONFIGs would be good too. I just cannot imagine it really makes sense to configure everything so fine grained and this is just asking for random compile breakage on randconfig. -Andi _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Andi Kleen
date: 2008-04-10T08:25:44-00:00

Re: [PATCH 1/3] change clone_flags type to u64
type: item
description: Hello Andi, Andi Kleen wrote: > sukadev@us.ibm.com writes: > >> From: Sukadev Bhattiprolu <sukadev@us.ibm.com> >> 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(). > > I must admit I was always a little sceptical of giving every tiny > namespaceable kernel feature its own CLONE flag (and it's own > CONFIG option). What was the rationale for that again? I guess that was a development rationale. Most of the namespaces are in use in the container projects like openvz, vserver and probably others and we needed a way to activate the code. Not perfect I agree. > With your current strategy are you sure that even 64bit will > be enough in the end? For me it rather looks like you'll > go through those quickly too as more and more of the kernel > is namespaced. well, we're reaching the end. I hope ! devpts is in progress and mq is just waiting for a clone flag. > Also I think the user interface is very unfriendly. How > is a non kernel hacker supposed to make sense of these > myriads of flags? You'll be creating another > CreateProcess123_extra_args_extended() > in the end I fear. well, the clone interface is a not friendly interface anyway. glibc wraps it and most users just use fork(). We will need a user library, like we have a libphtread or a libaio, to effectively use the namespaces features. This is being worked on but it's another topic. > Wouldn't it be better to just partition all this into > fewer more understandable larger feature groups? I think > that would be much nicer from pretty much all perspectives > (kernel maintenance, user interface sanity, not needing > clone128/256 in the end etc.) Yes. this make sense. Most of the namespaces have dependencies between each other. > Some consolidation on the CONFIGs would be good too. I just > cannot imagine it really makes sense to configure everything > so fine grained and this is jus…
creator: Cedric Le Goater
date: 2008-04-10T12:25:31-00:00

Re: [PATCH 0/3] clone64() and unshare64() system calls
type: item
description: H. Peter Anvin wrote: > sukadev@us.ibm.com 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 32 bit systems ? > > Not as such, no. The ABI handles that. To make the ABI clean on some > architectures, it's good to consider a 64-bit value only in positions > where they map to an even:odd register pair once slotted in. OK. I didn't know that. I took sys_llseek() as an example of an interface to follow when coded clone64(). Thanks, C. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Cedric Le Goater
date: 2008-04-10T12:33:10-00:00

Re: [PATCH 1/3] change clone_flags type to u64
type: item
description: > I guess that was a development rationale. But what rationale? It just doesn't make much sense to me. > Most of the namespaces are in > use in the container projects like openvz, vserver and probably others > and we needed a way to activate the code. You could just have added it to feature groups over time. > > Not perfect I agree. > > > With your current strategy are you sure that even 64bit will > > be enough in the end? For me it rather looks like you'll > > go through those quickly too as more and more of the kernel > > is namespaced. > > well, we're reaching the end. I hope ! devpts is in progress and > mq is just waiting for a clone flag. Are you sure? > > > Also I think the user interface is very unfriendly. How > > is a non kernel hacker supposed to make sense of these > > myriads of flags? You'll be creating another > > CreateProcess123_extra_args_extended() > > in the end I fear. > > well, the clone interface is a not friendly interface anyway. glibc wraps > it But only for the stack setup which is just a minor detail. The basic clone() flags interface used to be pretty sane and usable before it could overloaded with so many tiny features. I especially worry on how user land should keep track of changing kernel here. If you add new feature flag for lots of kernel features it is reasonable to expect that in the future there will be often new features. Does this mean user land needs to be updated all the time? Will this end up like another udev? > We will need a user library, like we have a libphtread or a libaio, to That doesn't make sense. The basic kernel syscalls should be usable, not require some magic library that would likely need intimate knowledge of specific kernel versions to do any good. > but we still need a way to extend the clone flags because none are left. Can we just take out some again that were added in the .25 cycle and readd them once there is a properly thought out interface? That would leave at least one. -Andi ______________________…
creator: Andi Kleen
date: 2008-04-10T12:50:27-00:00

Re: [PATCH 1/3] change clone_flags type to u64
type: item
description: The was no real rationale except for some people seeing "clone" functionality as the match and the fact that FS_NAMESCAPE was done so made them believe it is a good way to go. And I warned about flags limitation at the beginning. Both OpenVZ/vserver suggested to use a special syscall for handling this. Maybe it is a good point to switch to it now finally and stop worring about all this? Andi Kleen wrote: >> I guess that was a development rationale. > > But what rationale? It just doesn't make much sense to me. > >> Most of the namespaces are in >> use in the container projects like openvz, vserver and probably others >> and we needed a way to activate the code. > > You could just have added it to feature groups over time. > >> Not perfect I agree. >> >>> With your current strategy are you sure that even 64bit will >>> be enough in the end? For me it rather looks like you'll >>> go through those quickly too as more and more of the kernel >>> is namespaced. >> well, we're reaching the end. I hope ! devpts is in progress and >> mq is just waiting for a clone flag. > > Are you sure? > >> >>> Also I think the user interface is very unfriendly. How >>> is a non kernel hacker supposed to make sense of these >>> myriads of flags? You'll be creating another >>> CreateProcess123_extra_args_extended() >>> in the end I fear. >> well, the clone interface is a not friendly interface anyway. glibc wraps >> it > > But only for the stack setup which is just a minor detail. > > The basic clone() flags interface used to be pretty sane and usable > before it could overloaded with so many tiny features. > > I especially worry on how user land should keep track of changing kernel > here. If you add new feature flag for lots of kernel features it is > reasonable to expect that in the future there will be often new features. > > Does this mean user land needs to be updated all the time? Will this > end up like another udev? > >> We will need a user library, like we have a libphtread or a l…
creator: Kirill Korotaev
date: 2008-04-10T13:11:53-00:00

Re: [PATCH 1/3] change clone_flags type to u64
type: item
description: Andi Kleen wrote: >> I guess that was a development rationale. > > But what rationale? It just doesn't make much sense to me. Let's add Eric in Cc: >> Most of the namespaces are in >> use in the container projects like openvz, vserver and probably others >> and we needed a way to activate the code. > > You could just have added it to feature groups over time. Yes if the feature group had existed, that would have been a good option. Don't take me wrong. I agree with this group direction. Most namespaces can't be safely decoupled from each other with a clone flag. >> Not perfect I agree. >> >>> With your current strategy are you sure that even 64bit will >>> be enough in the end? For me it rather looks like you'll >>> go through those quickly too as more and more of the kernel >>> is namespaced. >> well, we're reaching the end. I hope ! devpts is in progress and >> mq is just waiting for a clone flag. > > Are you sure? I'm never sure ! :) That's what we have in plan for the moment. >>> Also I think the user interface is very unfriendly. How >>> is a non kernel hacker supposed to make sense of these >>> myriads of flags? You'll be creating another >>> CreateProcess123_extra_args_extended() >>> in the end I fear. >> well, the clone interface is a not friendly interface anyway. glibc wraps >> it > > But only for the stack setup which is just a minor detail. > > The basic clone() flags interface used to be pretty sane and usable > before it could overloaded with so many tiny features. > > I especially worry on how user land should keep track of changing kernel > here. If you add new feature flag for lots of kernel features it is > reasonable to expect that in the future there will be often new features. > > Does this mean user land needs to be updated all the time? Will this > end up like another udev? > >> We will need a user library, like we have a libphtread or a libaio, to > > That doesn't make sense. The basic kernel syscalls should be usable, > not require some magi…
creator: Cedric Le Goater
date: 2008-04-10T13:18:20-00:00

Re: [PATCH 1/3] change clone_flags type to u64
type: item
description: Kirill Korotaev wrote: > The was no real rationale except for some people seeing "clone" functionality > as the match and the fact that FS_NAMESCAPE was done so made them believe it > is a good way to go. > And I warned about flags limitation at the beginning. yes and now, we've hit the clone wall but that's a good thing. > Both OpenVZ/vserver suggested to use a special syscall for handling this. most projects do it that way. > Maybe it is a good point to switch to it now finally and stop worring about all > this? what would be the interface ? C. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Cedric Le Goater
date: 2008-04-10T13:23:00-00:00

Re: [PATCH 0/3] clone64() and unshare64() system calls
type: item
description: Cedric Le Goater wrote: > > OK. I didn't know that. I took sys_llseek() as an example of an interface > to follow when coded clone64(). > llseek() was the first system call that took a doublewidth argument. It's not the one you want to mimic. -hpa _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: hpa
date: 2008-04-10T16:00:05-00:00

Re: [PATCH 1/3] change clone_flags type to u64
type: item
description: Quoting Andi Kleen (andi@firstfloor.org): > > I guess that was a development rationale. > > But what rationale? It just doesn't make much sense to me. > > > Most of the namespaces are in > > use in the container projects like openvz, vserver and probably others > > and we needed a way to activate the code. > > You could just have added it to feature groups over time. > > > > > Not perfect I agree. > > > > > With your current strategy are you sure that even 64bit will > > > be enough in the end? For me it rather looks like you'll > > > go through those quickly too as more and more of the kernel > > > is namespaced. > > > > well, we're reaching the end. I hope ! devpts is in progress and > > mq is just waiting for a clone flag. > > Are you sure? Well for one thing we can take a somewhat different approach to new clone flags. I.e. we could extend CLONE_NEWIPC to do mq instead of introducing a new clone flag. The name doesn't have 'sysv' in it, and globbing all ipc resources together makes some amount of sense. Similarly has hpa+eric pointed out earlier, suka could use CLONE_NEWDEV for ptys. If we have net, pid, ipc, devices, that's a pretty reasonable split imo. Perhaps we tie user to devices and get rid of CLONE_NEWUSER which I suspect noone is using atm (since only Dave has run into the CONFIG_USER_SCHED problem). Or not. We could roll uts into net, and give CLONE_NEWUTS a deprecation period. -serge _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: serue
date: 2008-04-10T17:14:53-00:00

Re: [PATCH 0/3] clone64() and unshare64() system calls
type: item
description: Paul Menage [menage@google.com] wrote: | On Wed, Apr 9, 2008 at 7:38 PM, <sukadev@us.ibm.com> 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 the consensus was that adding a new system call was | better than trying to force extensibility on to the existing | non-extensible system call. There were couple of objections to extensible system calls like sys_indirect() and to Pavel's approach. | | But if we are adding a new system call, why not make the new one | extensible to reduce the need for yet another new call in the future? hypothetically, can we make a variant of clone() extensible to the point of requiring a copy_from_user() ? | | Paul _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Sukadev Bhattiprolu
date: 2008-04-10T18:26:16-00:00

Re: [PATCH 0/3] clone64() and unshare64() system calls
type: item
description: sukadev@us.ibm.com wrote: > | > | I thought that the consensus was that adding a new system call was > | better than trying to force extensibility on to the existing > | non-extensible system call. > > There were couple of objections to extensible system calls like > sys_indirect() and to Pavel's approach. > This is a very different thing, though. sys_indirect is pretty much a mechanism for having a sideband channel -- a second ABI -- into each and every system call, making it extremely hard to analyze what the full set of impact of a specific system call is. Worse, as it was being proposed to have been used, it would have set state variables inside the kernel in a very opaque manner. > | But if we are adding a new system call, why not make the new one > | extensible to reduce the need for yet another new call in the future? > > hypothetically, can we make a variant of clone() extensible to the point > of requiring a copy_from_user() ? The only issue is whether or not it's acceptable from a performance standpoint. clone() is reasonably expensive, though. -hpa _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: hpa
date: 2008-04-10T18:31:41-00:00

Re: [PATCH 1/3] change clone_flags type to u64
type: item
description: Serge E. Hallyn wrote: > Quoting Andi Kleen (andi@firstfloor.org): >> > I guess that was a development rationale. >> >> But what rationale? It just doesn't make much sense to me. >> >> > Most of the namespaces are in >> > use in the container projects like openvz, vserver and probably others >> > and we needed a way to activate the code. >> >> You could just have added it to feature groups over time. >> >> > >> > Not perfect I agree. >> > >> > > With your current strategy are you sure that even 64bit will >> > > be enough in the end? For me it rather looks like you'll >> > > go through those quickly too as more and more of the kernel >> > > is namespaced. >> > >> > well, we're reaching the end. I hope ! devpts is in progress and >> > mq is just waiting for a clone flag. >> >> Are you sure? > > Well for one thing we can take a somewhat different approach to new > clone flags. I.e. we could extend CLONE_NEWIPC to do mq instead of > introducing a new clone flag. The name doesn't have 'sysv' in it, > and globbing all ipc resources together makes some amount of sense. > Similarly has hpa+eric pointed out earlier, suka could use > CLONE_NEWDEV for ptys. If we have net, pid, ipc, devices, that's a > pretty reasonable split imo. Perhaps we tie user to devices and get > rid of CLONE_NEWUSER which I suspect noone is using atm (since only > Dave has run into the CONFIG_USER_SCHED problem). Or not. We could > roll uts into net, and give CLONE_NEWUTS a deprecation period. Please don't. Then we'd need to re-add it in Linux-VServer to support guests where network namespaces aren't used... > -serge -- Daniel Hokka Zakrisson _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Daniel Hokka Zakrisso
date: 2008-04-10T22:13:00-00:00

Re: [PATCH 1/3] change clone_flags type to u64
type: item
description: Quoting Daniel Hokka Zakrisson (daniel@hozac.com): > Serge E. Hallyn wrote: > > Quoting Andi Kleen (andi@firstfloor.org): > >> > I guess that was a development rationale. > >> > >> But what rationale? It just doesn't make much sense to me. > >> > >> > Most of the namespaces are in > >> > use in the container projects like openvz, vserver and probably others > >> > and we needed a way to activate the code. > >> > >> You could just have added it to feature groups over time. > >> > >> > > >> > Not perfect I agree. > >> > > >> > > With your current strategy are you sure that even 64bit will > >> > > be enough in the end? For me it rather looks like you'll > >> > > go through those quickly too as more and more of the kernel > >> > > is namespaced. > >> > > >> > well, we're reaching the end. I hope ! devpts is in progress and > >> > mq is just waiting for a clone flag. > >> > >> Are you sure? > > > > Well for one thing we can take a somewhat different approach to new > > clone flags. I.e. we could extend CLONE_NEWIPC to do mq instead of > > introducing a new clone flag. The name doesn't have 'sysv' in it, > > and globbing all ipc resources together makes some amount of sense. > > Similarly has hpa+eric pointed out earlier, suka could use > > CLONE_NEWDEV for ptys. If we have net, pid, ipc, devices, that's a > > pretty reasonable split imo. Perhaps we tie user to devices and get > > rid of CLONE_NEWUSER which I suspect noone is using atm (since only > > Dave has run into the CONFIG_USER_SCHED problem). Or not. We could > > roll uts into net, and give CLONE_NEWUTS a deprecation period. > > Please don't. Then we'd need to re-add it in Linux-VServer to support > guests where network namespaces aren't used... So these are networked vservers with a different hostname? Just curious, what would be a typical use for these? Anyway then I guess we won't :) Do you have other suggestions for ns clone flags which ought to be combined? Do the rest of what I listed make sense to you? (If…
creator: serue
date: 2008-04-10T22:49:47-00:00

Re: [PATCH 1/3] change clone_flags type to u64
type: item
description: Serge E. Hallyn wrote: > Quoting Daniel Hokka Zakrisson (daniel@hozac.com): >> Serge E. Hallyn wrote: >> > Quoting Andi Kleen (andi@firstfloor.org): >> >> > I guess that was a development rationale. >> >> >> >> But what rationale? It just doesn't make much sense to me. >> >> >> >> > Most of the namespaces are in >> >> > use in the container projects like openvz, vserver and probably >> others >> >> > and we needed a way to activate the code. >> >> >> >> You could just have added it to feature groups over time. >> >> >> >> > >> >> > Not perfect I agree. >> >> > >> >> > > With your current strategy are you sure that even 64bit will >> >> > > be enough in the end? For me it rather looks like you'll >> >> > > go through those quickly too as more and more of the kernel >> >> > > is namespaced. >> >> > >> >> > well, we're reaching the end. I hope ! devpts is in progress and >> >> > mq is just waiting for a clone flag. >> >> >> >> Are you sure? >> > >> > Well for one thing we can take a somewhat different approach to new >> > clone flags. I.e. we could extend CLONE_NEWIPC to do mq instead of >> > introducing a new clone flag. The name doesn't have 'sysv' in it, >> > and globbing all ipc resources together makes some amount of sense. >> > Similarly has hpa+eric pointed out earlier, suka could use >> > CLONE_NEWDEV for ptys. If we have net, pid, ipc, devices, that's a >> > pretty reasonable split imo. Perhaps we tie user to devices and get >> > rid of CLONE_NEWUSER which I suspect noone is using atm (since only >> > Dave has run into the CONFIG_USER_SCHED problem). Or not. We could >> > roll uts into net, and give CLONE_NEWUTS a deprecation period. >> >> Please don't. Then we'd need to re-add it in Linux-VServer to support >> guests where network namespaces aren't used... > > So these are networked vservers with a different hostname? Just > curious, what would be a typical use for these? Layer 3 isolation will continue to be the default for Linux-VServer. > Anyway then I gue…
creator: Daniel Hokka Zakrisso
date: 2008-04-11T08:45:22-00:00