From owner-freebsd-arch Thu Apr 26 10:15:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from filk.iinet.net.au (syncopation-dns.iinet.net.au [203.59.24.29]) by hub.freebsd.org (Postfix) with SMTP id 365B537B71B for ; Thu, 26 Apr 2001 10:15:33 -0700 (PDT) (envelope-from julian@elischer.org) Received: (qmail 13034 invoked by uid 666); 26 Apr 2001 17:18:42 -0000 Received: from i179-136.nv.iinet.net.au (HELO elischer.org) (203.59.179.136) by mail.m.iinet.net.au with SMTP; 26 Apr 2001 17:18:42 -0000 Message-ID: <3AE85776.92D6BD90@elischer.org> Date: Thu, 26 Apr 2001 10:14:30 -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: Alfred Perlstein Cc: Arch@FreeBSD.ORG, Robert Watson , Daniel Eischen , John Baldwin Subject: Re: KSE threading support (first parts) References: <3AE71067.FF4BD029@elischer.org> <20010425110940.L1790@fw.wintelcom.net> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > >  > > Also I've punted on most things to do with signals as we haven't > > really discussed how we want signals to be handled in a KSE world.. > > (ca each KSEG or KSE get individual signals? do we need to > > define a special 'signal' KSE? If so is that all it does? > > > > What happens to the 'u-area'? > > It makes sense that it stays except for struct pcb. Honestly > swapping out the pcbs could be left as something to re-optimize > later, they can take a signifigant amount of space, but nowadays > it's not that big of a deal. so how much work is it to move the pcbs into the proc struct? (and thus into the ksec struct) does anyone see any reason that that would not work? Is thre anything special about having it in the u area? (other than swapping) > > > how do we define a "cur-kse" similar to curproc? > > (do we need one?) > > yes. I will look at seeing if I can do this... > > > presently the processor state is stored all over the place > > when a process is suspended.. > > This needs to be brought together so it can be put into the KSEC. > > Who understands that stuff? > > That's your job. Refer to Jason Evans if he's available. gee thanks.. I don't really have a grip on all the ways that traps etc can need to save context.. I REALLY don't get the floating point context stuff. Some state is stored on the user tack, some on the kernel stack and some in the pcb (and maybe some in the proc struct.) to complicate thigs a little: Some things such as segment registers may be "per KSE" where normal registers are "per KSEC". > > You should also ask John Baldwin about proc locking as this > stuff is definetly going to require locking in order to function > properly. > > > Some of the next steps would be: > > 1/ figure out what we want for signals etc.. > > Afaik Solaris tried many different ways to propogate signals across > thier lwps, afaik they found the task so complex and so hard to get > right that the latest implementation makes one lwp the signal target. > > Most likely then signals would be still be in struct proc or the > initial kse. I was thinking about this.. I think that signals should be delivered to the UTS and it should be up to the UTS to decide what to do about it.. In that case they would be delivered to the first available kernel->user boundary crossing for that process. > > > 2/ get the contexts actually stored in the KSEC structure > > when a proces is suspended. (instead of some strange pcb in funny memory > > near the u area) > > huh? I mean that I get a headach when looking at where all the registers, segment registers etc. are all stored as it looks as if it's rather mixed up.. It'd be nice if it were all in one place, and the KSEC is where that should be. > > > 3/ Set up the linkages between these structures, and > > 4/ start using 'kse' instead of 'proc' in a bunch of places > > and using the linkages to find the appropriate other > > structures when needed. > > 5/ Add code to make new KSEs so that the 1:1 Mapping is no longer > > true. > > 6/ Add syscalls to start making KSEs other than the one that > > is built into the process. > > 7/ start making upcalls > > > > ok, when are you going to have these done? :) > > One other question, have you looked at the recent lwp/kse support added > to NetBSD? Is there anything to learn/avoid? I've had only a small look so far sorting hte wheat from the chaff is a hard task and of course it requires understanding a lot that I'm not too solid on. (e.g. UVM). > > -Alfred -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message