From owner-freebsd-current Fri Jul 6 23:53:35 2001 Delivered-To: freebsd-current@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id AE2D437B407; Fri, 6 Jul 2001 23:53:29 -0700 (PDT) (envelope-from julian@elischer.org) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id BAA36500; Sat, 7 Jul 2001 01:38:16 -0700 (PDT) Message-ID: <3B46B0D0.413DFEA5@elischer.org> Date: Fri, 06 Jul 2001 23:48:48 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Daniel Eischen Cc: Peter Wemm , John Baldwin , current@FreeBSD.ORG, Jason Evans Subject: Re: RFC: Kernel thread system nomenclature. References: Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Daniel Eischen wrote: > > On Fri, 6 Jul 2001, Peter Wemm wrote: > > Julian Elischer wrote: > > > > > > > > > On Fri, 6 Jul 2001, Daniel Eischen wrote: > > > > > > > ->proc-> > > > > ->thrgrp-> > > > > ->thr-> > > > > ->thrctx-> > > > > > > > interesting, though the thrctx maps most closely to a userland thread. > > > there may be many threads running on each #3. > > > > IMHO, I like this less than kse/kseg/ksec/proc. Remember.. these are > > not thread specific.. they can be used to implement aio etc as well. > > > > The KSE paper's definitions of things are pretty clear. If we're not > > going to use something netbsd compatable, then IMHO we should stick to > > the design paper. > > That was my first thought also ;-) > > > The only variation that I think I'd find appealing would be to try > > and make the kseg/ksec difference stand out more. ksegrp/ksectx is less > > likely to be confused at a casual glance. > > > > I'm not really sure that we can use the 'struct lwp' name in a compatable > > way with NetBSD. It would be even worse if we both had 'struct lwp' > > but ours was different to theirs. > > NetBSD doesn't (yet) have an idea of a KSE group. We could just > replace our usage of KSE with LWP: > > proc-> > lwpgrp-> > lwp-> > lwpctx-> > > If NetBSD ever folded in our KSE group support, wouldn't that be the > most compatible? heh.. unlikely as to which (#4 or #3) is the lwp, I think that #4 is the lwp as it is what is put on the sleep queue, and it is what has the kernel stack and context to be restarted. Their equivalent to #3 is a couple of fields in the 'sadata' struct and the 'struct sa' that is passed around. The define a 'per process' upcall location and have a predefined number of stacks passed to the kernel to use on these upcalls. We define a separate preloaded context for each #3 to come back on. They directly schedule all lwps on the run queue, thereby giving them all 'process' weight by default. We do it via #2, which allows us to keep them fairer (if we want). > > > ... etc... > > > > Look for these in particular: > > Index: sys/sys/lwp.h > > Index: sys/sys/proc.h > > Index: sys/sys/sa.h > > Index: sys/sys/savar.h yep looked at them. interesting but predictable if you've read the sa paper. I still don't understand the solaris lwp mode though... > > > > If we dont do similar structure member naming, then there is no point > > using the same structure names as that will just increase the confusion. I think that their lwp and or #4 are really pretty similar in a lot of ways but as you suggest, maybe not similar enough to keep the name the same. > > > > NetBSD's structure is different too.. They have implelemted both > > Solaris-style LWP's and SA's over the top of the same low level entity. > > I like that they use a ucontext_t for storing the context also. > Julian, can we please do the same? We'll probably also need to > use a spare slot in ucontext/mcontext for a flags word (floating > point register validity?). I was always planning to use one, the only difference is where it is stored.. We bypass the need to have a trampoline by knowing in advance where to copy out the ucontext to. We can also report back many blocked calls at once and many completed ones at the same time. The ucontext is stored directly back to user space rather than copied to the stack, and then copied to the thread storage.. The thread storage contains a ucontext. They use it indirectly, while we use it directly. we COULD put it on the stack like they do, but I think our idea is more flexible. ok, so to the names.. #1 proc #2 ksegrp #3 kse #4 ksectx shorter abreviations: ip->p_xxxxx kg->kg_xxxx ke->ke_xxxx kc->kc_xxxx (this is what Jasone proposed on my original suggestions.) but at least this way I won't get grief on it and it also matches what I've already coded :-) > > -- > Dan Eischen -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message