This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
On Tue, Jun 20, 2000 at 01:43:14PM -0700, David Mosberger wrote: > >>>>> On Tue, 20 Jun 2000 11:08:14 -0700, "H . J . Lu" <hjl@valinux.com> said: > > HJ> The current ia64 linuxthreads implementation in my ia64 glibc > HJ> uses clone2 instead of clone. What do we want to do with it? I'd > HJ> like to see a uniform clone interface for linuxthreads across > HJ> all cpus. > > Me too. > > HJ> Any suggestions? > > Here are two possiblities: > > --------------------- > (1) Obsolete the existing clone and replace it with a version that has > the following interface: > > int clone (unsigned long flags, unsigned long sp1, unsigned long sp2); > > This is like the old clone, except for the addition of a second stack > pointer. On IA-64, this second stack pointer would be used to > indicate the initial value for the register backing store. > > --------------------- > (2) Obsolete the existing clone and replace it with a version that has > the following interface: > > int clone (unsigned long flags, > unsigned long stack_base, unsigned long stack_size); > > This is like the old clone, except for the addition of the > "stack_size" argument. Unlike in the old clone, "stack_base" always > points to the lowest virtual address of that has been reserved for > stack use. The stack_size argument specifies the size of the virtual > memory region reserved for the stack. > > Both stack_base and stack_size can be 0: > > - If stack_base is zero, clone() will arrange for the child to use > the same stack pointer(s) as the parent. This is meaningful only > if CLONE_VM is not specified. > > - If stack_size is zero, no memory has been reserved a priori for > stack use, i.e., the stack region is grown dynamically as needed. > Depending on architecture, the stack may grow towards lower virtual > addresses (e.g., x86), higher virtual addresses (e.g., PA-RISC), or > in both directions (e.g., IA-64). > --------------------- > > Unfortunately, both (1) and (2) have their problems. (1) looks > obviously IA-64 specific. sp2 makes no sense on most existing > architectures and why should there be two stack pointers? Perhaps > someone will come up with an architecture that requires three or no > stack pointers at all and then we'd need to go back to the drawing > board again. > > (2) is much more architecture neutral. Unfortunately, the > stack_size==0 case still introduces some architecture dependency as > the growth direction(s) will depend on the platform you're running on. > However, disallowing this case would limit flexibility for IA-64. The > reason is that for IA-64 it probably would be ideal to initialize sp > and bsp to the same value, letting the two stacks grow away from each > other. For this to work best, you'd want stack_base to point to the > middle of a virtual page as that would reduce the number of > stack-related page faults to one (for simple threads). > > Overall, I find (1) unacceptable and (2) the best we've been able to > come up so far. Perhaps others on this list should think about this > issue and see if the can punch any holes into solution (2). If not > (and nobody has a better suggestion), we should broaden the discussion > to include non-IA-64 kernel developers and try implementing it. > > There is another level of clone interface, which is used in linuxthreads. I am more interested in that one. Right now, ia64 use int clone2(int (*fn)(void *arg), void *thread_bottom, size_t stack_size, int flags, void *arg); and the rest uses int clone(int (*fn)(void *arg), void *thread_top, int flags, void *arg); If we all use int clone2(int (*fn)(void *arg), void *thread_bottom, size_t stack_size, int flags, void *arg); that is one solution. All the other CPUs who want thread_top need to use thread_bottom + stack_size to get thread_top in their clone.S. -- H.J. Lu (hjl@gnu.org)
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |