From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 1 Sep 2000 19:34:14 -0400 From: Alexander Viro To: 9fans@cse.psu.edu Subject: Re: [9fans] FreeBSD 4.0 / Plan9 3rd ed. In-Reply-To: <200009012258.SAA02080@cse.psu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Topicbox-Message-UUID: 021b3d4c-eac9-11e9-9e20-41e7f4b1d025 On Fri, 1 Sep 2000 forsyth@caldo.demon.co.uk wrote: > >>thread==process. There is a rfork() equivalent (clone(2)) and model is > >>exactly the same as on Plan 9 (process as a set of components that can be > >>shared between several processes; fork() as a special case of more generic > > no it is not equivalent. > would that it were. You can have multiple stacks. If anything, work by ESP is better than by TSS. "Current stack pointer" makes sense on most of architectures. TSS doesn't. Lack of stack-splitting is not an accident - stack is not a magic object. It's just an anonymous mapping with MAP_GROWSDOWN in flags. OK, so it's time for patch to mmap.2. Omitted piece being: MAP_GROWSDOWN created mapping will behave like a stack - grow downwards upon pagefaults. Stacks are not special in any respects - they are nothing but anonymous mappings that can grow. Sorry. That makes my original reaction somewhat over-the-top. Umhm... OK, I'll look through the thing (drawterm, that is) and try to see what can be done. Anyway, TSS hack is doomed - it's not going to work on 2.4. We used to allocate a separate TSS for each task, but that essentially forced a TLB flush upon every context switch. And it hurts a lot. Current kernel has a TSS per CPU and does needed updates by hands - it turned out to be faster than jump on TSS. So something has to be done anyway. Yes, 2.4 is not released yet, but you can be 100% sure that this change will not be reverted.