From owner-freebsd-arch Sun Nov 21 5:41:41 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 510EB14CF9 for ; Sun, 21 Nov 1999 05:41:37 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id OAA26203 for ; Sun, 21 Nov 1999 14:41:36 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA13443 for freebsd-arch@freebsd.org; Sun, 21 Nov 1999 14:41:36 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 1AF1A14CF9 for ; Sun, 21 Nov 1999 05:41:27 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt44.pcnet.net [206.105.29.118]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id IAA22389; Sun, 21 Nov 1999 08:41:27 -0500 (EST) Message-ID: <3837F679.BCEC1312@vigrid.com> Date: Sun, 21 Nov 1999 08:41:13 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Threads References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > > On Sun, 21 Nov 1999, Daniel M. Eischen wrote: > > I'd say that all upcalls are _not_ necessarily the result of a prior downcall. > > A subprocess that is preempted should force an upcall on the next available > > subprocess. > > > > I assume the UTS will install a set of upcall entry points to handle > > async notification events. We just need to define what events are passed > > between the UTS and the kernel. > > What better way to install them than to do a syscall down? > All the kernel needs to know is that it sets some stuff, pre-empts the > present KSE and runs another. I assumed that the UTS would have to perform a system call to install the UTS upcall entry point(s). > > > > > > My suggested idea is that the UTS does a blocking syscall > > > that notifies the kernel that it is now capable of receiving upcalls, > > > and the kermnel duplicates that KSE and stack and returns on a new > > > KSE. The UTS knows when it returns, to immediatly allocate a new stack > > > and thread (probably already allocated and waiting before the downcall > > > actually) and switches to the new stack (or maybe the downcall was > > > already done on the new one in which case it restarts the old thread. In > > > any case the thread that did the downcall is the nominated handler of > > > async events. > > > > That's OK, but why not use a ucontext passed in with a new system > > call? Make the UTS supply ucontexts (made with makecontext) for event > > notifications also. > > The UTS requires a KSE to run in, otherwise it has no CPU > so there has to be one reserved for the task I think. (maybe not) That's why you hand the kernel (at UTS initialization time) premade contexts for handling async notification. > That reminds me that all the returning of ucontexts around the place is > one of the reasons why a new callgate would be a good idea. > > I'm not that fussed about it but it just seems to me that the information > being passed back and forth is DIFFERENT than that being passed back and > forth in the non-threaded world. True, but it is passed back and forth in NEW ways. It doesn't affect non-MT system calls. > I don't want to get into the trap of deciding that we are doing > everything the "scheduler activations way", because we may be doing some > things quite different. Granted, but let's also not let NIH have any impact on what we decide ;-) > My philosophy is that things should be precomputed early and when they are > required they are just 'used'. Agreed. > Here is a first half-thought out run-threough of how an IO syscall blocks > and the UTS gets notified. > --------------------- > > in a syscall, > > the thread loads some values on the user stack > > the thread calls the ULT syscall handler > > The ULT allocates an IO status block > > the ULT sycall handler calls the new callgate > > The callgate causes the user stack to be saved and registers to be saved, > etc. the kernel stack is activated. > > a flag (a) is set. > > a setjmp() is done and saved at (b) and the stack is marked at (c) > > syscall is processed...... This seems overly complicated. What if the system call doesn't block? You've just done all the above for nothing. > > at some point a tsleep() is hit. > > it notices that flag (a) is set, and > > grabs a new KSE from the KSE cache. > > copies the kernel stack up to to (c) to that on the new KSE > > copies the Async KSE's stack to (c) onto the old KSE Why not just context switch to the cached context beginning at the UTS defined async notification entry points? > > hacks the contents of (b) to fit the new KSE > > does a longjmp().. We are now effectively the thread returning > > Set 'incomplete' into the IO status block. > > * some stack munging thing done here I am not sure about * > > returns to the UTS indicating thread blocked > > * some user stack munging thing done here I am not sure about * > > UTS suspends thread > > UTS schedules new thread > > ***Time passes**** > > down in the bowels of the system the original KSE unblocks.. > > control passes back up to the top of the kernel. > > It sets the status of the IO as it would have, then returns, > > and finds itself in the ASYNC entrypoint of the UTS. (or maybe on the > original return path.. depends on state of stack) > > the UTS notices that the IO has completed, and schedules the original > thread to continue. The KSE then runs that thread until the UTS says > otherwise. I think the above approach is too complicated and can be simplified to eliminate the overhead in setting up the system call. Here's my thoughts. At thread library intialization time, the UTS makes contexts for async notification event handlers. Contexts are in the form of a return from a trap to the kernel. My idea is to use setcontext(2) and makecontext(2) to create the contexts. We may need to give the kernel additional user stacks, but that isn't clear yet. Flag (async_notify) is set in the calling process. A thread makes a system call and it blocks; tsleep is hit. (Notice that nothing needs to be done differently in order to make a system call.) It notices that flag (async_notify) is set. It grabs a new KSE (kernel register save area and kernel stack) from the KSE cache, and places the current KSE in the sleep queue. A unique ID is created to identify the blocked KSE (integer ID?). This unique ID, along with an ID that identifies the event and any other necessary information, is copied to the top of the user stack of the relevent async notification event handler. The parameters to the UTS event handler are setup to point to the top of the stack. The kernel returns directly to the UTS entry point on the predefined context/user stack, just as if a setcontext(2) was performed. The UTS knows what thread was running and marks it as blocked in the kernel and saves the unique KSE ID. The UTS schedules a new thread. ***Time passes*** The original KSE unblocks. It is added to the current processes unblocked KSE list. When the process runs again (or the next subprocess, since you can have more than 1 cooperating processes), a new KSE is allocated and context is set to the relevent UTS event handler. Event information is copied out to the top of the predefined user stack, parameters set accordingly, and the kernel returns to the UTS event handler. If a thread was preempted for the notification, then its context (just like getcontext(2)) is also copied out to the UTS event handler user stack. The UTS event handler receives notification that the thread that _was_ running on this process was preempted for this notification, and that other KSEs have unblocked in the kernel. The UTS marks the unblocked threads has active. The context of the thread that was running can be resumed with setcontext(2) or hacked into a jmp_buf and resumed with longjmp. The UTS resumes the blocked thread in one of two ways. A new system call to resume the KSE identified by it's unique ID is one way. The other way is to have the kernel copy the context of the unblocked KSE out to the UTS event handler. It can be resumed with setcontext(2). Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 21 17: 9:54 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 9340C14E3F for ; Sun, 21 Nov 1999 17:09:52 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id CAA02051 for ; Mon, 22 Nov 1999 02:09:51 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA16297 for freebsd-arch@freebsd.org; Mon, 22 Nov 1999 02:09:51 +0100 (MET) Received: from fgwmail5.fujitsu.co.jp (fgwmail5.fujitsu.co.jp [192.51.44.35]) by hub.freebsd.org (Postfix) with ESMTP id 9697514ED5; Sun, 21 Nov 1999 17:08:46 -0800 (PST) (envelope-from shin@nd.net.fujitsu.co.jp) Received: from m1.gw.fujitsu.co.jp by fgwmail5.fujitsu.co.jp (8.9.3/3.7W-MX9911-Fujitsu Gateway) id KAA17733; Mon, 22 Nov 1999 10:08:45 +0900 (JST) Received: from chisato.nd.net.fujitsu.co.jp by m1.gw.fujitsu.co.jp (8.9.3/3.7W-9911-Fujitsu Domain Master) id KAA17793; Mon, 22 Nov 1999 10:08:44 +0900 (JST) Received: from localhost (dhcp7186.nd.net.fujitsu.co.jp [10.18.7.186]) by chisato.nd.net.fujitsu.co.jp (8.8.5+2.7Wbeta5/3.3W8chisato-970826) with ESMTP id KAA11100; Mon, 22 Nov 1999 10:08:43 +0900 (JST) To: freebsd-arch@freebsd.org Cc: cvs-committers@freebsd.org Subject: Re: [Solicite review for KAME 2nd patch](netinet6 basic part addtion) In-Reply-To: <19991117032655J.shin@nd.net.fujitsu.co.jp> References: <19991112152848.A90019@fasterix.frmug.org> <19991113012530.A62524@fasterix.frmug.org> <19991117032655J.shin@nd.net.fujitsu.co.jp> X-Mailer: Mew version 1.94 on Emacs 20.4 / Mule 4.0 (HANANOEN) X-Prom-Mew: Prom-Mew 1.93.4 (procmail reader for Mew) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19991122100858P.shin@nd.net.fujitsu.co.jp> Date: Mon, 22 Nov 1999 10:08:58 +0900 From: Yoshinobu Inoue X-Dispatcher: imput version 990905(IM130) Lines: 14 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > New patches are placed below. > > http://paradise.kame.net/v6proxy/diana2/shin/work/freebsd/kame-into-fbc.html By the way, do people have no more comments? Already 5 day passed after the revised patch was made, and I would like to commit it soon, after I cvs update the sys tree once more and check the kernel build. (I might wait too long. Sorry I don't know how long should I wait for comments yet. But this time, I thought I should wait longer because I touched common inpcb structure.) Yoshinobu Inoue To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 21 17:28: 5 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id DBEF81521C for ; Sun, 21 Nov 1999 17:27:44 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id CAA03795 for ; Mon, 22 Nov 1999 02:27:43 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA16517 for freebsd-arch@freebsd.org; Mon, 22 Nov 1999 02:27:43 +0100 (MET) Received: from canonware.com (canonware.com [207.20.242.18]) by hub.freebsd.org (Postfix) with SMTP id 408B6152A7 for ; Sun, 21 Nov 1999 17:27:17 -0800 (PST) (envelope-from jasone@canonware.com) Received: (qmail 1973 invoked by uid 1001); 22 Nov 1999 01:27:11 -0000 Date: Sun, 21 Nov 1999 17:27:11 -0800 From: Jason Evans To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: New development scheme (was Re: Core responsibilities) Message-ID: <19991121172711.A301@sturm.canonware.com> References: <19991120190750.D11515@sturm.canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from julian@whistle.com on Sat, Nov 20, 1999 at 07:24:29PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Nov 20, 1999 at 07:24:29PM -0800, Julian Elischer wrote: > I wonder if we can try a new development scheme? > You have amandate to do almost anythign to make threads work.. > there are a lot of people who would like to help you work on this.. > Even a full time job doesn't give enough time for doing this all on your > own completely in isolation. > > How about if you coem on as "main threads guy and thread team leader"? > Take over the discussion lead, and I know I'd be willing to take on > specific tasks.. e.g. "split the proc struct into proc and thread parts" > "get us a new call-gate for the threaded syscalls" "make a skelaton in the > sources to compile a version of libc-R using the new callgate" > > "Fix PS to show all threads and not just the main one" > "fix /proc for the new world" > etc.etc. > > there are lots of people who know how to do these bits > And tehy will hapily do these thongs and feed you back patches > if you can use you new 'Thread-czar' position to organise it. Well, I think I'll have it all done by next week, so... =) Seriously though, this is absolutely what I hope will happen. I want to see much better threads support go into 4.0, and that's much more likely to happen if this is a group effort. Since threads is my main focus for now, I have no problem with doing a lot of the associated administrative foo that needs to happen in organizing our efforts. I've been making up a list of specific jobs to be done during implementation that I'll send out for review soon, but I'm hoping we can nail down the the upcall mechanism and motivations a little better first, so that we can get on to an agreed plan of attack for implementation. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 21 17:30:27 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id E60E71588D for ; Sun, 21 Nov 1999 17:30:08 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id CAA04042 for ; Mon, 22 Nov 1999 02:30:07 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA16575 for freebsd-arch@freebsd.org; Mon, 22 Nov 1999 02:30:07 +0100 (MET) Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id DEED614C88; Sun, 21 Nov 1999 17:29:49 -0800 (PST) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id KAA02164; Sun, 21 Nov 1999 10:35:04 -0800 (PST) Message-Id: <199911211835.KAA02164@implode.root.com> To: Yoshinobu Inoue Cc: freebsd-arch@freebsd.org, cvs-committers@freebsd.org Subject: Re: [Solicite review for KAME 2nd patch](netinet6 basic part addtion) In-reply-to: Your message of "Mon, 22 Nov 1999 10:08:58 +0900." <19991122100858P.shin@nd.net.fujitsu.co.jp> From: David Greenman Reply-To: dg@root.com Date: Sun, 21 Nov 1999 10:35:04 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> New patches are placed below. >> >> http://paradise.kame.net/v6proxy/diana2/shin/work/freebsd/kame-into-fbc.html > >By the way, do people have no more comments? >Already 5 day passed after the revised patch was made, and I >would like to commit it soon, after I cvs update the sys tree >once more and check the kernel build. > >(I might wait too long. Sorry I don't know how long should I >wait for comments yet. But this time, I thought I should wait >longer because I touched common inpcb structure.) Looks good. Please proceed. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 22 16:34:53 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 9C34114CA5 for ; Mon, 22 Nov 1999 16:34:51 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id BAA23309 for ; Tue, 23 Nov 1999 01:34:47 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA23152 for freebsd-arch@freebsd.org; Tue, 23 Nov 1999 01:34:47 +0100 (MET) Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id D082D14F06 for ; Mon, 22 Nov 1999 16:33:55 -0800 (PST) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost [127.0.0.1]) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id TAA40550; Mon, 22 Nov 1999 19:30:45 -0500 (EST) (envelope-from chuckr@picnic.mat.net) Date: Mon, 22 Nov 1999 19:30:45 -0500 (EST) From: Chuck Robey To: Julian Elischer Cc: Nate Williams , "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 20 Nov 1999, Julian Elischer wrote: > > > On Sat, 20 Nov 1999, Nate Williams wrote: > > > > New calls must be able to return and say > > > "hey it's not me returnuing, but actually a new KSE, " > > > > Not only that, but you need a way for it to be 'aborted' out and have it > > cleanup as it goes. I suspect that this will require re-writing a large > > number of syscalls with threading in mind, and leaving the 'old' calls > > in place will allow more flexibility as things change. > > > > I could envision the 'old' calls going away at some point as the new > > calls get completely fleshed out and tested, to be replaced with simple > > wrappers for the threaded calls. > > > > Maybe in the libraries, but we will need to keep the old syscalls in the > kernel effectively forever. (for old binaries) It's not much of a cost.. > (look at linux emulation). If I can ask one question, how will we cover things like errno, which we'll want to be in thread-specific storage, but not on the stack (I think)? ---------------------------------------------------------------------------- Chuck Robey | Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770 | I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 22 19:59:14 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2855314BE7 for ; Mon, 22 Nov 1999 19:59:11 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA00247 for ; Tue, 23 Nov 1999 04:59:01 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA24249 for freebsd-arch@freebsd.org; Tue, 23 Nov 1999 04:58:57 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 0BC9E15086 for ; Mon, 22 Nov 1999 19:58:49 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id TAA42358; Mon, 22 Nov 1999 19:57:56 -0800 (PST) Date: Mon, 22 Nov 1999 19:57:56 -0800 (PST) From: Julian Elischer To: Chuck Robey Cc: Nate Williams , "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 22 Nov 1999, Chuck Robey wrote: > On Sat, 20 Nov 1999, Julian Elischer wrote: > > > > > > > On Sat, 20 Nov 1999, Nate Williams wrote: > > > > > > New calls must be able to return and say > > > > "hey it's not me returnuing, but actually a new KSE, " > > > > > > Not only that, but you need a way for it to be 'aborted' out and have it > > > cleanup as it goes. I suspect that this will require re-writing a large > > > number of syscalls with threading in mind, and leaving the 'old' calls > > > in place will allow more flexibility as things change. > > > > > > I could envision the 'old' calls going away at some point as the new > > > calls get completely fleshed out and tested, to be replaced with simple > > > wrappers for the threaded calls. > > > > > > > Maybe in the libraries, but we will need to keep the old syscalls in the > > kernel effectively forever. (for old binaries) It's not much of a cost.. > > (look at linux emulation). > > If I can ask one question, how will we cover things like errno, which > we'll want to be in thread-specific storage, but not on the stack (I > think)? > I think the usual errno hack is just fine.. we've already cleaned out other occurances of errno from a lot of code. #define errno (*threadspecific->errnum) or #define errno (errnum[thread_ID]) Actually there is no reason errno can't be on your local stack, in th einitial frame, as long as you have a way to reference it. > > ---------------------------------------------------------------------------- > Chuck Robey | Interests include C programming, Electronics, > 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. > Greenbelt, MD 20770 | I run picnic.mat.net: FreeBSD-current(i386) and > (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) > ---------------------------------------------------------------------------- > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 22 20:13:27 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 6CDDE14A0E for ; Mon, 22 Nov 1999 20:13:23 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id FAA00405 for ; Tue, 23 Nov 1999 05:13:15 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA24310 for freebsd-arch@freebsd.org; Tue, 23 Nov 1999 05:13:15 +0100 (MET) Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id B5E2614A0E for ; Mon, 22 Nov 1999 20:12:47 -0800 (PST) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost [127.0.0.1]) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id XAA70655; Mon, 22 Nov 1999 23:12:12 -0500 (EST) (envelope-from chuckr@picnic.mat.net) Date: Mon, 22 Nov 1999 23:12:12 -0500 (EST) From: Chuck Robey To: Julian Elischer Cc: Nate Williams , "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 22 Nov 1999, Julian Elischer wrote: > I think the usual errno hack is just fine.. > we've already cleaned out other occurances of errno from a lot of code. > > #define errno (*threadspecific->errnum) > or > #define errno (errnum[thread_ID]) > > Actually there is no reason errno can't be on your local stack, in th > einitial frame, as long as you have a way to reference it. OK. The question came to my mind when reading the Sun whitepaper, for thread-specific static storage. They did it via the compiler, and seeing as that would be hard for us, I was curious how we'd do it. I was wondering if it might be done via the thread context block. In light of the fact that new threads are dynamically created, I'm not too sure how you'd do your second suggestion above, but the first one seems easily doable. I want to ask a couple more questions, about the scheduler, procs and KSE's. For general questions, would maybe another list be better? ---------------------------------------------------------------------------- Chuck Robey | Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770 | I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 22 20:39:53 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 6F8E615040 for ; Mon, 22 Nov 1999 20:39:48 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id FAA00684 for ; Tue, 23 Nov 1999 05:39:19 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA24446 for freebsd-arch@freebsd.org; Tue, 23 Nov 1999 05:39:18 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id BC84415040; Mon, 22 Nov 1999 20:38:52 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id UAA44174; Mon, 22 Nov 1999 20:38:33 -0800 (PST) Date: Mon, 22 Nov 1999 20:38:30 -0800 (PST) From: Julian Elischer To: Chuck Robey Cc: Nate Williams , "Daniel M. Eischen" , freebsd-arch@freebsd.org, jasone@freebsd.org Subject: Re: Threads In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 22 Nov 1999, Chuck Robey wrote: > > I want to ask a couple more questions, about the scheduler, procs and > KSE's. For general questions, would maybe another list be better? no, -arch is the right place, unless jason evans decides that it should move somewhere else. julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 22 21:42:19 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 33A171501A for ; Mon, 22 Nov 1999 21:42:06 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id GAA01266 for ; Tue, 23 Nov 1999 06:41:21 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA24706 for freebsd-arch@freebsd.org; Tue, 23 Nov 1999 06:41:21 +0100 (MET) Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 7246214FEE; Mon, 22 Nov 1999 21:41:05 -0800 (PST) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost [127.0.0.1]) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id AAA79488; Tue, 23 Nov 1999 00:40:28 -0500 (EST) (envelope-from chuckr@picnic.mat.net) Date: Tue, 23 Nov 1999 00:40:27 -0500 (EST) From: Chuck Robey To: Julian Elischer Cc: Nate Williams , "Daniel M. Eischen" , freebsd-arch@freebsd.org, jasone@freebsd.org Subject: Re: Threads In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 22 Nov 1999, Julian Elischer wrote: > > > On Mon, 22 Nov 1999, Chuck Robey wrote: > > > > I want to ask a couple more questions, about the scheduler, procs and > > KSE's. For general questions, would maybe another list be better? > > no, -arch is the right place, unless jason evans decides that it should > move somewhere else. It seems to me that we're talking about, basically, changing the scheduler from being process-centric to being KSE-centric, right? I think that means that, excepting possible per-process limits, the scheduler wouldn't care what process was up, and it would be keeping KSE run-lists, wait-lists, etc, right? I'm wondering if there might possibly be some way to preserve some level of simplicity by keeping ksid'd like we keep pid's now, so that things that juggle a 32 bit entity keep on doing that, although perhaps under another name. > > > julian > > ---------------------------------------------------------------------------- Chuck Robey | Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770 | I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 23 4:22: 4 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 926E014D0E for ; Tue, 23 Nov 1999 04:21:55 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id NAA09091 for ; Tue, 23 Nov 1999 13:21:30 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA25809 for freebsd-arch@freebsd.org; Tue, 23 Nov 1999 13:21:29 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 0411C150AA; Tue, 23 Nov 1999 04:21:17 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id HAA07292; Tue, 23 Nov 1999 07:20:01 -0500 (EST) Date: Tue, 23 Nov 1999 07:19:54 -0500 (EST) From: Daniel Eischen To: Chuck Robey Cc: Julian Elischer , Nate Williams , "Daniel M. Eischen" , freebsd-arch@freebsd.org, jasone@freebsd.org Subject: Re: Threads In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 23 Nov 1999, Chuck Robey wrote: > It seems to me that we're talking about, basically, changing the scheduler > from being process-centric to being KSE-centric, right? I think that > means that, excepting possible per-process limits, the scheduler wouldn't > care what process was up, and it would be keeping KSE run-lists, > wait-lists, etc, right? I think the sleep queues need to be KSEs, and perhaps someday they'll become per-mutex or condvar queues :-). I think the run queue has to remain process (or kernel thread) oriented. The KSE run-list would be hung off each process. > I'm wondering if there might possibly be some way to preserve some level > of simplicity by keeping ksid'd like we keep pid's now, so that things > that juggle a 32 bit entity keep on doing that, although perhaps under > another name. I think you're basically right in keeping things simple. I think that a non-MT process should be equivalent to a MT process. The non-MT process has only one co-operating process (itself) and one KSE. Whenever the non-MT process blocks in the kernel, there are no more available KSEs, so another process is scheduled. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 23 5:26:16 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 6FA8014D7C for ; Tue, 23 Nov 1999 05:26:11 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id OAA10347 for ; Tue, 23 Nov 1999 14:26:07 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA26091 for freebsd-arch@freebsd.org; Tue, 23 Nov 1999 14:26:06 +0100 (MET) Received: from post.mail.nl.demon.net (post-11.mail.nl.demon.net [194.159.73.21]) by hub.freebsd.org (Postfix) with ESMTP id 32ED714E14 for ; Tue, 23 Nov 1999 05:25:46 -0800 (PST) (envelope-from marcel@scc.nl) Received: from [212.238.132.94] (helo=scones.sup.scc.nl) by post.mail.nl.demon.net with esmtp (Exim 2.12 #1) id 11qFxA-0003tu-00 for freebsd-arch@freebsd.org; Tue, 23 Nov 1999 13:25:52 +0000 Received: from scc.nl (scones.sup.scc.nl [192.168.2.4]) by scones.sup.scc.nl (8.9.3/8.9.3) with ESMTP id OAA84752 for ; Tue, 23 Nov 1999 14:25:30 +0100 (CET) (envelope-from marcel@scc.nl) Message-ID: <383A95CA.AC00E8B@scc.nl> Date: Tue, 23 Nov 1999 14:25:30 +0100 From: Marcel Moolenaar Organization: SCC vof X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Cross-building (was: cross compilation goals) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [the patches in this posting are for illustration purposes only. They once worked, but have been lying around for too long to be safely used as is. Also, spacing may be corrupted due to cut-n-paste and line-breaking] To continue where we left off I want to discuss some changes to gcc. To make sure nobody gets the wrong impression: The changes are only to the FreeBSD specific additions or modifications! The reason for these changes are: o Remove old code that has lost its function, o Introduce more (compile time) flexibility, o Bug fixes. Index: 1. Remove support for /etc/objformat 2. Make hardcoded paths PREFIX related Your comments? 1. Remove support for /etc/objformat ------------------------------------ The reasons for this change are: o /etc/objformat does not exist anymore, o It interferes with cross-compilation. The last bullet is explained by the following situation: Assume we want to (source) upgrade from 3.0-RELEASE to -current. The machine has /etc/objformat which contains OBJFORMAT=aout... The functionality lost by this removal is nicely covered by the ability to specify OBJFORMAT in the environment. patch: Index: contrib/egcs/gcc/gcc.c =================================================================== RCS file: /home/ncvs/src/contrib/egcs/gcc/gcc.c,v retrieving revision 1.4 diff -u -r1.4 gcc.c --- gcc.c 1999/09/13 15:41:42 1.4 +++ gcc.c 1999/11/03 17:07:53 @@ -2718,26 +2718,7 @@ } #if defined(FREEBSD_NATIVE) && defined(__i386__) - { - /* first hint is /etc/objformat */ - FILE *fp = fopen("/etc/objformat", "r"); - if (fp) { - char buf[1024]; - buf[1023] = '\0'; - while (fgets(buf, sizeof(buf) - 1, fp) != NULL) { - i = strlen(buf); - if (buf[i - 1] == '\n') - buf[i - 1] = '\0'; - if (strcmp(buf, "OBJFORMAT=aout") == 0) - objformat_aout = 1; - else if (strcmp(buf, "OBJFORMAT=elf") == 0) - objformat_aout = 0; - else - fprintf(stderr, "Unrecognized line in /etc/objformat: %s\n", buf); - } - fclose(fp); - } - /* but the user $OBJFORMAT overrides system default */ + /* the user $OBJFORMAT overrides system default */ temp = getenv("OBJFORMAT"); if (temp) { if (strcmp(temp, "aout") == 0) @@ -2747,7 +2728,6 @@ else fprintf(stderr, "Unrecognized value of $OBJFORMAT: %s\n", temp); } - } #endif 2. Make hardcoded paths PREFIX related -------------------------------------- The reasons for this change are: o The ability to "rebase" the compiler toolset, o To simplify cross-compilation. All FreeBSD specific paths are hardcoded in gcc itself. Instead of having "/usr/libexec/elf/" in gcc I suggest something like PREFIX"/libexec/elf/". This allows for compile-time control over where gcc should look for backend tools. This simplifies a cross-world, because the compiler that's build during tool-building can be based in the object tree and can be used without any special treatment other than setting the PATH to point to the cross-compiler. The idea was taken from cc/cc_drv/Makefile where the same thing happens. I just applied it to gcc at large. The patch also contains some bug fixes. For example: - add_prefix (&exec_prefixes, "/usr/libexec", "GCC", + add_prefix (&exec_prefixes, PREFIX"/libexec/", "GCC", or - add_prefix (&exec_prefixes, "/usr/bin", "GCC", + add_prefix (&exec_prefixes, PREFIX"/bin/", "GCC", "exec_prefixes" *must* be terminated by slashes to be effective. The reason why it did work was because we had a second "/usr/libexec/" with the terminating slash as can be seen with: scones% gcc --print-search-dirs install: /usr/libexec/(null) programs: /usr/libexec/elf/:/usr/libexec:/usr/bin:/usr/libexec/ libraries: /usr/libdata/gcc/:/usr/libexec/:/usr/ccs/lib/:/usr/lib/ patch: Index: contrib/egcs/gcc/gcc.c =================================================================== RCS file: /home/ncvs/src/contrib/egcs/gcc/gcc.c,v retrieving revision 1.4 diff -u -r1.4 gcc.c --- gcc.c 1999/09/13 15:41:42 1.4 +++ gcc.c 1999/11/03 17:07:53 @@ -3104,17 +3084,17 @@ #if defined(__i386__) if (objformat_aout) { n_switches++; /* add implied -maout */ - add_prefix (&exec_prefixes, "/usr/libexec/aout/", "BINUTILS", + add_prefix (&exec_prefixes, PREFIX"/libexec/aout/", "BINUTILS", 0, 0, NULL_PTR); } else - add_prefix (&exec_prefixes, "/usr/libexec/elf/", "BINUTILS", + add_prefix (&exec_prefixes, PREFIX"/libexec/elf/", "BINUTILS", 0, 0, NULL_PTR); #endif - add_prefix (&exec_prefixes, "/usr/libexec", "GCC", + add_prefix (&exec_prefixes, PREFIX"/libexec/", "GCC", 0, 0, warn_std_ptr); - add_prefix (&exec_prefixes, "/usr/bin", "GCC", + add_prefix (&exec_prefixes, PREFIX"/bin/", "GCC", 0, 0, warn_std_ptr); - add_prefix (&startfile_prefixes, "/usr/libdata/gcc/", "BINUTILS", + add_prefix (&startfile_prefixes, PREFIX"/libdata/gcc/", "BINUTILS", 0, 0, warn_std_ptr); #else /* not FREEBSD_NATIVE */ #ifndef OS2 Index: gnu/usr.bin/cc/Makefile.inc =================================================================== RCS file: /home/ncvs/src/gnu/usr.bin/cc/Makefile.inc,v retrieving revision 1.39 diff -u -r1.39 Makefile.inc --- Makefile.inc 1999/10/12 20:22:38 1.39 +++ Makefile.inc 1999/11/03 11:12:42 @@ -29,16 +29,16 @@ CFLAGS+= -DFREEBSD_NATIVE -DHAVE_CONFIG_H CFLAGS+= -DDEFAULT_TARGET_VERSION=\"$(version)\" CFLAGS+= -DDEFAULT_TARGET_MACHINE=\"$(target)\" +CFLAGS+= -DPREFIX=\"${DESTDIR}/usr\" .if defined(USE_EGCS_HAIFA) CFLAGS+= -DHAIFA Index: gnu/usr.bin/cc/cc_drv/Makefile =================================================================== RCS file: /home/ncvs/src/gnu/usr.bin/cc/cc_drv/Makefile,v retrieving revision 1.4 diff -u -r1.4 Makefile --- Makefile 1999/08/27 23:35:15 1.4 +++ Makefile 1999/11/03 11:13:02 @@ -6,7 +6,6 @@ SRCS= multilib.h choose-temp.c obstack.c prefix.c pexecute.c version.c -CFLAGS+= -DPREFIX=\"/usr\" CFLAGS+= -DIN_GCC LIB= cc_drv Index: gnu/usr.bin/cc/cc_tools/freebsd-native.h =================================================================== RCS file: /home/ncvs/src/gnu/usr.bin/cc/cc_tools/freebsd-native.h,v retrieving revision 1.3 diff -u -r1.3 freebsd-native.h --- freebsd-native.h 1999/08/27 23:35:17 1.3 +++ freebsd-native.h 1999/11/03 16:56:58 @@ -6,8 +6,8 @@ /* Look for the include files in the system-defined places. */ -#define GPLUSPLUS_INCLUDE_DIR "/usr/include/g++" -#define GCC_INCLUDE_DIR "/usr/include" +#define GPLUSPLUS_INCLUDE_DIR PREFIX"/include/g++" +#define GCC_INCLUDE_DIR PREFIX"/include" /* Now that GCC knows what the include path applies to, put the G++ one first. C++ can now have include files that override the default C ones. */ @@ -26,15 +26,15 @@ #undef TOOLDIR_BASE_PREFIX #undef MD_EXEC_PREFIX -#define STANDARD_EXEC_PREFIX "/usr/libexec/" -#define TOOLDIR_BASE_PREFIX "/usr/libexec/" -#define MD_EXEC_PREFIX "/usr/libexec/" +#define STANDARD_EXEC_PREFIX PREFIX"/libexec/" +#define TOOLDIR_BASE_PREFIX PREFIX"/libexec/" +#define MD_EXEC_PREFIX PREFIX"/libexec/" /* Under FreeBSD, the normal location of the various *crt*.o files is the /usr/lib directory. */ #undef STANDARD_STARTFILE_PREFIX -#define STANDARD_STARTFILE_PREFIX "/usr/lib/" +#define STANDARD_STARTFILE_PREFIX PREFIX"/lib/" /* FreeBSD is 4.4BSD derived */ #define bsd4_4 -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 23 5:49:50 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3F8DA150C9 for ; Tue, 23 Nov 1999 05:49:42 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id OAA10770 for ; Tue, 23 Nov 1999 14:49:24 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA26173 for freebsd-arch@freebsd.org; Tue, 23 Nov 1999 14:49:23 +0100 (MET) Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id EC715150C9 for ; Tue, 23 Nov 1999 05:49:04 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id D962E1CC8; Tue, 23 Nov 1999 21:49:00 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: Marcel Moolenaar Cc: freebsd-arch@freebsd.org Subject: Re: Cross-building (was: cross compilation goals) In-Reply-To: Message from Marcel Moolenaar of "Tue, 23 Nov 1999 14:25:30 +0100." <383A95CA.AC00E8B@scc.nl> Date: Tue, 23 Nov 1999 21:49:00 +0800 From: Peter Wemm Message-Id: <19991123134900.D962E1CC8@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Marcel Moolenaar wrote: > 1. Remove support for /etc/objformat > ------------------------------------ > > The reasons for this change are: > o /etc/objformat does not exist anymore, > o It interferes with cross-compilation. > > The last bullet is explained by the following situation: Assume we want > to (source) upgrade from 3.0-RELEASE to -current. The machine has > /etc/objformat which contains OBJFORMAT=aout... > > The functionality lost by this removal is nicely covered by the ability > to specify OBJFORMAT in the environment. I'm not so sure about this particular change, and this part is far from complete. /etc/objformat is referred to from quite a number of places including libc (see getobjformat(3)) and the *.mk files, documentation and (I believe) a book. The purpose of /etc/objformat is to allow overriding which defines the system default format. Since it isn't practical to recompile the system to change the default for some development task for a few days, we have an override of the default. role. It's purpose was to allow conditional overrides. Certain places in the source tree had "OBJFORMAT?= foo" which meant that the default for a given part of the tree would be changed unless the builder had explicitly set it. This used to be more "magic" than it is today, but I still feel it's useful to have the two seperate. Finally, as you say, we don't ship with the file present by default, so it doesn't interfere with cross builds. I don't see why it has to be killed.. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 23 7: 0:19 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 6916A14BF4 for ; Tue, 23 Nov 1999 07:00:15 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id PAA12074 for ; Tue, 23 Nov 1999 15:59:58 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA26451 for freebsd-arch@freebsd.org; Tue, 23 Nov 1999 15:59:57 +0100 (MET) Received: from post.mail.nl.demon.net (post-11.mail.nl.demon.net [194.159.73.21]) by hub.freebsd.org (Postfix) with ESMTP id 6FB61152AA for ; Tue, 23 Nov 1999 06:58:42 -0800 (PST) (envelope-from marcel@scc.nl) Received: from [212.238.132.94] (helo=scones.sup.scc.nl) by post.mail.nl.demon.net with esmtp (Exim 2.12 #1) id 11qHOU-0005oX-00; Tue, 23 Nov 1999 14:58:12 +0000 Received: from scc.nl (scones.sup.scc.nl [192.168.2.4]) by scones.sup.scc.nl (8.9.3/8.9.3) with ESMTP id PAA29290; Tue, 23 Nov 1999 15:57:56 +0100 (CET) (envelope-from marcel@scc.nl) Message-ID: <383AAB73.966D3D60@scc.nl> Date: Tue, 23 Nov 1999 15:57:55 +0100 From: Marcel Moolenaar Organization: SCC vof X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5 i386) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm Cc: freebsd-arch@freebsd.org Subject: Re: Cross-building (was: cross compilation goals) References: <19991123134900.D962E1CC8@overcee.netplex.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Wemm wrote: > > Marcel Moolenaar wrote: > > > 1. Remove support for /etc/objformat > > ------------------------------------ > The purpose of /etc/objformat is to allow overriding which > defines the system default format. Since it isn't practical to recompile the > system to change the default for some development task for a few days, we have > an override of the default. This can be accomplished by using the environment variable as well (see below). Is it possible to make an aout world (I don't mean legacy stuff) or a world with an objformat other than ELF? In other words do we actively support multiple object formats? > $OBJFORMAT is treated slightly differently and had a slightly different > role. It's purpose was to allow conditional overrides. Certain places in > the source tree had "OBJFORMAT?= foo" which meant that the default for a > given part of the tree would be changed unless the builder had explicitly > set it. This used to be more "magic" than it is today, but I still feel > it's useful to have the two seperate. Yes. Having an environment variable to control the output of the compilation toolset is a good thing. It can be applied system wide, but also in a smaller context. It can be undone by removing it and it can be overridden again. there's nothing about /etc/objformat that can't be handled with the environment variable. So, why /etc/objformat when it can only do harm in certain cases? > Finally, as you say, we don't ship with the file present by default, so it > doesn't interfere with cross builds. I don't see why it has to be killed.. The point is that the cross-compiler is adapting to a system it shouldn't be adapting to. /etc/objformat can be read by any tool that runs on the system, including the tools to which the override does not apply. Since it's a file, you cannot undo the override by removing the override, but you'll have to override the override, which makes it impossible to simply use the system default because you'll have to *know* the system default to be able to override the override. Needlessly complicated. /etc/objformat has served its purposes in the aout to elf switchover, but has lost it's function, I think. The new function you described it to be having is artificial IMO. This, I think, is also expressed in the fact that we don't have it. On systems that do have it (as described in my example) it can only mess things up. -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 23 8: 6: 2 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 4E7E214BD7 for ; Tue, 23 Nov 1999 08:05:59 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id RAA13157 for ; Tue, 23 Nov 1999 17:05:48 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA26753 for freebsd-arch@freebsd.org; Tue, 23 Nov 1999 17:05:47 +0100 (MET) Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id C41E114BD7 for ; Tue, 23 Nov 1999 08:05:42 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (root@d60-025.leach.ucdavis.edu [169.237.60.25]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id IAA38339; Tue, 23 Nov 1999 08:05:34 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id IAA42863; Tue, 23 Nov 1999 08:05:33 -0800 (PST) (envelope-from obrien) Date: Tue, 23 Nov 1999 08:05:33 -0800 From: "David O'Brien" To: Marcel Moolenaar Cc: freebsd-arch@freebsd.org Subject: Re: Cross-building (was: cross compilation goals) Message-ID: <19991123080533.A42803@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <19991123134900.D962E1CC8@overcee.netplex.com.au> <383AAB73.966D3D60@scc.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <383AAB73.966D3D60@scc.nl>; from marcel@scc.nl on Tue, Nov 23, 1999 at 03:57:55PM +0100 X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Nov 23, 1999 at 03:57:55PM +0100, Marcel Moolenaar wrote: > Is it possible to make an aout world (I don't mean legacy stuff) or a > world with an objformat other than ELF? In other words do we actively > support multiple object formats? I don't know if it is possible today (post 2.95.2), BUT in my mind, I do support it. I seriously hope to build an a.out box to make sure things still work. -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 23 8:10:11 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 14BED152DD for ; Tue, 23 Nov 1999 08:10:06 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id RAA13203 for ; Tue, 23 Nov 1999 17:09:50 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA26780 for freebsd-arch@freebsd.org; Tue, 23 Nov 1999 17:09:49 +0100 (MET) Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 0F20E14BD7 for ; Tue, 23 Nov 1999 08:09:39 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (root@d60-025.leach.ucdavis.edu [169.237.60.25]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id IAA38345; Tue, 23 Nov 1999 08:07:38 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id IAA42874; Tue, 23 Nov 1999 08:07:38 -0800 (PST) (envelope-from obrien) Date: Tue, 23 Nov 1999 08:07:38 -0800 From: "David O'Brien" To: Marcel Moolenaar Cc: freebsd-arch@freebsd.org Subject: Re: Cross-building (was: cross compilation goals) Message-ID: <19991123080738.B42803@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <383A95CA.AC00E8B@scc.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <383A95CA.AC00E8B@scc.nl>; from marcel@scc.nl on Tue, Nov 23, 1999 at 02:25:30PM +0100 X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Nov 23, 1999 at 02:25:30PM +0100, Marcel Moolenaar wrote: > Index: contrib/egcs/gcc/gcc.c ... > - /* first hint is /etc/objformat */ > - FILE *fp = fopen("/etc/objformat", "r"); We should switch to getobjformat(3) here, and remove the code for checking /etc/objformat and $OBJFORMAT directly. -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 23 8:57:52 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 63C87150EF for ; Tue, 23 Nov 1999 08:57:33 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id RAA13832 for ; Tue, 23 Nov 1999 17:57:31 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA27071 for freebsd-arch@freebsd.org; Tue, 23 Nov 1999 17:57:30 +0100 (MET) Received: from mail.scc.nl (node1374.a2000.nl [62.108.19.116]) by hub.freebsd.org (Postfix) with ESMTP id 7E410150FE for ; Tue, 23 Nov 1999 08:56:58 -0800 (PST) (envelope-from freebsd-arch@scc.nl) Received: (from daemon@localhost) by mail.scc.nl (8.9.3/8.9.3) id RAA69428 for arch@FreeBSD.org; Tue, 23 Nov 1999 17:42:44 +0100 (CET) (envelope-from freebsd-arch@scc.nl) Received: from GATEWAY by dwarf.hq.scc.nl with netnews for arch@FreeBSD.org (arch@FreeBSD.org) To: arch@freebsd.org Date: Tue, 23 Nov 1999 17:42:03 +0100 From: Marcel Moolenaar Message-ID: <383AC3DB.1739948B@scc.nl> Organization: SCC vof Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <383A95CA.AC00E8B@scc.nl>, <19991123080738.B42803@dragon.nuxi.com> Subject: Re: Cross-building (was: cross compilation goals) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David O'Brien wrote: > > On Tue, Nov 23, 1999 at 02:25:30PM +0100, Marcel Moolenaar wrote: > > Index: contrib/egcs/gcc/gcc.c > ... > > - /* first hint is /etc/objformat */ > > - FILE *fp = fopen("/etc/objformat", "r"); > > We should switch to getobjformat(3) here, and remove the code for > checking /etc/objformat and $OBJFORMAT directly. It's certainly much cleaner to use getobjformat in the first place. In that case, the question will be: should getobjformat use /etc/objformat? -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 23 10:25:32 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id B009314ED7 for ; Tue, 23 Nov 1999 10:25:25 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA14738 for ; Tue, 23 Nov 1999 19:24:55 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA27732 for freebsd-arch@freebsd.org; Tue, 23 Nov 1999 19:24:53 +0100 (MET) Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 4EB4815391 for ; Tue, 23 Nov 1999 10:21:14 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 330661CC7; Wed, 24 Nov 1999 02:21:02 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: Marcel Moolenaar Cc: arch@freebsd.org Subject: Re: Cross-building (was: cross compilation goals) In-Reply-To: Message from Marcel Moolenaar of "Tue, 23 Nov 1999 17:42:03 +0100." <383AC3DB.1739948B@scc.nl> Date: Wed, 24 Nov 1999 02:21:02 +0800 From: Peter Wemm Message-Id: <19991123182102.330661CC7@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Marcel Moolenaar wrote: > David O'Brien wrote: > > > > On Tue, Nov 23, 1999 at 02:25:30PM +0100, Marcel Moolenaar wrote: > > > Index: contrib/egcs/gcc/gcc.c > > ... > > > - /* first hint is /etc/objformat */ > > > - FILE *fp = fopen("/etc/objformat", "r"); > > > > We should switch to getobjformat(3) here, and remove the code for > > checking /etc/objformat and $OBJFORMAT directly. > > It's certainly much cleaner to use getobjformat in the first place. In > that case, the question will be: should getobjformat use /etc/objformat? Yes, it should use getobjformat(3), and leave getobjformat(3) as it is. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 23 11:13:18 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id A144214C4F for ; Tue, 23 Nov 1999 11:13:12 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA15318 for ; Tue, 23 Nov 1999 20:13:02 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA28549 for freebsd-arch@freebsd.org; Tue, 23 Nov 1999 20:13:01 +0100 (MET) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 6075D14C4F for ; Tue, 23 Nov 1999 11:12:38 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id MAA12837; Tue, 23 Nov 1999 12:11:39 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpdAAACVaGQy; Tue Nov 23 12:11:20 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id MAA02934; Tue, 23 Nov 1999 12:11:54 -0700 (MST) From: Terry Lambert Message-Id: <199911231911.MAA02934@usr06.primenet.com> Subject: Re: Cross compilation goals. To: marcel@scc.nl (Marcel Moolenaar) Date: Tue, 23 Nov 1999 19:11:54 +0000 (GMT) Cc: tlambert@primenet.com, arch@freebsd.org In-Reply-To: <38344691.BF54DAD@scc.nl> from "Marcel Moolenaar" at Nov 18, 99 07:33:53 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Another issue is that the GCC/EGCS code "front ending" is not > > very well integrated; you end up with huge amounts of installed > > headers, even if you are cross-compiling the same OS on another > > platform. > > I'm not sure I understand your point. Do you mean that installing the > headers in the object-tree should be avoided if they are the same as the > ones installed on the host? No. Although that is a good point: The headers should be included from their location in the source tree, not from the host, and not from the object tree. > Or that different architectures can share the same set of headers? Different machine architectures running the same OS. > The first case probably takes as much time to detect as it takes to > installing the headers. And the space saved is probably not worth all > the trouble. It's faster to _not_ detect AND _not_ install the headers. > The second case is not possible, so I assume you don't actually ment > that :-) The second case is perfectly possible, and reasonable in fact. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 23 11:23: 8 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id ACCC315146 for ; Tue, 23 Nov 1999 11:22:46 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA15404 for ; Tue, 23 Nov 1999 20:21:50 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA28627 for freebsd-arch@freebsd.org; Tue, 23 Nov 1999 20:21:50 +0100 (MET) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id AC9911538D; Tue, 23 Nov 1999 11:17:19 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id MAA23015; Tue, 23 Nov 1999 12:16:33 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpdAAArCai3S; Tue Nov 23 12:16:26 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id MAA03270; Tue, 23 Nov 1999 12:16:56 -0700 (MST) From: Terry Lambert Message-Id: <199911231916.MAA03270@usr06.primenet.com> Subject: Re: Cross compilation goals. To: owner-freebsd-arch@freebsd.org (Warner Losh) Date: Tue, 23 Nov 1999 19:16:56 +0000 (GMT) Cc: arch@freebsd.org In-Reply-To: <199911182348.QAA28898@harmony.village.org> from "Warner Losh" at Nov 18, 99 04:48:21 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I've just read the rest of the thread, and need to amplify the non > goal and state it as follows: > > 1) It will not necessarily be a goal of this effort to produce a > FreeBSD source tree that can be compiled on a non-FreeBSD > system. You will not necessarily be able to build a FreeBSD > system on a Solaris system, for example. I think it would have been very useful to the Alpha porting effort if it had been possbile to build FreeBSD on DEC UNIX. I still think it would be useful to seperate the compilation tools themselves (e.g. not the ancillary support tools, like bmake or binstall). Consider the performance of FreeBSD Alpha when compiled with the much better DEC Compiler, for example. > I'd like to add the following non-goal for the current effort: > > 2) It will not necessarily be a goal of this effort to produce > binaries for Non-FreeBSD systems on a FreeBSD system. I can agree with this one, although it is somewhat of a shame to lose this generalization. In particular, Linux cross-compilation is attractive from several vantage points, not the least of which is the commercial libraries available on Linux. > I agree with Marcel that the current set of goals is to make > cross-building work rather than the more generic and slightly > different cross-compilation problem. Yup. > Don't get me wrong. In the long term world, I'd love to see the > ability to make binaries for other systems (within reason) in FreeBSD, > but I'm not sure that is a current goal given our time horizons. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 23 11:28:41 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 6701D153C2 for ; Tue, 23 Nov 1999 11:28:36 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA15484 for ; Tue, 23 Nov 1999 20:27:15 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA28685 for freebsd-arch@freebsd.org; Tue, 23 Nov 1999 20:27:15 +0100 (MET) Received: from mail.scc.nl (node1374.a2000.nl [62.108.19.116]) by hub.freebsd.org (Postfix) with ESMTP id D747C14A2D for ; Tue, 23 Nov 1999 11:26:57 -0800 (PST) (envelope-from freebsd-arch@scc.nl) Received: (from daemon@localhost) by mail.scc.nl (8.9.3/8.9.3) id UAA09672 for arch@FreeBSD.org; Tue, 23 Nov 1999 20:25:50 +0100 (CET) (envelope-from freebsd-arch@scc.nl) Received: from GATEWAY by dwarf.hq.scc.nl with netnews for arch@FreeBSD.org (arch@FreeBSD.org) To: arch@freebsd.org Date: Tue, 23 Nov 1999 20:25:45 +0100 From: Marcel Moolenaar Message-ID: <383AEA39.853F353B@scc.nl> Organization: SCC vof Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <38344691.BF54DAD@scc.nl>, <199911231911.MAA02934@usr06.primenet.com> Subject: Re: Cross compilation goals. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > > Another issue is that the GCC/EGCS code "front ending" is not > > > very well integrated; you end up with huge amounts of installed > > > headers, even if you are cross-compiling the same OS on another > > > platform. > > > > I'm not sure I understand your point. Do you mean that installing the > > headers in the object-tree should be avoided if they are the same as the > > ones installed on the host? > > No. Although that is a good point: The headers should be included > from their location in the source tree, not from the host, and not > from the object tree. The problem with this is that some headers need to be generated and that the layout of the source tree is incompatible with layout of /usr/include. > > Or that different architectures can share the same set of headers? > > Different machine architectures running the same OS. We can't use the include files of the machine we are running on. They may be (totally) different from those of the machine we are trying to build (see below) > > The second case is not possible, so I assume you don't actually ment > > that :-) > > The second case is perfectly possible, and reasonable in fact. Include files of the same OS and version, but for different architectures are in general different for the machine dependent parts and sometimes even for the machine independent parts. How do you think we can share those headers? -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 23 11:31:47 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id BDD4114A2D for ; Tue, 23 Nov 1999 11:31:39 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA15528 for ; Tue, 23 Nov 1999 20:31:39 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA28726 for freebsd-arch@freebsd.org; Tue, 23 Nov 1999 20:31:38 +0100 (MET) Received: from canonware.com (canonware.com [207.20.242.18]) by hub.freebsd.org (Postfix) with SMTP id B53B314A2D for ; Tue, 23 Nov 1999 11:31:28 -0800 (PST) (envelope-from jasone@canonware.com) Received: (qmail 10259 invoked by uid 1001); 23 Nov 1999 19:31:06 -0000 Date: Tue, 23 Nov 1999 11:31:06 -0800 From: Jason Evans To: Daniel Eischen Cc: freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <19991123113106.G301@sturm.canonware.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from eischen@vigrid.com on Tue, Nov 23, 1999 at 07:19:54AM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Nov 23, 1999 at 07:19:54AM -0500, Daniel Eischen wrote: > On Tue, 23 Nov 1999, Chuck Robey wrote: > > It seems to me that we're talking about, basically, changing the scheduler > > from being process-centric to being KSE-centric, right? I think that > > means that, excepting possible per-process limits, the scheduler wouldn't > > care what process was up, and it would be keeping KSE run-lists, > > wait-lists, etc, right? > > I think the sleep queues need to be KSEs, and perhaps someday they'll > become per-mutex or condvar queues :-). I think the run queue has to > remain process (or kernel thread) oriented. The KSE run-list would be > hung off each process. How do you see this working with KSE soft processor affinity? It seems to me that there would be difficulty in determining which of a set of KSEs associated with a process should be run on a given CPU, if the run queue is at the process granularity. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 23 13:16:13 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id EA7A61537C for ; Tue, 23 Nov 1999 13:16:08 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA17065 for ; Tue, 23 Nov 1999 22:15:09 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA29414 for freebsd-arch@freebsd.org; Tue, 23 Nov 1999 22:15:07 +0100 (MET) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 8F8C31537C for ; Tue, 23 Nov 1999 13:14:54 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40328>; Wed, 24 Nov 1999 08:07:48 +1100 Content-return: prohibited Date: Wed, 24 Nov 1999 08:14:34 +1100 From: Peter Jeremy Subject: Re: Cross compilation goals. In-reply-to: <199911231916.MAA03270@usr06.primenet.com> To: Terry Lambert Cc: arch@freebsd.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Nov24.080748est.40328@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <199911182348.QAA28898@harmony.village.org> <199911231916.MAA03270@usr06.primenet.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Nov-24 06:16:56 +1100, Terry Lambert wrote: >> I've just read the rest of the thread, and need to amplify the non >> goal and state it as follows: >> >> 1) It will not necessarily be a goal of this effort to produce a >> FreeBSD source tree that can be compiled on a non-FreeBSD >> system. You will not necessarily be able to build a FreeBSD >> system on a Solaris system, for example. > > >I think it would have been very useful to the Alpha porting effort >if it had been possbile to build FreeBSD on DEC UNIX. I'm not sure that being able to FreeBSD/alpha on DEC UNIX would help any more than being able to build FreeBSD/alpha on FreeBSD/i386. (Though at the time, I gather neither worked correctly). That said, my recent attempts to install FreeBSD on a Multia would have be significantly simpler if I could have built netboot on DEC UNIX. > Consider the performance of FreeBSD Alpha when compiled >with the much better DEC Compiler, for example. Has anyone actually done any comparative benchmarks between the two compilers? I found that (contrary to my expectations) gcc 2.8.1 was better than the DU cc for md5(1) and related tools. >> I'd like to add the following non-goal for the current effort: >> >> 2) It will not necessarily be a goal of this effort to produce >> binaries for Non-FreeBSD systems on a FreeBSD system. > >I can agree with this one, although it is somewhat of a shame to >lose this generalization. Same here, though it would be nice to have more integrated support for cross-development to embedded environments. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 23 13:27:50 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 47E5614E73 for ; Tue, 23 Nov 1999 13:27:29 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA17291 for ; Tue, 23 Nov 1999 22:27:00 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA29544 for freebsd-arch@freebsd.org; Tue, 23 Nov 1999 22:27:00 +0100 (MET) Received: from plunger.gdeb.com (plunger.gdeb.com [153.11.11.3]) by hub.freebsd.org (Postfix) with ESMTP id 126C014E73 for ; Tue, 23 Nov 1999 13:26:35 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from orion.caen.gdeb.com ([153.11.109.11]) by plunger.gdeb.com with ESMTP id QAA06566; Tue, 23 Nov 1999 16:20:09 -0500 (EST) Received: from vigrid.com (clcrtr [153.11.109.129]) by orion.caen.gdeb.com (8.9.3/8.9.3) with ESMTP id QAA82092; Tue, 23 Nov 1999 16:22:22 -0500 (EST) (envelope-from eischen@vigrid.com) Message-ID: <383B058E.694FDE4C@vigrid.com> Date: Tue, 23 Nov 1999 16:22:22 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.51 [en] (X11; U; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jason Evans Cc: freebsd-arch@freebsd.org Subject: Re: Threads References: <19991123113106.G301@sturm.canonware.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jason Evans wrote: > > I think the sleep queues need to be KSEs, and perhaps someday they'll > > become per-mutex or condvar queues :-). I think the run queue has to > > remain process (or kernel thread) oriented. The KSE run-list would be > > hung off each process. > > How do you see this working with KSE soft processor affinity? It seems to > me that there would be difficulty in determining which of a set of KSEs > associated with a process should be run on a given CPU, if the run queue is > at the process granularity. I guess it depends on how you look at it. If a threaded application is granted multiple (sub)processes in order to run on multiple CPUs, you can view each subprocess as a vessel in which the UTS schedules work. The UTS knows how many subprocesses it has and can try to keep both supplied with threads. The UTS can also try to keep threads on the same process as they last executed. The kernel can do this also by keeping per-subprocess lists of KSEs, but this is only for KSEs that block/unblock in the kernel. It doesn't know about other threads that are scheduled on the subprocess by the UTS. I guess it might be OK to keep KSE lists hung off each subprocess, but what we want to ensure is that if a thread is preempted on one subprocess, the next cooperating subprocess is informed of the event. This is to ensure that if it is in a critical region, it can be resumed until it exits the critical region. Now what if we want a subprocess with "other than default" priority that only runs a small group of threads? Only the UTS knows what threads should be scheduled on this subprocess. We also don't want to use this subprocess as a vessel for other work because we want to reserve its quantum for the truly important events that may occur. In this situation, it makes a lot of sense to have the blocked/unblocked KSE list hung off the subprocess; as soon as there is an unblocked KSE on the subprocess, it is added to the run queue and can be scheduled at its other-than-default priority. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 23 21: 9:17 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 7718815500 for ; Tue, 23 Nov 1999 21:09:14 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id GAA24419 for ; Wed, 24 Nov 1999 06:09:12 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA31785 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 06:09:10 +0100 (MET) Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 62F4015500; Tue, 23 Nov 1999 21:08:41 -0800 (PST) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost [127.0.0.1]) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id AAA85910; Wed, 24 Nov 1999 00:06:54 -0500 (EST) (envelope-from chuckr@picnic.mat.net) Date: Wed, 24 Nov 1999 00:06:54 -0500 (EST) From: Chuck Robey To: Daniel Eischen Cc: Julian Elischer , Nate Williams , freebsd-arch@freebsd.org, jasone@freebsd.org Subject: Re: Threads In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 23 Nov 1999, Daniel Eischen wrote: > > I'm wondering if there might possibly be some way to preserve some level > > of simplicity by keeping ksid'd like we keep pid's now, so that things > > that juggle a 32 bit entity keep on doing that, although perhaps under > > another name. > > I think you're basically right in keeping things simple. I think > that a non-MT process should be equivalent to a MT process. The > non-MT process has only one co-operating process (itself) and one > KSE. Whenever the non-MT process blocks in the kernel, there are > no more available KSEs, so another process is scheduled. OK, then let me ask another question: are we at all concerned about maybe following an already established thread API, or are we going to create our own? Things like user threads probably could work as then are now (albeit perhaps with only minor changes in performance) and stuff with runtimes like Java wouldn't care, but big programs like XFree86 and Netscape, and specially made daemons trying to do things like mass factoring, that are going to really want to manipulate real concurrency levels, they're going to have to be aware of our real underlying API, so making a unique one will complicate a lot of lives. > Dan Eischen > eischen@vigrid.com ---------------------------------------------------------------------------- Chuck Robey | Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770 | I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 23 21:54:38 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 0F9A014F83 for ; Tue, 23 Nov 1999 21:54:31 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id GAA24937 for ; Wed, 24 Nov 1999 06:54:09 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA31955 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 06:54:08 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 4643315543; Tue, 23 Nov 1999 21:49:56 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id AAA24224; Wed, 24 Nov 1999 00:49:50 -0500 (EST) Date: Wed, 24 Nov 1999 00:49:49 -0500 (EST) From: Daniel Eischen To: Chuck Robey Cc: Julian Elischer , Nate Williams , freebsd-arch@freebsd.org, jasone@freebsd.org Subject: Re: Threads In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 24 Nov 1999, Chuck Robey wrote: > OK, then let me ask another question: are we at all concerned about maybe > following an already established thread API, or are we going to create our > own? Things like user threads probably could work as then are now (albeit > perhaps with only minor changes in performance) and stuff with runtimes > like Java wouldn't care, but big programs like XFree86 and Netscape, and > specially made daemons trying to do things like mass factoring, > that are going to really want to manipulate real concurrency levels, > they're going to have to be aware of our real underlying API, so making a > unique one will complicate a lot of lives. IMHO, we should stick to the POSIX and perhaps SSv2 standards. We shouldn't be rolling our own non-standard interfaces unless there's a very good reason to. POSIX provides a way to set concurrency levels (pthread_setconcurrency) as well as creating PTHREAD_SCOPE_SYSTEM threads which should compete for processor time with all the other scope system threads in the system. It might be good to see what Java and other systems need from a threads library. Is a fully compliant POSIX threading environment enough? Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 23 22:34:28 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id F125C15516 for ; Tue, 23 Nov 1999 22:34:19 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id HAA25320 for ; Wed, 24 Nov 1999 07:34:18 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id HAA32120 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 07:34:18 +0100 (MET) Received: from green.dyndns.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 230F615516; Tue, 23 Nov 1999 22:33:45 -0800 (PST) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost [127.0.0.1]) by green.dyndns.org (8.9.3/8.9.3) with ESMTP id BAA43025; Wed, 24 Nov 1999 01:33:04 -0500 (EST) (envelope-from green@FreeBSD.org) Date: Wed, 24 Nov 1999 01:33:04 -0500 (EST) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: ipfw@freebsd.org Cc: arch@freebsd.org Subject: new IPFW Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've finally sat myself down to take the first step in getting the new IPFW done. I'll start by listing some of the different ideas I've had, CC'd to arch@ so that I pick up the audience of people I need. First of all, what was done right about the old IPFW? The basic architecture is nice; a chain of rules is quite efficient, but can be improved upon with basic optimization techniques, which should be done. The syntax is pretty nice, and IPFW is really very fast. It is called by a hook so was easy to become a KLD. Now, the new IPFW could directly replace the old IPFW given that 1) it uses the same entry point, and 2) uses the same API. The API for calling IPFW per-packet itself is not bad. There are many things to improve upon. The old IPFW is very static and limited in certain regards. It uses a monolithic "rule" struct to store everything related to that rule, which is obviously not the right thing to do. There are arbitrary limits on rules because of this, and it makes the API pretty sickening. So what can be done better than the old IPFW? First of all, it should be easy to retrieve a rule and change it. I should be able get, for instance, rule 1000 (in old IPFW format, of course) 1000 deny all from 127.0.0.0/24 to any and replace it with 1000 deny all from 127.0.0.0/8 to any. This would require a retrieval, deletion, and addition under the current IPFW user API. Instead, there should be an API call that woul effectively say "change rule 1000's destination address netmask to /8". I also want to be able to make things nicer to do. One, a certain amount of state should be able to be stored, allowing stateful operations in IPFW where previously there were none. Commands should be more dynamic; all the old rule actions should be supported (pass, deny, fwd, divert, pipe, et al), whereas new ones should be easy to add by PIM (Pluggable IPFW Modules? =). Perhaps it would be nice to have a real "branch" action instead of using more hackish gotos, which can be terminated with deny all from any to any (which should be a synonym for "end"; you should be able to write procedures in IPFW). All actions except for deny should have a "continue" option, where the packet matching would both match that rule and follow its action, but also pass on to the next rule. This would obsolete the never-working- anyway "tee" action, and make things much easier, if thought about properly. To cut down on number of rules (that basically go pass such-and- such, deny other-such) with redundant information, which would of course take up less memory and processor time, each "match" type could be negated, such as, with a default-to-pass rule set, "deny [implicit all] ( src [alt:from] 127.0.0.0/8 or dest [alt:to] 127.0.0.8 ) and not interface lo0". This would allow actual logic in rules, albeit with slightly more complexity in the IPFW implementation in the kernel. This would be a huge gain for the administrator of the firewall, in that {,s}he could use a more natural programming syntax, rather than the current, simplistic, absolutely non-programmable (but klugeable) IPFW. For the matching rules themselves, they should be dynamic and possibly object-oriented. I envision something like this: struct ipfw_rule { int rule_number; /* maybe name alias, too? :) */ u_int32_t rule_options; /* for what doesn't fit in the action */ rule_action *action; /* action is an object and contains ancillary data */ SLIST_HEAD(, match_type) matches; /* must match all of these in the null-terminated list to match the rule */ struct irstats { u_int64_t matches; etc... } stats; }; The match_type could consist of something like: SLIST_FOREACH(matchrule, rule->matches, rule_list_entry) { if (!matchrule->dispatch(matchrule, packet, other info)) return 0; } passed all matches. action.... Where matcher_dispatch would read the match object, which would be inherited from the base type: struct base_matchrule { match_func_t *dispatch; }; and other types would be something like { struct address_matchrule { match_func_t *dispatch; u_int32_t flags; /* source/dest, IS or NOT, etc. */ struct sockaddr_maxsize addr; /* support in and in6 */ }; And this would be the object-oriented architecture part. I'm going to wrap this up since I'm up quite late (well, only 1:30, but I'm still a growing person...), and I don't want to start to get too incoherent. Thank you for your time and attention with my IPFW ideas, and please send comments and ideas to me; heck, I'd love to start a long discussion about this, so we can flesh everything out :) -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 23 22:48:49 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id B34CB14EC5 for ; Tue, 23 Nov 1999 22:48:40 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id HAA25609 for ; Wed, 24 Nov 1999 07:48:33 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id HAA32215 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 07:48:33 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id A540215162; Tue, 23 Nov 1999 22:48:15 -0800 (PST) (envelope-from julian@whistle.com) Received: from home.elischer.org (home.elischer.org [207.76.204.203]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id WAA55165; Tue, 23 Nov 1999 22:47:55 -0800 (PST) Date: Tue, 23 Nov 1999 22:47:53 -0800 (PST) From: Julian Elischer X-Sender: julian@home.elischer.org To: Daniel Eischen Cc: Chuck Robey , Nate Williams , freebsd-arch@freebsd.org, jasone@freebsd.org Subject: Re: Threads In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sorry to have been silent for few days on the topic.. I've been following but not had the time to respond. On Wed, 24 Nov 1999, Daniel Eischen wrote: > On Wed, 24 Nov 1999, Chuck Robey wrote: > > > OK, then let me ask another question: are we at all concerned about maybe > > following an already established thread API, or are we going to create our > > own? Things like user threads probably could work as then are now (albeit > > perhaps with only minor changes in performance) and stuff with runtimes > > like Java wouldn't care, but big programs like XFree86 and Netscape, and > > specially made daemons trying to do things like mass factoring, > > that are going to really want to manipulate real concurrency levels, > > they're going to have to be aware of our real underlying API, so making a > > unique one will complicate a lot of lives. > > IMHO, we should stick to the POSIX and perhaps SSv2 standards. We > shouldn't be rolling our own non-standard interfaces unless there's > a very good reason to. One of the 'goals' we discussed was th ability to implement standards Ithink that the exposed inteface will be a library. The kernel interface is something we will have towork out on our own. though some parts of it will necessarily be visible to teh outside (e.g. through ps) > > POSIX provides a way to set concurrency levels (pthread_setconcurrency) > as well as creating PTHREAD_SCOPE_SYSTEM threads which should compete > for processor time with all the other scope system threads in the system. > It might be good to see what Java and other systems need from a > threads library. Is a fully compliant POSIX threading environment > enough? I would imagine it should be enough. > > Dan Eischen > eischen@vigrid.com > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 23 23:35:32 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id CF98214C8E for ; Tue, 23 Nov 1999 23:35:28 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id IAA26338 for ; Wed, 24 Nov 1999 08:34:25 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA32516 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 08:34:25 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 6E38214F77 for ; Tue, 23 Nov 1999 23:34:14 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id XAA60550; Tue, 23 Nov 1999 23:34:02 -0800 (PST) Date: Tue, 23 Nov 1999 23:34:02 -0800 (PST) From: Julian Elischer To: Nate Williams Cc: "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: <199911210527.WAA13788@mt.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 20 Nov 1999, Nate Williams wrote: > > > > New calls must be able to return and say > > > > "hey it's not me returnuing, but actually a new KSE, " > > > > > > Not only that, but you need a way for it to be 'aborted' out and have it > > > cleanup as it goes. I suspect that this will require re-writing a large > > > number of syscalls with threading in mind, and leaving the 'old' calls > > > in place will allow more flexibility as things change. > > > > > > I could envision the 'old' calls going away at some point as the new > > > calls get completely fleshed out and tested, to be replaced with simple > > > wrappers for the threaded calls. > > > > Maybe in the libraries, but we will need to keep the old syscalls in the > > kernel effectively forever. (for old binaries) It's not much of a cost.. > > (look at linux emulation). > > Like I said above, the old calls could be simple wrappers for the new > 'threaded' syscalls, which gives us the ability to have both. > > The 'old' implementations would go away, not the old calls. The advantage of the methid that Dan is talking about (and I too) is that really there doesn't have to be very much re-writing of syscalls. you can basically do all the work in the tsleep call, the mswitch and teh trap (syscall) code. everything in between those points basically stays pretty much as-is. > > > Nate > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 23 23:38:15 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 0654E14C8E for ; Tue, 23 Nov 1999 23:38:12 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id IAA26409 for ; Wed, 24 Nov 1999 08:38:07 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA32557 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 08:38:07 +0100 (MET) Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 6FF8914C8E for ; Tue, 23 Nov 1999 23:37:55 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id IAA14544; Wed, 24 Nov 1999 08:05:45 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id XAA44855; Tue, 23 Nov 1999 23:50:11 +0100 (CET) (envelope-from wilko) From: Wilko Bulte Message-Id: <199911232250.XAA44855@yedi.iaf.nl> Subject: Re: Cross compilation goals. In-Reply-To: <99Nov24.080748est.40328@border.alcanet.com.au> from Peter Jeremy at "Nov 24, 1999 8:14:34 am" To: peter.jeremy@alcatel.com.au Date: Tue, 23 Nov 1999 23:50:11 +0100 (CET) Cc: tlambert@primenet.com, arch@freebsd.org X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As Peter Jeremy wrote ... > On 1999-Nov-24 06:16:56 +1100, Terry Lambert wrote: > >> I've just read the rest of the thread, and need to amplify the non > >> goal and state it as follows: > >> > >> 1) It will not necessarily be a goal of this effort to produce a > >> FreeBSD source tree that can be compiled on a non-FreeBSD > >> system. You will not necessarily be able to build a FreeBSD > >> system on a Solaris system, for example. > > > > > >I think it would have been very useful to the Alpha porting effort > >if it had been possbile to build FreeBSD on DEC UNIX. > > I'm not sure that being able to FreeBSD/alpha on DEC UNIX would help > any more than being able to build FreeBSD/alpha on FreeBSD/i386. > (Though at the time, I gather neither worked correctly). > > That said, my recent attempts to install FreeBSD on a Multia would > have be significantly simpler if I could have built netboot on > DEC UNIX. It would even be more practical if netboot were built by default. Which it was not until recently.. (dfr enabled it on 11/03 I just noticed ;-) > two compilers? I found that (contrary to my expectations) gcc 2.8.1 > was better than the DU cc for md5(1) and related tools. Hmm. Speed freaks could KAP-ify on DUNIX, that might be an asset. Wilko -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 23 23:49: 5 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 4FD0314EFC for ; Tue, 23 Nov 1999 23:49:02 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id IAA26622 for ; Wed, 24 Nov 1999 08:49:02 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA32623 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 08:49:01 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 2B63B15104 for ; Tue, 23 Nov 1999 23:48:15 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id XAA62150; Tue, 23 Nov 1999 23:47:18 -0800 (PST) Date: Tue, 23 Nov 1999 23:47:18 -0800 (PST) From: Julian Elischer To: "Daniel M. Eischen" Cc: Nate Williams , freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: <383785E5.C9193B77@vigrid.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 21 Nov 1999, Daniel M. Eischen wrote: > > Now I think I understand what Julian is talking about. Suppose a read(2) > blocks in an MT application. Julian is thinking that read(2) returns > with -1 and errno set to EMTBLOCKED or something like that? Not exactly.. I think that by stack magic what actually returns is a differnt KSE and it 'returns' (so to speak) to the UTS The way that the UTS tells the kernel how these returns are made is that one time for each subproc it calls a new syscall with information as to how to get to the UTS. Basically this is a set of context that the future upcalling KSEs will use. Basically a stack is set up and the KSE "returns". In some way you can think of it as being one call returning many times. The state saved from that one downcall becomes a prototype upcall. Each subproc has to do this once, as each should have a different return context for it's upcalls. If you haven;t done this you can't get upcalls so you are effectively non multithreaded. > > I don't think a blocking system call should return at all. > Control should be returned to the UTS at another entry point > and on another stack. Certainly, OR another possibility is that ALL syscalls return to the same place? > > Dan Eischen > eischen@vigrid.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 23 23:58:54 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id EAA241501B for ; Tue, 23 Nov 1999 23:58:50 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id IAA26852 for ; Wed, 24 Nov 1999 08:58:50 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA32689 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 08:58:49 +0100 (MET) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id DCAFD1501B; Tue, 23 Nov 1999 23:58:21 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40346>; Wed, 24 Nov 1999 18:51:11 +1100 Content-return: prohibited Date: Wed, 24 Nov 1999 18:58:01 +1100 From: Peter Jeremy Subject: Re: new IPFW In-reply-to: To: Brian Fundakowski Feldman Cc: arch@freebsd.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Nov24.185111est.40346@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Nov-24 17:33:04 +1100, Brian Fundakowski Feldman wrote: > All actions except for deny should have a "continue" option, where >the packet matching would both match that rule and follow its action, >but also pass on to the next rule. I don't quite follow what Brian means here. I'd like to suggest an additional 'goto rule N' command which, together with a pattern negation operator gives a fairly powerful language. Check out the filtering options in ppp(8) (the examples in /etc/ppp/ppp.conf.sample make them a bit clearer). >This would >allow actual logic in rules, albeit with slightly more complexity in >the IPFW implementation in the kernel. This would be a huge gain for >the administrator of the firewall, in that {,s}he could use a more >natural programming syntax, rather than the current, simplistic, >absolutely non-programmable (but klugeable) IPFW. IMHO, the complexity would be better in a userland `rule compiler' which produced (maybe more) simple rules for the kernel to execute. I suspect that trying to support complex rules in the kernel is unlikely to be a 'win' - think CISC vs RISC. A totally different approach is that used by bpf and libpcap. This could also form the basis of a reasonable IPFW implementation (but the API would probably need to change). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 2: 5:58 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id AB2361516B for ; Wed, 24 Nov 1999 02:05:42 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id LAA29309 for ; Wed, 24 Nov 1999 11:05:36 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id LAA33052 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 11:05:35 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 8CC251512A for ; Wed, 24 Nov 1999 02:04:28 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id CAA78056; Wed, 24 Nov 1999 02:04:15 -0800 (PST) Date: Wed, 24 Nov 1999 02:04:15 -0800 (PST) From: Julian Elischer To: "Daniel M. Eischen" Cc: freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: <3837F679.BCEC1312@vigrid.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 21 Nov 1999, Daniel M. Eischen wrote: > Julian Elischer wrote: > > > > On Sun, 21 Nov 1999, Daniel M. Eischen wrote: > > What better way to install them than to do a syscall down? > > All the kernel needs to know is that it sets some stuff, pre-empts the > > present KSE and runs another. > > I assumed that the UTS would have to perform a system call to > install the UTS upcall entry point(s). yes. There is a lot of information that can be supplied just in the action of making that call. You have a return address and some stack. I'd do it so that the context that the call saves to return to is the majority of the context that an upcall would get. If the upcalls all jumped in just as though they had made the syscall, then they have access to a bunch of stuff that can be easily tailored. e.g. local and static variables etc. To work with it you don;t need to be an expert in stack frames etc. You just need to know that you call a function that throws you onto a new stack, instead of returning. So the code for your prototypical async handler might be: /* * This function is called with the name of the function you want the * subproc to start its first thread on. This is how you start a new * subproc off on it's first thread. This stack is reserved for * returning async events FOR THIS SUBPROC. Remember each subproc can * have only one running KSE at a time, so the contents that the kernel * places in sc_state for the async handler are safe from other returning * events for othe rsobprocs and hopefully from other events associated * with this subproc (we hope) */ void handler (void startlocation(void *), void *arg) { struct syscall_state Asc_state; upcall_reason_t reason; reason = register_upcall(&syscall_state); switch (reason) { case ORIGINAL: newthread(startthread, startlocation, arg) /* notreached */ case INTERRUPT: newthread(signalhandler, sc_state, NULL); /* notreached */ case IO_COMPLETION: newthread(finish_syscall, sc_state, NULL); /* notreached */ case IO_BLOCKED: find_runnable_thread(); /* notreached */ } } > > > > > > That's OK, but why not use a ucontext passed in with a new system > > > call? Make the UTS supply ucontexts (made with makecontext) for event > > > notifications also. I think that the easiest context to create is one that you create by just being there. It's self correcting in the face of compiler changes etc. > > > > I'm not that fussed about it but it just seems to me that the information > > being passed back and forth is DIFFERENT than that being passed back and > > forth in the non-threaded world. > > True, but it is passed back and forth in NEW ways. It doesn't affect > non-MT system calls. That's where I disagree. I think nearly all syscalls can block given page faults etc. and having all syscalls potentially return via the UTS is going to mean some change in the kernel/process protocol. If a blocked syscall returns, then when it returns the UTS needs to be able to decide whether it is the most important thread to continue or not. So it can't just 'return', but has to come back via the UTS. This requires that things be considerably different. At least this is how I see it. > > I don't want to get into the trap of deciding that we are doing > > everything the "scheduler activations way", because we may be doing some > > things quite different. > > Granted, but let's also not let NIH have any impact on what we decide ;-) If we had that at the moment we wouldn't be discussing this the way we are.. > > > My philosophy is that things should be precomputed early and when they are > > required they are just 'used'. > > Agreed. > > > Here is a first half-thought out run-threough of how an IO syscall blocks > > and the UTS gets notified. > > --------------------- > > > > in a syscall, > > > > the thread loads some values on the user stack > > > > the thread calls the ULT aware syscall handler > > > > The ULT allocates an IO status block > > > > the ULT sycall handler calls the new callgate > > > > The callgate causes the user stack to be saved and registers to be saved, > > etc. the kernel stack is activated. > > > > a flag (a) is set. > > > > a setjmp() is done and saved at (b) and the stack is marked at (c) > > > > syscall is processed...... > > This seems overly complicated. What if the system call doesn't > block? You've just done all the above for nothing. the only extra work is the setjmp. The rest already occurs to some extent in the preent system. There is already some marshalling of arguments etc before calling the kernel or doing the syscall. it's just slightly different. The setjmp may not be needed, but some information needs to be done. Maybe a dummy frame is pushed (see later) > > > > at some point a tsleep() is hit. > > > > it notices that flag (a) is set, and > > > > grabs a new KSE from the KSE cache. > > > > copies the kernel stack up to to (c) to that on the new KSE > > > > copies the Async KSE's stack to (c) onto the old KSE > > Why not just context switch to the cached context beginning > at the UTS defined async notification entry points? Because it has to get some information about the syscall that blocked, and if it just took a copy of the stack as if it had just Made the call itself, it has that all available. The second time through (on the longjmp()) it goes to the 'it blocked' code rather than processing the request. It can set the 'it blocked' status on the IO status block allocated to that thread, and jump to the async return. The stack and a jetjmp contain all the information that might be required, so why not make use of it? Remember once this has happenned, the actual syscall is not going to return via that path anyhow, as it should go back via the UTS. > > > > > hacks the contents of (b) to fit the new KSE > > > > does a longjmp().. We are now effectively the thread returning > > > > Set 'incomplete' into the IO status block. > > > > * some stack munging thing done here I am not sure about * > > > > returns to the UTS indicating thread blocked > > > > * some user stack munging thing done here I am not sure about * > > > > UTS suspends thread > > > > UTS schedules new thread > > > > ***Time passes**** > > > > down in the bowels of the system the original KSE unblocks.. > > > > control passes back up to the top of the kernel. > > > > It sets the status of the IO as it would have, then returns, > > > > and finds itself in the ASYNC entrypoint of the UTS. (or maybe on the > > original return path.. depends on state of stack) > > > > the UTS notices that the IO has completed, and schedules the original > > thread to continue. The KSE then runs that thread until the UTS says > > otherwise. > > I think the above approach is too complicated and can be simplified > to eliminate the overhead in setting up the system call. I don't think there's much overhead other than allocating an IO status block in teh thread's last stack frame. > > Here's my thoughts. > > At thread library intialization time, the UTS makes contexts for > async notification event handlers. Contexts are in the form of a > return from a trap to the kernel. My idea is to use setcontext(2) > and makecontext(2) to create the contexts. We may need to give > the kernel additional user stacks, but that isn't clear yet. Flag > (async_notify) is set in the calling process. I think we are in violent agreement here, it's just implementation details. > > A thread makes a system call and it blocks; tsleep is hit. > (Notice that nothing needs to be done differently in order > to make a system call.) > > It notices that flag (async_notify) is set. It grabs a new > KSE (kernel register save area and kernel stack) from the KSE > cache, and places the current KSE in the sleep queue. exactly. > > A unique ID is created to identify the blocked KSE (integer > ID?). This unique ID, along with an ID that identifies the > event and any other necessary information, is copied to the > top of the user stack of the relevent async notification > event handler. The parameters to the UTS event handler are > setup to point to the top of the stack. See my example earlier.. > > The kernel returns directly to the UTS entry point on the > predefined context/user stack, just as if a setcontext(2) > was performed. Basically that's what I wan texcept that the syscall that sets the async handler returns multiple times.. Including when a blocked syscall resumes. > > The UTS knows what thread was running and marks it as blocked > in the kernel and saves the unique KSE ID. > How does it know what was running? > The UTS schedules a new thread. > > ***Time passes*** > > The original KSE unblocks. It is added to the current processes > unblocked KSE list. > > When the process runs again (or the next subprocess, since you > can have more than 1 cooperating processes), a new KSE is > allocated and context is set to the relevent UTS event handler. > Event information is copied out to the top of the predefined > user stack, parameters set accordingly, and the kernel returns > to the UTS event handler. If a thread was preempted for the > notification, then its context (just like getcontext(2)) is > also copied out to the UTS event handler user stack. I think we agree here. My only point is that a lot of this can be achieved using stack munging and that we don't need to create a lot of special frame handling and context saving if we use the saved state that si already existant in the stacks. > > The UTS event handler receives notification that the thread that > _was_ running on this process was preempted for this notification, > and that other KSEs have unblocked in the kernel. The UTS marks > the unblocked threads has active. The context of the thread that > was running can be resumed with setcontext(2) or hacked into a > jmp_buf and resumed with longjmp. > Yes, sure. > The UTS resumes the blocked thread in one of two ways. A new > system call to resume the KSE identified by it's unique ID is > one way. The other way is to have the kernel copy the context > of the unblocked KSE out to the UTS event handler. It can be > resumed with setcontext(2). I think that I'd like to see this shown with simulated stacks and such in pictures.. I think you and I are in agreement, but having trouble saying that. > > Dan Eischen > eischen@vigrid.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 2:29:41 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 7C95D150BF for ; Wed, 24 Nov 1999 02:29:32 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id LAA29710 for ; Wed, 24 Nov 1999 11:29:09 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id LAA33113 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 11:29:07 +0100 (MET) Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 8AD1E150BF; Wed, 24 Nov 1999 02:28:46 -0800 (PST) (envelope-from rgrimes@gndrsh.dnsmgr.net) Received: (from rgrimes@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id CAA45230; Wed, 24 Nov 1999 02:26:32 -0800 (PST) (envelope-from rgrimes) From: "Rodney W. Grimes" Message-Id: <199911241026.CAA45230@gndrsh.dnsmgr.net> Subject: Re: new IPFW In-Reply-To: from Brian Fundakowski Feldman at "Nov 24, 1999 01:33:04 am" To: green@freebsd.org (Brian Fundakowski Feldman) Date: Wed, 24 Nov 1999 02:26:29 -0800 (PST) Cc: ipfw@freebsd.org, arch@freebsd.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I've finally sat myself down to take the first step in getting the new > IPFW done. I'll start by listing some of the different ideas I've had, ... [and lots more good stuff cut to make this short and to the point]... > And this would be the object-oriented architecture part. > > I'm going to wrap this up since I'm up quite late (well, only 1:30, but > I'm still a growing person...), and I don't want to start to get too > incoherent. Thank you for your time and attention with my IPFW ideas, > and please send comments and ideas to me; heck, I'd love to start > a long discussion about this, so we can flesh everything out :) Have you looked at or though about using the bpf routines in the kernel? bpf match rules are very powerful, compile to some pretty fast code, and the code is already written, and it knows about a lot more than just IP. After all, they are probably the ``oldest'' set of filter routines we have, they have just never been reused to do firewall type stuff with. The fcode engine even has a jump, though all jumps must be forward in the fcode, but this is no more restrictive than the current firewall rule ``skipto'' operation. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 2:41:40 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id B589814C4C for ; Wed, 24 Nov 1999 02:41:29 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id LAA29982 for ; Wed, 24 Nov 1999 11:41:28 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id LAA33192 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 11:41:28 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 2A07315125; Wed, 24 Nov 1999 02:41:17 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id CAA82491; Wed, 24 Nov 1999 02:41:16 -0800 (PST) Date: Wed, 24 Nov 1999 02:41:16 -0800 (PST) From: Julian Elischer To: jasone@freebsd.org Cc: freebsd-arch@freebsd.org Subject: Re: Threads and my new job. In-Reply-To: <19991122185220.D301@sturm.canonware.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 22 Nov 1999, Jason Evans wrote: > Walnut Creek has hired me as a full time employee to work primarily on > improving and expanding FreeBSD's threads support. This is very exciting > to me, and I hope my work will be of benefit the FreeBSD community. Great. co-incidentally Terry tells me that at freeBSDcon someone told him that Microsoft hsa hired 2 ace programmers to add threads to freeBSD for some reason. He is adamant that it was microsoft, but can't remember whether it was Link-Exchange or Hotmail.. Paul at hotmails says "hey, not us" so maybe it's the other lot. (or maybe Terry thought it was Microsoft but it was apple or someone) Though the stated reason was to move som large package to NT-style threads under BSD and then 'jump' it over to NT. > > There is a lot of work to be done in order to make FreeBSD's threads > support truly excellent, and it will take more than just me working on it. > Fortunately, there are a number of other people also interested in > improving threads support, and as work progresses, I expect this will very > much be a group effort. > > Some very fruitful long-range architecture discussions have been taking > place on the -arch mailing list, and discussion will likely continue there > for some time as design decisions are hashed out. If you are interested in > participating in the design discussion, please subscribe to -arch (if you > haven't already), read the -arch archives for the past couple of weeks to > bring yourself up to speed on what has been discussed so far, read some of > the more pertinent references listed throughout the discussion, then jump > in. The signal-to-noise ratio on -arch is exceptionally high; please do > your part in keeping it that way. thanks for the plug.. > > What am I going to do? My first mandate is to round out the edges of our > current libc_r and to bring it closer to standards compliance before 4.0. > Specifically, I know that the following work is necessary: > > *) Address and close approximately 20 PRs. The list of PRs I know about > is: i386/7426, bin/7587, misc/8202, bin/8281, kern/8729, misc/9778, > misc/9903, misc/10599, bin/10992, kern/11982, kern/11984, bin/13008, > misc/13117, kern/13644, misc/14264, i386/14383, kern/14685, and > docs/14858. If there are other PRs that I didn't list that are directly > related to threads, please let me know about them in private email so > that I can keep track of them. Jolly good idea. can you buy the posix standard on CD and stick it in a drive at WC so we can read the official specs? (at least from Freefall) > > *) Signal delivery fixes. I think Daniel Eischen has already taken care of > this. > > *) Lacking interfaces, such as pthread_cancel() (mentioned specifically in > PR bin/7587) need to be implemented. > > *) Make a real libpthread, rather than relying on the -pthread linker > magic. This is high on Daniel Eischen's wish list, so maybe he already > has something in the works. =) > > If you know of other outstanding issues that have a prayer of being > addressed before 4.0 ships, please speak up. This is good stuff. I am trying to get ahead of this point by trying to work out the kernel support needed to do teh next step which is threading capable of utilising SMP but with good performance still. Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 2:52: 3 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 788C6151C6 for ; Wed, 24 Nov 1999 02:51:56 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id LAA00286 for ; Wed, 24 Nov 1999 11:51:27 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id LAA33238 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 11:51:26 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 291FB150B8; Wed, 24 Nov 1999 02:50:11 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id CAA83363; Wed, 24 Nov 1999 02:49:48 -0800 (PST) Date: Wed, 24 Nov 1999 02:49:48 -0800 (PST) From: Julian Elischer To: "Rodney W. Grimes" Cc: Brian Fundakowski Feldman , ipfw@freebsd.org, arch@freebsd.org Subject: Re: new IPFW In-Reply-To: <199911241026.CAA45230@gndrsh.dnsmgr.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 24 Nov 1999, Rodney W. Grimes wrote: > > I've finally sat myself down to take the first step in getting the new > > IPFW done. I'll start by listing some of the different ideas I've had, > ... [and lots more good stuff cut to make this short and to the point]... > > > And this would be the object-oriented architecture part. > > > > I'm going to wrap this up since I'm up quite late (well, only 1:30, but > > I'm still a growing person...), and I don't want to start to get too > > incoherent. Thank you for your time and attention with my IPFW ideas, > > and please send comments and ideas to me; heck, I'd love to start > > a long discussion about this, so we can flesh everything out :) > > Have you looked at or though about using the bpf routines in the > kernel? bpf match rules are very powerful, compile to some pretty > fast code, and the code is already written, and it knows about a lot > more than just IP. > > After all, they are probably the ``oldest'' set of filter routines > we have, they have just never been reused to do firewall type stuff > with. The fcode engine even has a jump, though all jumps must be > forward in the fcode, but this is no more restrictive than the current > firewall rule ``skipto'' operation. iThen there is a reference that Garret Wollman pointed out some time ago. a package at MIT called 'DPF' Very cool.. incorporated into the Exokernel. Unfortunatly it uses an in-kernel incremental machine instruction generator so it wouldn't be very portable, however it is apparently blazingly fast. I envision a combination of the structure of ipfw with the compiled speed of DPF. in other th packet falls through an IPFW branching structure until it hits a DPF filter which produces an outcome. > > -- > Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 3:24:53 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id C057114FC2 for ; Wed, 24 Nov 1999 03:24:46 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id MAA00962 for ; Wed, 24 Nov 1999 12:24:40 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id MAA33358 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 12:24:40 +0100 (MET) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 99F6F14A08; Wed, 24 Nov 1999 03:23:09 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (dcs@p19-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.148]) by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id UAA12468; Wed, 24 Nov 1999 20:22:27 +0900 (JST) Message-ID: <383BC9D9.B7E721C9@newsguy.com> Date: Wed, 24 Nov 1999 20:19:54 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Chuck Robey Cc: Daniel Eischen , Julian Elischer , Nate Williams , freebsd-arch@freebsd.org, jasone@freebsd.org Subject: Re: Threads References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Chuck Robey wrote: > > OK, then let me ask another question: are we at all concerned about maybe > following an already established thread API, or are we going to create our > own? Things like user threads probably could work as then are now (albeit > perhaps with only minor changes in performance) and stuff with runtimes > like Java wouldn't care, but big programs like XFree86 and Netscape, and > specially made daemons trying to do things like mass factoring, > that are going to really want to manipulate real concurrency levels, > they're going to have to be aware of our real underlying API, so making a > unique one will complicate a lot of lives. But do they? Do Netscape, XFree86 or any other program you know of make use of underlying APIs instead of lib-exported, POSIX-compliant APIs? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Then again maybe not going to heaven would be a blessing. Relkin liked a certain amount of peace and harmony, since there'd been a pronounced shortage of them in his own life; however, nothing but peace and harmony, forever and forever? He wasn't sure about that. And no beer? Very dubious proposition." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 3:54:24 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2AB1F14C30 for ; Wed, 24 Nov 1999 03:54:18 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id MAA01557 for ; Wed, 24 Nov 1999 12:54:17 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id MAA33413 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 12:54:16 +0100 (MET) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id D7E0E14C30 for ; Wed, 24 Nov 1999 03:54:08 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (dcs@p19-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.148]) by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id UAA26936; Wed, 24 Nov 1999 20:54:03 +0900 (JST) Message-ID: <383BD145.57BA3C7C@newsguy.com> Date: Wed, 24 Nov 1999 20:51:33 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Julian Elischer Cc: "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian, Dan, remember that reducing the overhead of task switching (thread switching) is of vital importance. In that light, the least context that has to be save/restored when a KSE blocks, the better. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Then again maybe not going to heaven would be a blessing. Relkin liked a certain amount of peace and harmony, since there'd been a pronounced shortage of them in his own life; however, nothing but peace and harmony, forever and forever? He wasn't sure about that. And no beer? Very dubious proposition." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 5:37:49 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 283691522C for ; Wed, 24 Nov 1999 05:37:44 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id OAA03332 for ; Wed, 24 Nov 1999 14:36:49 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA33640 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 14:36:47 +0100 (MET) Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id C6FCB15098; Wed, 24 Nov 1999 05:36:30 -0800 (PST) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id HAA25678; Wed, 24 Nov 1999 07:34:49 -0600 (CST) Received: (from jlemon@localhost) by right.PCS (8.8.5/8.6.4) id HAA03066; Wed, 24 Nov 1999 07:34:48 -0600 (CST) Message-ID: <19991124073447.18248@right.PCS> Date: Wed, 24 Nov 1999 07:34:47 -0600 From: Jonathan Lemon To: Julian Elischer Cc: "Rodney W. Grimes" , Brian Fundakowski Feldman , arch@freebsd.org Subject: Re: new IPFW References: <199911241026.CAA45230@gndrsh.dnsmgr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: ; from Julian Elischer on Nov 11, 1999 at 02:49:48AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Nov 11, 1999 at 02:49:48AM -0800, Julian Elischer wrote: > Unfortunatly it uses an in-kernel incremental machine instruction > generator so it wouldn't be very portable, however it is apparently > blazingly fast. Yes, I hope to be eable to incorporate the vcode generator if I ever have time. One thing you have to watch for is running the generator too often that you thrash the icache. The backend emits code for the alpha and i386 right now, IIRC, so that should cover our current platforms. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 6: 8: 0 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 8B8D71521C for ; Wed, 24 Nov 1999 06:07:56 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id PAA05158 for ; Wed, 24 Nov 1999 15:07:43 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA33717 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 15:07:43 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id AF0161522B for ; Wed, 24 Nov 1999 06:07:20 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt41.pcnet.net [206.105.29.115]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id JAA15576; Wed, 24 Nov 1999 09:05:20 -0500 (EST) Message-ID: <383BF031.B52BC41F@vigrid.com> Date: Wed, 24 Nov 1999 09:03:29 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Threads References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > > I think that the easiest context to create is one that you create by just > being there. It's self correcting in the face of compiler changes etc. Well, that's how getcontext and makecontext work also, except the application supplies the stack to use, as opposed to using the current stack. I don't see there being much difference between our ideas. > > > I'm not that fussed about it but it just seems to me that the information > > > being passed back and forth is DIFFERENT than that being passed back and > > > forth in the non-threaded world. > > > > True, but it is passed back and forth in NEW ways. It doesn't affect > > non-MT system calls. > > That's where I disagree. > I think nearly all syscalls can block given page faults etc. and having all > syscalls potentially return via the UTS is going to mean some change > in the kernel/process protocol. I guess we just disagree on how the kernel is entered. I just don't see why we need to change the method of entering the kernel. We just want to switch to a new context (UTS) when a KSE blocks, and that can be done from within the kernel without changing the method entering the kernel. > If a blocked syscall returns, then when it returns the UTS needs to > be able to decide whether it is the most important thread to continue or not. > So it can't just 'return', but has to come back via the UTS. This requires > that things be considerably different. At least this is how I see it. Right. And just because it woke up from a tsleep doesn't mean that it will eventually be able to finish and return to userland. It may encounter more tsleeps before leaving the kernel. The UTS needs to enter the kernel in order to resume the thread. And it needs a way of telling the kernel which blocked KSE to resume. The UTS is notified that a KSE has unblocked, but it doesn't have to immediately resume it - other threads may have higher priority. I think we are in agreement here. I'm just advocating using the stack of the UTS event handler context (in the form of parameters to the event handlers) to tell the UTS that threads have blocked/unblocked in the kernel. There doesn't have to be any magic/wizardry in the system calling convention to do this. The kernel can return directly to the predefined UTS event handlers (also on a predefined stack) and totally bypass the original system call in which it entered the kernel. At some point later, the UTS resumes the (now unblocked) KSE and returns the same way it entered. You also want the ability to inform the UTS of _more_ than just one event at a time. Several KSEs may unblock before a subprocess is run. You should be able to notify the UTS of them all at once. How does that work in your method? > > The UTS knows what thread was running and marks it as blocked > > in the kernel and saves the unique KSE ID. > > > > How does it know what was running? How can it not know? It was the last thread scheduled. It _has_ to know which threads are running on which processes in order to effectively schedule them. Our current threads library knows what thread is currently running - it is kept in _thread_run. We need to be able to retrieve TSD from a register, or perhaps per-process data mapped at the same address but still accessible to other subprocesses. Can we play games with %gs and/or LDTs? On the Alpha, can we just use an S register? I dunno. Another problem that really needs to be solved. > > When the process runs again (or the next subprocess, since you > > can have more than 1 cooperating processes), a new KSE is > > allocated and context is set to the relevent UTS event handler. > > Event information is copied out to the top of the predefined > > user stack, parameters set accordingly, and the kernel returns > > to the UTS event handler. If a thread was preempted for the > > notification, then its context (just like getcontext(2)) is > > also copied out to the UTS event handler user stack. > > I think we agree here. > My only point is that a lot of this can be achieved using stack munging and > that we don't need to create a lot of special frame handling and > context saving if we use the saved state that si already existant in the stacks. I think we can do this with just an ID for a KSE. The kernel will save it's own registers, and it knows where the trapframe is. Can't it just save a pointer to the trapframe in the KSE, switch to a new KSE and the UTS eventhandler frame, and pass an ID for the blocked KSE back out to the UTS event handler? > > The UTS resumes the blocked thread in one of two ways. A new > > system call to resume the KSE identified by it's unique ID is > > one way. The other way is to have the kernel copy the context > > of the unblocked KSE out to the UTS event handler. It can be > > resumed with setcontext(2). > > I think that I'd like to see this shown with simulated stacks and such > in pictures.. I think you and I are in agreement, but having > trouble saying that. :-) Pictures would be nice. I'll work on some over the Thanksgiving break. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 6:34: 8 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 214C915120 for ; Wed, 24 Nov 1999 06:34:04 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id PAA05650 for ; Wed, 24 Nov 1999 15:34:02 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA33790 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 15:34:02 +0100 (MET) Received: from test.tar.com (test.tar.com [204.95.187.4]) by hub.freebsd.org (Postfix) with ESMTP id 7A3DF15120 for ; Wed, 24 Nov 1999 06:33:50 -0800 (PST) (envelope-from dick@test.tar.com) Received: (from dick@localhost) by test.tar.com (8.9.3/8.9.3) id IAA93419; Wed, 24 Nov 1999 08:33:38 -0600 (CST) (envelope-from dick) Date: Wed, 24 Nov 1999 08:33:38 -0600 From: "Richard Seaman, Jr." To: "Daniel M. Eischen" Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <19991124083338.G1408@tar.com> References: <383BF031.B52BC41F@vigrid.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <383BF031.B52BC41F@vigrid.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Nov 24, 1999 at 09:03:29AM -0500, Daniel M. Eischen wrote: > > > The UTS knows what thread was running and marks it as blocked > > > in the kernel and saves the unique KSE ID. > > > > > > > How does it know what was running? > > How can it not know? It was the last thread scheduled. > > It _has_ to know which threads are running on which processes in > order to effectively schedule them. Our current threads library > knows what thread is currently running - it is kept in _thread_run. > > We need to be able to retrieve TSD from a register, or perhaps > per-process data mapped at the same address but still accessible > to other subprocesses. Can we play games with %gs and/or LDTs? > On the Alpha, can we just use an S register? I dunno. Another > problem that really needs to be solved. You may want to look at the latest linuxthreads code, which will use some combination of LTD and %fs register manipulation (that I don't profess to understand) to track the "current thread" and its TLS. I'm not sure if there is any work that will have to be done to FreeBSD for newer linuxthreads code to work in linux emulation mode, but in any case its something you might want to look at. -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 7:37:45 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id C5F4814A19 for ; Wed, 24 Nov 1999 07:37:17 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id QAA06601 for ; Wed, 24 Nov 1999 16:37:14 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA33971 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 16:37:14 +0100 (MET) Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id CE03E15244 for ; Wed, 24 Nov 1999 07:35:16 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 3.03 #1) id 11qeQr-0001cB-00 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 08:34:09 -0700 Message-ID: <383C056F.6202D5AE@softweyr.com> Date: Wed, 24 Nov 1999 08:34:07 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Reentrant library to-do list Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Pedro Giffuni called me on some belated deliveries on my work on the _r routines this afternoon. ;^) In the ensuing pleasant conversation, I sent him my to-do list and he suggested it would be a good idea to share it here. I snarfed a list of all the _r routines from a recent Solaris release, then categorized them in categories of "I need it now", "Lord, spare me", etc. Here's the list, including what I've already done: Already done: x asctime_r ctime (3c) - convert date and time to string x ctime_r ctime (3c) - convert date and time to string x gmtime_r ctime (3c) - convert date and time to string x localtime_r ctime (3c) - convert date and time to string x strtok_r string (3c) - string operations x tmpnam_r tmpnam (3s) - create a name for a temporary file x rand_r rand (3c) - simple random-number generator Relatively simple: gamma_r lgamma (3m) - log gamma function lgamma_r lgamma (3m) - log gamma function (IIRC, these are already *in* the library, and I have man pages ready on a system that is currently stuffed in a closet. Ignore these unless you really need them NOW). ctermid_r ctermid (3s) - generate path name for controlling terminal ttyname_r ttyname (3c) - find name of a terminal Probably simple: readdir_r directory (3c) - directory operations gethostbyaddr_r gethostbyname (3n) - get network host entry gethostbyname_r gethostbyname (3n) - get network host entry gethostent_r gethostbyname (3n) - get network host entry getnetbyaddr_r getnetbyname (3n) - get network entry getnetbyname_r getnetbyname (3n) - get network entry getnetent_r getnetbyname (3n) - get network entry getnetgrent_r getnetgrent (3n) - get network group entry getprotobyname_r getprotobyname (3n) - get protocol entry getprotobynumber_r getprotobyname (3n) - get protocol entry getprotoent_r getprotobyname (3n) - get protocol entry getrpcbyname_r getrpcbyname (3n) - get RPC entry getrpcbynumber_r getrpcbyname (3n) - get RPC entry getrpcent_r getrpcbyname (3n) - get RPC entry getservbyname_r getservbyname (3n) - get service entry getservbyport_r getservbyname (3n) - get service entry getservent_r getservbyname (3n) - get service entry fgetgrent_r getgrnam (3c) - get group entry getgrent_r getgrnam (3c) - get group entry getgrgid_r getgrnam (3c) - get group entry getgrnam_r getgrnam (3c) - get group entry getlogin_r getlogin (3c) - get login name This one looked so simple, I did it tonight just to prove I still can. I'll test it tomorrow and commit it then. ;^) Difficult due to non-reentrant dbm library: fgetpwent_r getpwnam (3c) - get password entry fgetspent_r getspnam (3c) - get password entry getspent_r getspnam (3c) - get password entry getspnam_r getspnam (3c) - get password entry getpwent_r getpwnam (3c) - get password entry getpwnam_r getpwnam (3c) - get password entry getpwuid_r getpwnam (3c) - get password entry I think we can probably take care of these by using a semaphore to serialize access to the password db. I haven't looked into it at all; I've been putting this off until the last because it's the messiest. Of course, it's usually the one that comes up first, too. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 8:50:16 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id DB969152B8 for ; Wed, 24 Nov 1999 08:49:59 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id RAA07430 for ; Wed, 24 Nov 1999 17:49:54 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA34299 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 17:49:54 +0100 (MET) Received: from dingo.cdrom.com (castles532.castles.com [208.214.165.96]) by hub.freebsd.org (Postfix) with ESMTP id C13FA152B8 for ; Wed, 24 Nov 1999 08:46:51 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id IAA04101; Wed, 24 Nov 1999 08:35:04 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199911241635.IAA04101@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Threads and my new job. In-reply-to: Your message of "Wed, 24 Nov 1999 02:41:16 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Nov 1999 08:35:03 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > What am I going to do? My first mandate is to round out the edges of our > > current libc_r and to bring it closer to standards compliance before 4.0. ... > can you buy the posix standard on CD and stick it in a drive at WC so we > can read the official specs? (at least from Freefall) If you can tell us which documents to buy and where from, we'll do just that. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 9:27:35 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 0A1831501B for ; Wed, 24 Nov 1999 09:27:31 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id SAA07792 for ; Wed, 24 Nov 1999 18:27:12 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA34535 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 18:27:12 +0100 (MET) Received: from inago.swcp.com (inago.swcp.com [198.59.115.17]) by hub.freebsd.org (Postfix) with ESMTP id 21D9414BF2; Wed, 24 Nov 1999 09:26:03 -0800 (PST) (envelope-from synk@swcp.com) Received: (from synk@localhost) by inago.swcp.com (8.8.7/8.8.7) id KAA14176; Wed, 24 Nov 1999 10:25:06 -0700 (MST) Date: Wed, 24 Nov 1999 10:25:06 -0700 From: Brendan Conoboy To: Brian Fundakowski Feldman Cc: ipfw@freebsd.org, arch@freebsd.org Subject: Re: new IPFW Message-ID: <19991124102506.A14069@inago.swcp.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: ; from Brian Fundakowski Feldman on Wed, Nov 24, 1999 at 01:33:04AM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Nov 24, 1999 at 01:33:04AM -0500, Brian Fundakowski Feldman wrote: > I've finally sat myself down to take the first step in getting the new > IPFW done. I'll start by listing some of the different ideas I've had, > CC'd to arch@ so that I pick up the audience of people I need. Perhaps everybody but me knows the answer to this one: Why not build off of ipfilter? I've chosen ipf over ipfw for the last couple of years because ipf already had state, nat proxies, route intervention, etc. Since 3.x freebsd has carried support for both. Does ipf have something really ugly under the hood that people don't want to work with? -Brendan (synk@swcp.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 10:16:50 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 02F2014BFF for ; Wed, 24 Nov 1999 10:16:46 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA08261 for ; Wed, 24 Nov 1999 19:16:45 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA34796 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 19:16:44 +0100 (MET) Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id ECC6115180 for ; Wed, 24 Nov 1999 10:16:31 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id VAA27220 for ; Tue, 23 Nov 1999 21:59:21 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id VAA26148; Tue, 23 Nov 1999 21:59:20 -0800 Received: from softweyr.com ([204.68.178.39]) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA16886; Tue, 23 Nov 99 21:59:17 PST Message-Id: <383B7EB4.6497E65@softweyr.com> Date: Tue, 23 Nov 1999 22:59:16 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Reentrant library to-do list Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Pedro Giffuni called me on some belated deliveries on my work on the _r routines this afternoon. ;^) In the ensuing pleasant conversation, I sent him my to-do list and he suggested it would be a good idea to share it here. I snarfed a list of all the _r routines from a recent Solaris release, then categorized them in categories of "I need it now", "Lord, spare me", etc. Here's the list, including what I've already done: Already done: x asctime_r ctime (3c) - convert date and time to string x ctime_r ctime (3c) - convert date and time to string x gmtime_r ctime (3c) - convert date and time to string x localtime_r ctime (3c) - convert date and time to string x strtok_r string (3c) - string operations x tmpnam_r tmpnam (3s) - create a name for a temporary file x rand_r rand (3c) - simple random-number generator Relatively simple: gamma_r lgamma (3m) - log gamma function lgamma_r lgamma (3m) - log gamma function (IIRC, these are already *in* the library, and I have man pages ready on a system that is currently stuffed in a closet. Ignore these unless you really need them NOW). ctermid_r ctermid (3s) - generate path name for controlling terminal ttyname_r ttyname (3c) - find name of a terminal Probably simple: readdir_r directory (3c) - directory operations gethostbyaddr_r gethostbyname (3n) - get network host entry gethostbyname_r gethostbyname (3n) - get network host entry gethostent_r gethostbyname (3n) - get network host entry getnetbyaddr_r getnetbyname (3n) - get network entry getnetbyname_r getnetbyname (3n) - get network entry getnetent_r getnetbyname (3n) - get network entry getnetgrent_r getnetgrent (3n) - get network group entry getprotobyname_r getprotobyname (3n) - get protocol entry getprotobynumber_r getprotobyname (3n) - get protocol entry getprotoent_r getprotobyname (3n) - get protocol entry getrpcbyname_r getrpcbyname (3n) - get RPC entry getrpcbynumber_r getrpcbyname (3n) - get RPC entry getrpcent_r getrpcbyname (3n) - get RPC entry getservbyname_r getservbyname (3n) - get service entry getservbyport_r getservbyname (3n) - get service entry getservent_r getservbyname (3n) - get service entry fgetgrent_r getgrnam (3c) - get group entry getgrent_r getgrnam (3c) - get group entry getgrgid_r getgrnam (3c) - get group entry getgrnam_r getgrnam (3c) - get group entry getlogin_r getlogin (3c) - get login name This one looked so simple, I did it tonight just to prove I still can. I'll test it tomorrow and commit it then. ;^) Difficult due to non-reentrant dbm library: fgetpwent_r getpwnam (3c) - get password entry fgetspent_r getspnam (3c) - get password entry getspent_r getspnam (3c) - get password entry getspnam_r getspnam (3c) - get password entry getpwent_r getpwnam (3c) - get password entry getpwnam_r getpwnam (3c) - get password entry getpwuid_r getpwnam (3c) - get password entry I think we can probably take care of these by using a semaphore to serialize access to the password db. I haven't looked into it at all; I've been putting this off until the last because it's the messiest. Of course, it's usually the one that comes up first, too. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 10:36: 2 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id AE08915302 for ; Wed, 24 Nov 1999 10:35:52 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA08417 for ; Wed, 24 Nov 1999 19:35:51 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA34919 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 19:35:50 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 87980152E8 for ; Wed, 24 Nov 1999 10:35:40 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA19645; Wed, 24 Nov 1999 10:35:39 -0800 (PST) (envelope-from dillon) Date: Wed, 24 Nov 1999 10:35:39 -0800 (PST) From: Matthew Dillon Message-Id: <199911241835.KAA19645@apollo.backplane.com> To: "Daniel C. Sobral" Cc: Julian Elischer , "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads References: <383BD145.57BA3C7C@newsguy.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Julian, Dan, remember that reducing the overhead of task switching :(thread switching) is of vital importance. In that light, the least :context that has to be save/restored when a KSE blocks, the better. : :-- :Daniel C. Sobral (8-DCS) :dcs@newsguy.com :dcs@freebsd.org I am getting confused by this whole KSE thing. All the threading I've ever implemented has been done simply by splitting out the context information from the Process into a Task, and then allowing N Tasks to reference the same Process. There was no real distinction made between kernel and user mode tasks or processes. In such a scheme the switch code need only contain a single conditional: One to check if the governing process for a task has a user-level mmu directory that must be setup. That's it, done. I don't think separate scheduling queues are required either. I can see absolutely no gain in performance by doing that and it unnecessarily complicates the code. We can trivially use the existing priority scheme to schedule interrupt tasks (threads). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 10:59:29 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id EA4B414F23 for ; Wed, 24 Nov 1999 10:59:22 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA08595 for ; Wed, 24 Nov 1999 19:59:18 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA35072 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 19:59:17 +0100 (MET) Received: from spirit.jaded.net (spirit.jaded.net [216.94.113.12]) by hub.freebsd.org (Postfix) with ESMTP id 6F39515307 for ; Wed, 24 Nov 1999 10:58:25 -0800 (PST) (envelope-from dan@spirit.jaded.net) Received: (from dan@localhost) by spirit.jaded.net (8.9.3/8.9.3) id NAA36002; Wed, 24 Nov 1999 13:58:29 -0500 (EST) Date: Wed, 24 Nov 1999 13:58:29 -0500 From: Dan Moschuk To: Mike Smith Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads and my new job. Message-ID: <19991124135829.B33731@spirit.jaded.net> References: <199911241635.IAA04101@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <199911241635.IAA04101@dingo.cdrom.com>; from mike@smith.net.au on Wed, Nov 24, 1999 at 08:35:03AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG | > can you buy the posix standard on CD and stick it in a drive at WC so we | > can read the official specs? (at least from Freefall) | | If you can tell us which documents to buy and where from, we'll do just | that. I believe the POSIX document that decribes threads is 1.003c. But I could be wrong (it may have been since updated?) -- Dan Moschuk (TFreak!dan@freebsd.org) "Cure for global warming: One giant heatsink and dual fans!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 11: 4:38 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id DB4C315184 for ; Wed, 24 Nov 1999 11:04:35 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA08627 for ; Wed, 24 Nov 1999 20:02:18 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA35114 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 20:02:18 +0100 (MET) Received: from canonware.com (canonware.com [207.20.242.18]) by hub.freebsd.org (Postfix) with SMTP id 3B38D14F3F for ; Wed, 24 Nov 1999 10:55:15 -0800 (PST) (envelope-from jasone@canonware.com) Received: (qmail 14236 invoked by uid 1001); 24 Nov 1999 18:53:42 -0000 Date: Wed, 24 Nov 1999 10:53:42 -0800 From: Jason Evans To: Mike Smith Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads and my new job. Message-ID: <19991124105342.N301@sturm.canonware.com> References: <199911241635.IAA04101@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <199911241635.IAA04101@dingo.cdrom.com>; from mike@smith.net.au on Wed, Nov 24, 1999 at 08:35:03AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Nov 24, 1999 at 08:35:03AM -0800, Mike Smith wrote: > > > What am I going to do? My first mandate is to round out the edges of our > > > current libc_r and to bring it closer to standards compliance before 4.0. > ... > > can you buy the posix standard on CD and stick it in a drive at WC so we > > can read the official specs? (at least from Freefall) > > If you can tell us which documents to buy and where from, we'll do just > that. It is IEEE Standard 1003.1, 1996 Edition. It costs $215 for a single-user license, and the format is PDF (the print version is $120). I asked about multiple users, and the sales agent said, "Well, you can give your pass code to others so they can download it." When asked if that was legal per the license agreement, she responded that I'd have to talk with customer service. From what I can intuit from the IEEE web site, to legally put the standard online, even to a limited audience such as the committers, would cost us many thousands of dollars. I personally ordered a hard-copy from fatbrain.com yesterday, basically because the prospects of making the spec electronically available to multiple developers appears to be financially and/or legally prohibitive. As an individual passing copies to friends, perhaps such licensing agreements aren't a huge deal. However, as an organization (FreeBSD) or a company (Walnut Creek CDROM), I'd be very leery of violating the license. Also, I don't think it's critical that everyone have access to the standard. There are a number of good books that cover pthreads in enough detail that only those concerned with pedantic compliance really need to read the standard. In addition, the Single Unix Specification, Version 2 is available online at http://www.opengroup.org with free registration. This is a superset of pthreads, which means that unless interested in the exact details of levels of conformance to the POSIX standard, there is online documentation freely available for all of pthreads (plus some). Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 11: 4:42 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 4FA4D15304 for ; Wed, 24 Nov 1999 11:04:37 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA08641 for ; Wed, 24 Nov 1999 20:03:46 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA35128 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 20:03:46 +0100 (MET) Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 413E714E03 for ; Wed, 24 Nov 1999 11:03:36 -0800 (PST) (envelope-from bright@wintelcom.net) Received: from localhost (bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) with ESMTP id LAA14540; Wed, 24 Nov 1999 11:29:30 -0800 (PST) Date: Wed, 24 Nov 1999 11:29:30 -0800 (PST) From: Alfred Perlstein To: Wes Peters Cc: freebsd-arch@freebsd.org Subject: Re: Reentrant library to-do list In-Reply-To: <383B7EB4.6497E65@softweyr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 23 Nov 1999, Wes Peters wrote: > Probably simple: > readdir_r directory (3c) - directory operations this is in my port of the OpenBSD pthread_cancel functionality. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 11: 5: 3 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 6739414E03 for ; Wed, 24 Nov 1999 11:05:00 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA08668 for ; Wed, 24 Nov 1999 20:04:56 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA35146 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 20:04:55 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 0D0F914F3F for ; Wed, 24 Nov 1999 11:04:18 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id OAA28855; Wed, 24 Nov 1999 14:03:02 -0500 (EST) Date: Wed, 24 Nov 1999 14:03:02 -0500 (EST) From: Daniel Eischen To: Matthew Dillon Cc: "Daniel C. Sobral" , Julian Elischer , "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: <199911241835.KAA19645@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 24 Nov 1999, Matthew Dillon wrote: > I am getting confused by this whole KSE thing. All the threading I've > ever implemented has been done simply by splitting out the context > information from the Process into a Task, and then allowing N Tasks to > reference the same Process. There was no real distinction made between > kernel and user mode tasks or processes. In this context, what is a task? Something similar to a kernel thread? If there are N (user-level POSIX) threads in an application, how many tasks are there? > In such a scheme the switch code need only contain a single conditional: > One to check if the governing process for a task has a user-level mmu > directory that must be setup. That's it, done. > > I don't think separate scheduling queues are required either. I can see > absolutely no gain in performance by doing that and it unnecessarily > complicates the code. We can trivially use the existing priority > scheme to schedule interrupt tasks (threads). The kernel doesn't know at what priority the threads run, so how can it effectively schedule them? Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 11: 6:20 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3476714DF2 for ; Wed, 24 Nov 1999 11:06:17 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA08701 for ; Wed, 24 Nov 1999 20:06:15 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA35201 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 20:06:15 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id E67BA150F3 for ; Wed, 24 Nov 1999 11:06:07 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA20045; Wed, 24 Nov 1999 11:05:54 -0800 (PST) (envelope-from dillon) Date: Wed, 24 Nov 1999 11:05:54 -0800 (PST) From: Matthew Dillon Message-Id: <199911241905.LAA20045@apollo.backplane.com> To: Daniel Eischen Cc: Matthew Dillon , "Daniel C. Sobral" , Julian Elischer , "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On Wed, 24 Nov 1999, Matthew Dillon wrote: : :> I am getting confused by this whole KSE thing. All the threading I've :> ever implemented has been done simply by splitting out the context :> information from the Process into a Task, and then allowing N Tasks to :> reference the same Process. There was no real distinction made between :> kernel and user mode tasks or processes. : :In this context, what is a task? Something similar to a kernel thread? :If there are N (user-level POSIX) threads in an application, how many :tasks are there? N. A task is simply an execution context for the scheduler. That's it, nothing special. The scheduler need only know about tasks and doesn't really have to know about meta-data such as (except for the MMU context) data stored in Processes, nor does it really need to know what *kind* of task it is messing with. Simplicity is the best solution. :> complicates the code. We can trivially use the existing priority :> scheme to schedule interrupt tasks (threads). : :The kernel doesn't know at what priority the threads run, so how can :it effectively schedule them? : :Dan Eischen If you have one Task == one Thread, the priority is in the Task structure, so the kernel would know. Obviously the scheduler must know or it can't properly schedule the execution context. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 11:23:15 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id B0FF01534C for ; Wed, 24 Nov 1999 11:23:08 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA08858 for ; Wed, 24 Nov 1999 20:23:07 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA35273 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 20:23:06 +0100 (MET) Received: from poboxer.pobox.com (ferg5200-1-47.cpinternet.com [208.149.16.47]) by hub.freebsd.org (Postfix) with ESMTP id 0C87B1535C for ; Wed, 24 Nov 1999 11:22:12 -0800 (PST) (envelope-from alk@poboxer.pobox.com) Received: (from alk@localhost) by poboxer.pobox.com (8.9.3/8.9.1) id NAA71005; Wed, 24 Nov 1999 13:21:00 -0600 (CST) (envelope-from alk) From: Anthony Kimball MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 24 Nov 1999 13:21:00 -0600 (CST) X-Face: \h9Jg:Cuivl4S*UP-)gO.6O=T]]@ncM*tn4zG);)lk#4|lqEx=*talx?.Gk,dMQU2)ptPC17cpBzm(l'M|H8BUF1&]dDCxZ.c~Wy6-j,^V1E(NtX$FpkkdnJixsJHE95JlhO 5\M3jh'YiO7KPCn0~W`Ro44_TB@&JuuqRqgPL'0/{):7rU-%.*@/>q?1&Ed Reply-To: alk@pobox.com To: jasone@canonware.com Cc: freebsd-arch@freebsd.org Subject: Re: Threads and my new job. References: <199911241635.IAA04101@dingo.cdrom.com> <19991124105342.N301@sturm.canonware.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14396.14494.374644.347506@avalon.east> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Quoth Jason Evans on Wed, 24 November: : I personally ordered a hard-copy from : fatbrain.com yesterday You can circulate your copy, so scan it. I suppose that to be pedantic, you should limit access to the pages to one viewer at a time. There must be a .htaccess syntax for that. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 11:28:15 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id D2B56153D8 for ; Wed, 24 Nov 1999 11:28:12 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA08917 for ; Wed, 24 Nov 1999 20:27:42 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA35312 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 20:27:42 +0100 (MET) Received: from poboxer.pobox.com (ferg5200-1-47.cpinternet.com [208.149.16.47]) by hub.freebsd.org (Postfix) with ESMTP id D3AA5152CF for ; Wed, 24 Nov 1999 11:27:31 -0800 (PST) (envelope-from alk@poboxer.pobox.com) Received: (from alk@localhost) by poboxer.pobox.com (8.9.3/8.9.1) id NAA71030; Wed, 24 Nov 1999 13:26:01 -0600 (CST) (envelope-from alk) From: Anthony Kimball MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 24 Nov 1999 13:26:01 -0600 (CST) X-Face: \h9Jg:Cuivl4S*UP-)gO.6O=T]]@ncM*tn4zG);)lk#4|lqEx=*talx?.Gk,dMQU2)ptPC17cpBzm(l'M|H8BUF1&]dDCxZ.c~Wy6-j,^V1E(NtX$FpkkdnJixsJHE95JlhO 5\M3jh'YiO7KPCn0~W`Ro44_TB@&JuuqRqgPL'0/{):7rU-%.*@/>q?1&Ed Reply-To: alk@pobox.com To: dillon@apollo.backplane.com Cc: freebsd-arch@freebsd.org Subject: Re: Threads References: <199911241905.LAA20045@apollo.backplane.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14396.15070.190669.25400@avalon.east> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It would be nice to keep an eye out for the future... SMP coscheduling of threads. I'd like to see FreeBSD become the OS of the fastest computer in the world. Making it easy to coschedule threads (or processes for that matter) would go a long way towards displacing Linux in this category. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 11:29:30 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 979C71534C for ; Wed, 24 Nov 1999 11:29:24 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA08938 for ; Wed, 24 Nov 1999 20:29:24 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA35350 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 20:29:24 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id C3154152CF for ; Wed, 24 Nov 1999 11:29:12 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id OAA02394; Wed, 24 Nov 1999 14:29:12 -0500 (EST) Date: Wed, 24 Nov 1999 14:29:12 -0500 (EST) From: Daniel Eischen To: Matthew Dillon Cc: Matthew Dillon , "Daniel C. Sobral" , Julian Elischer , "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: <199911241905.LAA20045@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 24 Nov 1999, Matthew Dillon wrote: > :In this context, what is a task? Something similar to a kernel thread? > :If there are N (user-level POSIX) threads in an application, how many > :tasks are there? > > N. A task is simply an execution context for the scheduler. That's it, > nothing special. The scheduler need only know about tasks and doesn't > really have to know about meta-data such as (except for the MMU context) > data stored in Processes, nor does it really need to know what *kind* > of task it is messing with. > > Simplicity is the best solution. > > :> complicates the code. We can trivially use the existing priority > :> scheme to schedule interrupt tasks (threads). > : > :The kernel doesn't know at what priority the threads run, so how can > :it effectively schedule them? > : > :Dan Eischen > > If you have one Task == one Thread, the priority is in the Task > structure, so the kernel would know. Obviously the scheduler must know > or it can't properly schedule the execution context. So everytime the UTS wants to run a new thread, it has to make a call to the kernel to tell it what it's current priority is? And the kernel is suppose to be able to handle SCHED_FIFO and SCHED_RR queueing? And the kernel will now if a task holds a critical resource and will be able to avoid priority inversions? I think we want to avoid having the kernel know too much about each thread. It is something that is more easily handled in the threads library. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 11:46:20 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 5047315413 for ; Wed, 24 Nov 1999 11:46:17 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA09079 for ; Wed, 24 Nov 1999 20:45:43 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA35431 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 20:45:42 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 68EDC1539F for ; Wed, 24 Nov 1999 11:42:10 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA20231; Wed, 24 Nov 1999 11:41:41 -0800 (PST) (envelope-from dillon) Date: Wed, 24 Nov 1999 11:41:41 -0800 (PST) From: Matthew Dillon Message-Id: <199911241941.LAA20231@apollo.backplane.com> To: Anthony Kimball Cc: freebsd-arch@freebsd.org Subject: Re: Threads References: <199911241905.LAA20045@apollo.backplane.com> <14396.15070.190669.25400@avalon.east> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :It would be nice to keep an eye out for the future... SMP :coscheduling of threads. I'd like to see FreeBSD become the OS of the :fastest computer in the world. Making it easy to coschedule threads :(or processes for that matter) would go a long way towards displacing :Linux in this category. Coscheduling is a fairly simple mechanism to implement. No real special cases need to be added to the scheduler itself, you simply ensure that it is 'most likely' for the threads to be scheduled together by placing them next to each other in the run queue. For example, if you have a single scheduling queue (which I really think is what we want) and the scheduler on each cpu picks off the next ready thread from the same queue, and two threads wakeup simultaniously, you can construct the queueing code such that it is highly likely that the two threads will each be (nearly) simultaniously assigned a different cpu and be able to run in parallel. Coscheduling becomes utterly trivial to accomplish if you are using a fractional fair-share scheduler with a single circular linked list of runnable (and running) threads. This is because you can insert a new thread anywhere in the list you wish without creating a hogging sleep/wakeup hogging situation. Thus you can group tasks together fairly easily, even if they have different priorities, and you can even insert special scheduling synchronization entities to handle stabilization issues. A scheduling synchronization entity is a dummy thread for which the context switch is minimal. The thread is responsible for doing special scheduling protocols for the following N threads on the list. The 'real' scheduler winds up not having to do anything special. The dummy thread doesn't really run in a real context and only runs long enough to schedule the next few entities in a special manner. Typically I implement my schedulers using the 'ret' trick. The entity going to sleep pushes whatever context needs to be saved and then pushes the 'restore' vector onto its stack, stores the stack pointer in the task, and then switches to the next task. To restore the context of the task being switched to, the scheduler simply loads the stack pointer from the task structure and issues a 'RET'. This way you can implement a number of special cases as scheduling entities (without any of the overhead) rather then within the scheduler core itself. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 11:53:18 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 9974B1519F for ; Wed, 24 Nov 1999 11:53:15 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA09128 for ; Wed, 24 Nov 1999 20:51:05 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA35477 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 20:51:05 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id C96D9153A8 for ; Wed, 24 Nov 1999 11:48:01 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA20277; Wed, 24 Nov 1999 11:48:00 -0800 (PST) (envelope-from dillon) Date: Wed, 24 Nov 1999 11:48:00 -0800 (PST) From: Matthew Dillon Message-Id: <199911241948.LAA20277@apollo.backplane.com> To: Daniel Eischen Cc: "Daniel C. Sobral" , Julian Elischer , "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> If you have one Task == one Thread, the priority is in the Task :> structure, so the kernel would know. Obviously the scheduler must know :> or it can't properly schedule the execution context. : :So everytime the UTS wants to run a new thread, it has to make a call :to the kernel to tell it what it's current priority is? And the kernel :is suppose to be able to handle SCHED_FIFO and SCHED_RR queueing? And :the kernel will now if a task holds a critical resource and will be :able to avoid priority inversions? The simple answer is: Yes. Of course, if you are already in the kernel making a call to the scheduler costs nothing. If you aren't, the cost is a microsecond or so (assuming all the other junk FreeBSD does in the critical path is removed - stuff that doesn't have to be there). The reason you want to implement threads in the kernel is because it gives you much greater flexibility, especially when threads are issuing I/O. Remember that most thread switches occur due to event blocking, and event blocking already requires the kernel no matter how fancy you get with asynchronous system calls. This doesn't prevent you from having a user-level thread scheduler, it simply means that the UTS must make a system call to specifically schedule the next thread for a processor if it wants to be the one to choose it. :I think we want to avoid having the kernel know too much about each :thread. It is something that is more easily handled in the threads :library. : :Dan Eischen :eischen@vigrid.com I agree to a degree. For basic threading schemes I think simply using native threads supported by the kernel is the way to go. If you want to implement special schemes that is something a UTS could do very easily with very little kernel support. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 11:56: 6 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 00CD71519F for ; Wed, 24 Nov 1999 11:56:04 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA09163 for ; Wed, 24 Nov 1999 20:55:55 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA35519 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 20:55:55 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 0149D1519F for ; Wed, 24 Nov 1999 11:55:49 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id LAA47845; Wed, 24 Nov 1999 11:55:14 -0800 (PST) Date: Wed, 24 Nov 1999 11:55:14 -0800 (PST) From: Julian Elischer To: Matthew Dillon Cc: "Daniel C. Sobral" , "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: <199911241835.KAA19645@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 24 Nov 1999, Matthew Dillon wrote: > > :Julian, Dan, remember that reducing the overhead of task switching > :(thread switching) is of vital importance. In that light, the least > :context that has to be save/restored when a KSE blocks, the better. > : > :-- > :Daniel C. Sobral (8-DCS) > :dcs@newsguy.com > :dcs@freebsd.org > > I am getting confused by this whole KSE thing. All the threading I've > ever implemented has been done simply by splitting out the context > information from the Process into a Task, and then allowing N Tasks to > reference the same Process. There was no real distinction made between > kernel and user mode tasks or processes. This is 'linux threads', and it's what we already have, using rfork() however it's very heavyweight when compared with pure userland threads. you need something in-between, to get the advantages of both kernel support (blockable syscalls and page-faults) and the ability to schedule 1000 tiny threads effficiently (which is the model that some threaded packages use). > > In such a scheme the switch code need only contain a single conditional: > One to check if the governing process for a task has a user-level mmu > directory that must be setup. That's it, done. We basically already havee that, but you need to have the ability to involve teh User Thread Scheduler in process restarts etc. > > I don't think separate scheduling queues are required either. I can see > absolutely no gain in performance by doing that and it unnecessarily > complicates the code. We can trivially use the existing priority > scheme to schedule interrupt tasks (threads). well I agree with you to a point..And we are not planning on separate scheduling queues for threads and normal processes. Basically threads are assigned to a parent process, which is treated pretty much as it is now in a lot of ways. > > -Matt > Matthew Dillon > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 11:59:42 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 30D4315082 for ; Wed, 24 Nov 1999 11:59:39 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA09191 for ; Wed, 24 Nov 1999 20:59:27 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA35541 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 20:59:26 +0100 (MET) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 2432515082 for ; Wed, 24 Nov 1999 11:59:19 -0800 (PST) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.9.3/8.9.1) with ESMTP id OAA42011; Wed, 24 Nov 1999 14:57:54 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <199911241957.OAA42011@whizzo.transsys.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Daniel Eischen Cc: Matthew Dillon , "Daniel C. Sobral" , Julian Elischer , freebsd-arch@freebsd.org From: "Louis A. Mamakos" Subject: Re: Threads References: In-reply-to: Your message of "Wed, 24 Nov 1999 14:29:12 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Nov 1999 14:57:54 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Wed, 24 Nov 1999, Matthew Dillon wrote: > > > :In this context, what is a task? Something similar to a kernel thread? > > :If there are N (user-level POSIX) threads in an application, how many > > :tasks are there? > > > > N. A task is simply an execution context for the scheduler. That's it, > > nothing special. The scheduler need only know about tasks and doesn't > > really have to know about meta-data such as (except for the MMU context) > > data stored in Processes, nor does it really need to know what *kind* > > of task it is messing with. > > > > Simplicity is the best solution. > > > > :> complicates the code. We can trivially use the existing priority > > :> scheme to schedule interrupt tasks (threads). > > : > > :The kernel doesn't know at what priority the threads run, so how can > > :it effectively schedule them? > > : > > :Dan Eischen > > > > If you have one Task == one Thread, the priority is in the Task > > structure, so the kernel would know. Obviously the scheduler must know > > or it can't properly schedule the execution context. > > So everytime the UTS wants to run a new thread, it has to make a call > to the kernel to tell it what it's current priority is? And the kernel > is suppose to be able to handle SCHED_FIFO and SCHED_RR queueing? And > the kernel will now if a task holds a critical resource and will be > able to avoid priority inversions? Wow, so this has turned way too complicated. I confess to having the same basic questions as Matt; why all this complexity? I think the answer is that there's a belief that having the kernel context switch between threads is too expensive, thus the desire to multiplex "user" threads on to fewer "kernel scheduled" threads. To answer your question: I think the question you're asking doesn't make any sense. I think Matt was proposing that there's simply a kernel thread context that exists for each and every "user" thread that's active in the application. Today, there's only one of these that's intimately associated with the process context (contains MMU/VM cntext, file descriptors, etc.) > I think we want to avoid having the kernel know too much about each > thread. It is something that is more easily handled in the threads > library. Why? If someone has done measurements comparing the different approaches, and show that there's too much "overhead", then that's great. But it appears that there's a considerable price to be paid in additional complexity by sticking a user-mode thread library with it. I ask simply because in my prior experiences with multi-threaded operating systems, there was no such thread multiplexing happening in user space. Certain my NeXTSTEP based system, running on a crummy 25MHz 68040 didn't die from the "overhead". And previously to that, on old UNIVAC 1100 series mainframes, there certainly wasn't any such thing going on. Their idea of "lightweight" threads (they called them "activities") had a reduced register set to save on context switching overhead. Wouldn't you have minimal support for non-multiplexed threads first? For many applications with just a handful of threads, the "overhead" issue probably isn't even noticable. And I just hate to think of the crocks that debuggers will need to have to be aware of this thread multiplexing going on in user space. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 12: 1:58 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 694AC1534F for ; Wed, 24 Nov 1999 12:01:55 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA09220 for ; Wed, 24 Nov 1999 21:01:46 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA35569 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 21:01:42 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 0E0BF15082 for ; Wed, 24 Nov 1999 12:01:36 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA20386; Wed, 24 Nov 1999 12:01:20 -0800 (PST) (envelope-from dillon) Date: Wed, 24 Nov 1999 12:01:20 -0800 (PST) From: Matthew Dillon Message-Id: <199911242001.MAA20386@apollo.backplane.com> To: "Louis A. Mamakos" Cc: Daniel Eischen , "Daniel C. Sobral" , Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads References: <199911241957.OAA42011@whizzo.transsys.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Wow, so this has turned way too complicated. I confess to having the same :basic questions as Matt; why all this complexity? I think the answer is :that there's a belief that having the kernel context switch between threads :is too expensive, thus the desire to multiplex "user" threads on to fewer :"kernel scheduled" threads. : :To answer your question: I think the question you're asking doesn't make :any sense. I think Matt was proposing that there's simply a kernel :thread context that exists for each and every "user" thread that's active :in the application. Today, there's only one of these that's intimately :associated with the process context (contains MMU/VM cntext, file descriptors, :etc.) I'm off to LA so I can't continue this conversion. Let me just try to clarify my position: I'm all for user-level thread schedulers, but I believe that the actual context switching should be done by the kernel for several reasons. The biggest single reason is one that people often forget: Threads usually 'block' and 'wakeup' due to events, and for an event to occur the kernel almost always has to be involved to some degree or other. But there are other reasons too. Distribution of threads across available cpu's, for example. Remember that it is not the context switch which is the expensive part, it's how you scale the event-handling when dealing with a large number of resources. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 12:23:25 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id E5584150E9 for ; Wed, 24 Nov 1999 12:23:23 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA09343 for ; Wed, 24 Nov 1999 21:23:08 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA35638 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 21:23:07 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id DAAA414F4E for ; Wed, 24 Nov 1999 12:22:26 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id MAA48914; Wed, 24 Nov 1999 12:20:52 -0800 (PST) Date: Wed, 24 Nov 1999 12:20:52 -0800 (PST) From: Julian Elischer To: "Louis A. Mamakos" Cc: Daniel Eischen , Matthew Dillon , "Daniel C. Sobral" , freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: <199911241957.OAA42011@whizzo.transsys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 24 Nov 1999, Louis A. Mamakos wrote: > > Wow, so this has turned way too complicated. I confess to having the same > basic questions as Matt; why all this complexity? I think the answer is > that there's a belief that having the kernel context switch between threads > is too expensive, thus the desire to multiplex "user" threads on to fewer > "kernel scheduled" threads. This is not just a 'belief'. This is known. The work done by SUN on this and the work done by other people in the field (e.g. CMA MACH project and the much referenced Scheduler activations paper) ALL show the same thing. The optimal threading system is a hybrid. > > To answer your question: I think the question you're asking doesn't make > any sense. I think Matt was proposing that there's simply a kernel > thread context that exists for each and every "user" thread that's active > in the application. Today, there's only one of these that's intimately > associated with the process context (contains MMU/VM cntext, file descriptors, > etc.) There can be thousandds of user threads, do we want a kernel thread for each one? > > > I think we want to avoid having the kernel know too much about each > > thread. It is something that is more easily handled in the threads > > library. > > Why? If someone has done measurements comparing the different approaches, > and show that there's too much "overhead", then that's great. But it > appears that there's a considerable price to be paid in additional complexity > by sticking a user-mode thread library with it. For measurements I direct you to the "Scheduler Activations" paper by Anderson et al. (referenced early in this thread) If it's done right (and has kernel support) the user land scheduler is relatively simple. > > I ask simply because in my prior experiences with multi-threaded operating > systems, there was no such thread multiplexing happening in user space. > Certain my NeXTSTEP based system, running on a crummy 25MHz 68040 didn't > die from the "overhead". Based on Mach2.5 I know that Mach 2.5 had two threading models available. but th ekernel model was not very suitable for very large numbers of threads.. it was great for the kind of app that makes 4 threads. Not great for the kind that makes 1000. > > And previously to that, on old UNIVAC 1100 series mainframes, there > certainly wasn't any such thing going on. Their idea of "lightweight" > threads (they called them "activities") had a reduced register set to > save on context switching overhead. And they had compiler support from memory. > > Wouldn't you have minimal support for non-multiplexed threads first? For > many applications with just a handful of threads, the "overhead" issue > probably isn't even noticable. We already have that.. try the Linuxthreads port. Works great for that class of app that works great on it. :-) > > And I just hate to think of the crocks that debuggers will need to have to > be aware of this thread multiplexing going on in user space. That is a worry certainly. But it was solved for Solaris > > louie > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 12:48:25 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 7A59A1548E for ; Wed, 24 Nov 1999 12:48:20 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA09551 for ; Wed, 24 Nov 1999 21:48:19 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA35739 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 21:48:18 +0100 (MET) Received: from poboxer.pobox.com (ferg5200-1-47.cpinternet.com [208.149.16.47]) by hub.freebsd.org (Postfix) with ESMTP id 8177A1546E for ; Wed, 24 Nov 1999 12:48:04 -0800 (PST) (envelope-from alk@poboxer.pobox.com) Received: (from alk@localhost) by poboxer.pobox.com (8.9.3/8.9.1) id OAA71425; Wed, 24 Nov 1999 14:47:22 -0600 (CST) (envelope-from alk) From: Anthony Kimball MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 24 Nov 1999 14:47:22 -0600 (CST) X-Face: \h9Jg:Cuivl4S*UP-)gO.6O=T]]@ncM*tn4zG);)lk#4|lqEx=*talx?.Gk,dMQU2)ptPC17cpBzm(l'M|H8BUF1&]dDCxZ.c~Wy6-j,^V1E(NtX$FpkkdnJixsJHE95JlhO 5\M3jh'YiO7KPCn0~W`Ro44_TB@&JuuqRqgPL'0/{):7rU-%.*@/>q?1&Ed Reply-To: alk@pobox.com To: julian@whistle.com Cc: freebsd-arch@freebsd.org Subject: Re: Threads References: <199911241957.OAA42011@whizzo.transsys.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14396.20155.343099.560103@avalon.east> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Quoth Julian Elischer on Wed, 24 November: : > And I just hate to think of the crocks that debuggers will need to have to : > be aware of this thread multiplexing going on in user space. : : That is a worry certainly. But it was solved for Solaris For some value of 'solved' ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 13:51:47 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 6C165152EE for ; Wed, 24 Nov 1999 13:51:44 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA10173 for ; Wed, 24 Nov 1999 22:51:27 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA36054 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 22:51:21 +0100 (MET) Received: from nameserver.austclear.com.au (nameserver.austclear.com.au [192.83.119.132]) by hub.freebsd.org (Postfix) with ESMTP id 1194515487; Wed, 24 Nov 1999 13:51:06 -0800 (PST) (envelope-from ahl@austclear.com.au) Received: from tungsten.austclear.com.au (tungsten.austclear.com.au [192.168.70.1]) by nameserver.austclear.com.au (8.9.3/8.9.3) with ESMTP id IAA69731; Thu, 25 Nov 1999 08:46:19 +1100 (EST) Received: from tungsten (tungsten [192.168.70.1]) by tungsten.austclear.com.au (8.9.3/8.9.3) with ESMTP id IAA25984; Thu, 25 Nov 1999 08:48:11 +1100 (EST) Message-Id: <199911242148.IAA25984@tungsten.austclear.com.au> X-Mailer: exmh version 2.0.1 12/23/97 To: ipfw@freebsd.org, arch@freebsd.org Subject: Re: new IPFW Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Nov 1999 08:48:10 +1100 From: Tony Landells Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG One of the things that would be a minor prettiness improvement (hmm, I wonder if I should TM that?)... At the moment I have rule numbers on every rule in rc.firewall because I want to start all my "groups" of rules at a boundary (like multiples of 10000 for "major" groups, and multiples of 1000 for "minor" groups). I didn't want to do it with numbers on every rule, but there didn't seem to be many alternatives: if I just put "$ipfw add 10000 ..." for each rule in the group, then they all get the exact same number if I use "skipto" to set line numbers every so often then I get crap I don't want in the rulesets if I put the line number on the first line in each group, then I have to actually pay attention when I'm debugging a new ruleset as to where I've commented out lines, or inserted/deleted the first line in a group--that's way too hard ;-) I'd be much happier with something in ipfw that just marked the next line number to be used, preferably in a way that I could get it to move to the next "grouping"--like "set the next rule number to the next multiple of 1000". Such a thing may fall out of going to a more procedural layout, because you could have: rules rfc1918 { # filter out and log any RFC 1918 addresses add deny log ... add deny log ... }; and then say something like "add rfc1918 ..." or whatever. Of course, I guess I could achieve the same effect by using a shell variable and a few functions in rc.firewall... Tony To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 13:53:55 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id D1F2A152EE for ; Wed, 24 Nov 1999 13:53:52 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA10199 for ; Wed, 24 Nov 1999 22:53:36 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA36092 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 22:53:36 +0100 (MET) Received: from nameserver.austclear.com.au (nameserver.austclear.com.au [192.83.119.132]) by hub.freebsd.org (Postfix) with ESMTP id 5279B152EE; Wed, 24 Nov 1999 13:53:15 -0800 (PST) (envelope-from ahl@austclear.com.au) Received: from tungsten.austclear.com.au (tungsten.austclear.com.au [192.168.70.1]) by nameserver.austclear.com.au (8.9.3/8.9.3) with ESMTP id IAA69742; Thu, 25 Nov 1999 08:50:35 +1100 (EST) Received: from tungsten (tungsten [192.168.70.1]) by tungsten.austclear.com.au (8.9.3/8.9.3) with ESMTP id IAA26077; Thu, 25 Nov 1999 08:52:28 +1100 (EST) Message-Id: <199911242152.IAA26077@tungsten.austclear.com.au> X-Mailer: exmh version 2.0.1 12/23/97 To: ipfw@freebsd.org, arch@freebsd.org Subject: Re: new IPFW In-Reply-To: Your message of "Wed, 24 Nov 1999 02:26:29 -0800." <199911241026.CAA45230@gndrsh.dnsmgr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Nov 1999 08:52:28 +1100 From: Tony Landells Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ using BPF for ipfw ] One concern I would have with that is that there are a lot of tools built on BPF that I would prefer to not be able to run on the firewall. Well, to be more accurate, I'd love to be able to run them on the firewall, but I don't want attackers to have access to them, and the safest option is to not even have support in the kernel for them (I can always plug in a separate sniffer if I really need it). Cheers, Tony To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 14: 2:13 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 07B8A152D5 for ; Wed, 24 Nov 1999 14:02:08 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA10272 for ; Wed, 24 Nov 1999 23:02:00 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA36149 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 23:02:00 +0100 (MET) Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 72F2A152D5 for ; Wed, 24 Nov 1999 14:01:52 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id WAA32950; Wed, 24 Nov 1999 22:05:27 GMT (envelope-from dfr@nlsystems.com) Date: Wed, 24 Nov 1999 22:05:27 +0000 (GMT) From: Doug Rabson To: "Daniel M. Eischen" Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: <383BF031.B52BC41F@vigrid.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 24 Nov 1999, Daniel M. Eischen wrote: > We need to be able to retrieve TSD from a register, or perhaps > per-process data mapped at the same address but still accessible > to other subprocesses. Can we play games with %gs and/or LDTs? > On the Alpha, can we just use an S register? I dunno. Another > problem that really needs to be solved. On alpha, we can use the PAL_wrunique and PAL_wrunique PALcode calls to manage thread-specific data. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 14: 9:18 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id AD191154D2 for ; Wed, 24 Nov 1999 14:09:14 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA10353 for ; Wed, 24 Nov 1999 23:09:13 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA36223 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 23:09:13 +0100 (MET) Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 65AAB152D5; Wed, 24 Nov 1999 14:09:03 -0800 (PST) (envelope-from rgrimes@gndrsh.dnsmgr.net) Received: (from rgrimes@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id OAA46490; Wed, 24 Nov 1999 14:08:47 -0800 (PST) (envelope-from rgrimes) From: "Rodney W. Grimes" Message-Id: <199911242208.OAA46490@gndrsh.dnsmgr.net> Subject: Re: new IPFW In-Reply-To: <199911242152.IAA26077@tungsten.austclear.com.au> from Tony Landells at "Nov 25, 1999 08:52:28 am" To: ahl@austclear.com.au (Tony Landells) Date: Wed, 24 Nov 1999 14:08:47 -0800 (PST) Cc: ipfw@freebsd.org, arch@freebsd.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > [ using BPF for ipfw ] > > One concern I would have with that is that there are a lot of tools > built on BPF that I would prefer to not be able to run on the firewall. > > Well, to be more accurate, I'd love to be able to run them on the > firewall, but I don't want attackers to have access to them, and > the safest option is to not even have support in the kernel for them > (I can always plug in a separate sniffer if I really need it). Non-issue. The fcode engine is in net/bpf_filter.c, the bpf tapping routings that actually get packets to/from the cards is in net/bpf.c. I din't mean to imply that the filtering should be done using the /dev/bpf interface, just that the engine code for filtering could be reused. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 14:19:42 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2441B154D2 for ; Wed, 24 Nov 1999 14:19:39 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA10433 for ; Wed, 24 Nov 1999 23:19:19 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA36317 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 23:19:19 +0100 (MET) Received: from canonware.com (canonware.com [207.20.242.18]) by hub.freebsd.org (Postfix) with SMTP id 07606152C8 for ; Wed, 24 Nov 1999 14:19:12 -0800 (PST) (envelope-from jasone@canonware.com) Received: (qmail 16679 invoked by uid 1001); 24 Nov 1999 22:17:18 -0000 Date: Wed, 24 Nov 1999 14:17:18 -0800 From: Jason Evans To: Anthony Kimball Cc: freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <19991124141718.Q301@sturm.canonware.com> References: <199911241957.OAA42011@whizzo.transsys.com> <14396.20155.343099.560103@avalon.east> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <14396.20155.343099.560103@avalon.east>; from alk@pobox.com on Wed, Nov 24, 1999 at 02:47:22PM -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Nov 24, 1999 at 02:47:22PM -0600, Anthony Kimball wrote: > Quoth Julian Elischer on Wed, 24 November: > : > And I just hate to think of the crocks that debuggers will need to have to > : > be aware of this thread multiplexing going on in user space. > : > : That is a worry certainly. But it was solved for Solaris > > For some value of 'solved' ;-) Debugging multi-threaded applications is just plain complex. I've found gdb's threads support on Solaris to be surprisingly good. I for one will be really happy if threads debugging is that well supported on FreeBSD. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 14:29:50 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2E68B151C2 for ; Wed, 24 Nov 1999 14:29:40 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA10541 for ; Wed, 24 Nov 1999 23:29:39 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA36387 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 23:29:39 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 33C2A14FD9 for ; Wed, 24 Nov 1999 14:29:31 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id OAA52537; Wed, 24 Nov 1999 14:28:35 -0800 (PST) Date: Wed, 24 Nov 1999 14:28:35 -0800 (PST) From: Julian Elischer To: Matthew Dillon Cc: "Daniel C. Sobral" , "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: <199911241835.KAA19645@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG BTW we have coined KSE "Kerne Schedulabel entity" simply top stop people confusing each other with words like 'task' which means different things on different OSs. Your 'Task' IS a 'Kernel Schedulable Entity'. For it to run it neads context and a stack and the kernel needs to be able to schedule it. On Wed, 24 Nov 1999, Matthew Dillon wrote: > > :Julian, Dan, remember that reducing the overhead of task switching > :(thread switching) is of vital importance. In that light, the least > :context that has to be save/restored when a KSE blocks, the better. > : > :-- > :Daniel C. Sobral (8-DCS) > :dcs@newsguy.com > :dcs@freebsd.org > > I am getting confused by this whole KSE thing. All the threading I've > ever implemented has been done simply by splitting out the context > information from the Process into a Task, and then allowing N Tasks to > reference the same Process. There was no real distinction made between > kernel and user mode tasks or processes. > > In such a scheme the switch code need only contain a single conditional: > One to check if the governing process for a task has a user-level mmu > directory that must be setup. That's it, done. > > I don't think separate scheduling queues are required either. I can see > absolutely no gain in performance by doing that and it unnecessarily > complicates the code. We can trivially use the existing priority > scheme to schedule interrupt tasks (threads). > > -Matt > Matthew Dillon > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 14:34:15 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 4F6B214BDA for ; Wed, 24 Nov 1999 14:34:12 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA10589 for ; Wed, 24 Nov 1999 23:33:05 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA36420 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 23:33:05 +0100 (MET) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 6C4A714FD9; Wed, 24 Nov 1999 14:32:54 -0800 (PST) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.9.3/8.9.1) with ESMTP id RAA21036; Wed, 24 Nov 1999 17:31:30 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <199911242231.RAA21036@whizzo.transsys.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Rodney W. Grimes" Cc: ahl@austclear.com.au (Tony Landells), ipfw@freebsd.org, arch@freebsd.org From: "Louis A. Mamakos" Subject: Re: new IPFW References: <199911242208.OAA46490@gndrsh.dnsmgr.net> In-reply-to: Your message of "Wed, 24 Nov 1999 14:08:47 PST." <199911242208.OAA46490@gndrsh.dnsmgr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Nov 1999 17:31:30 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > [ using BPF for ipfw ] > > > > One concern I would have with that is that there are a lot of tools > > built on BPF that I would prefer to not be able to run on the firewall. > > > > Well, to be more accurate, I'd love to be able to run them on the > > firewall, but I don't want attackers to have access to them, and > > the safest option is to not even have support in the kernel for them > > (I can always plug in a separate sniffer if I really need it). > > Non-issue. The fcode engine is in net/bpf_filter.c, the bpf tapping > routings that actually get packets to/from the cards is in net/bpf.c. > > I din't mean to imply that the filtering should be done using the /dev/bpf > interface, just that the engine code for filtering could be reused. I've actually used the BFP engine for just such an application. It was on another platform (NeXTSTEP), and it was sorta a netgraph-like system, but all in user space. I used a BPF-based engine for such things as "firewall" type filtering, as well as classifing traffic for dial-on-demand and idle-timeout reset. It worked quite well. The one extension which would be valuable is more an extension of the BPF expression compiler rather than the engine itself; if would be valuable to be able to return a value from the BPF-engine program so that it could be acted on. The engine itself has this capability, but the existing tcpdump intended expression compiler doesn't currently have syntax to support it. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 14:41:27 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 6ED7214BDA for ; Wed, 24 Nov 1999 14:41:17 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA10661 for ; Wed, 24 Nov 1999 23:41:15 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA36502 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 23:41:15 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 0D27914BDA for ; Wed, 24 Nov 1999 14:41:08 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id OAA53172; Wed, 24 Nov 1999 14:40:52 -0800 (PST) Date: Wed, 24 Nov 1999 14:40:52 -0800 (PST) From: Julian Elischer To: "Louis A. Mamakos" Cc: Daniel Eischen , Matthew Dillon , "Daniel C. Sobral" , freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I think matt ha sa point but it doesn't necessarily cover all the requirements that complying with posix threads brings us. The system we suggest includes an escape mechanism whereby the blocked KSE is 'replaced immediatlyby a new one, that is made available to the Userlevel Thread Scheduler (UTS). If this feature is not enabled (the appliation has to turn it on when it has enough of itself set up to handle it) then we effectively have Linux threads, or with only one process, our current threads. here are some common points that I think everyone agrees on: The proc structure get's broken down to separate out those parts needed to schedule. (i.e. context etc) When a KSE blocks, that stack and context are effectively frozen, just as they are now. where we differ is what happens next. In Matt's system new KSE is created and run and a different userland context is chosen and scheduled by the kernel on that KSE. (as it has all the userland contexts stored somewhere. In ours, a new KSE is created and run and the UTS is invoked which does the same job but in userland. In Matt's system a 'yield()' call is a system call, where in ours it's something similar to a setjmp + calling the UTS. In Matt's system creating a new user thread context requires making a syscall (to save the context of whichever thread doesn't continue after the call). The difference is in who has access to what information. The same task is being done in each case, but where? In the "kernel thread Scheduler" (KTS?) model the kernel has to know all the information required for scheduling these threads. The Userland needs to know this too to some extent to decide when to migrate threads around between processors and how and when to change priorities. (which it needs to do via syscalls). The sceduling methods are liitted to what the kerlel supports. In the UTS model, the kernel is oblivious to what threads are being scheduled onto the KSEs. Both systems could work. I think we need pictures :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 14:44:52 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 9E05814BDA for ; Wed, 24 Nov 1999 14:44:48 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA10686 for ; Wed, 24 Nov 1999 23:44:10 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA36531 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 23:44:09 +0100 (MET) Received: from chai.torrentnet.com (chai.torrentnet.com [198.78.51.73]) by hub.freebsd.org (Postfix) with ESMTP id 2EB5F14BDA; Wed, 24 Nov 1999 14:43:38 -0800 (PST) (envelope-from bakul@torrentnet.com) Received: from chai.torrentnet.com (localhost [127.0.0.1]) by chai.torrentnet.com (8.8.8/8.8.5) with ESMTP id RAA13782; Wed, 24 Nov 1999 17:42:38 -0500 (EST) Message-Id: <199911242242.RAA13782@chai.torrentnet.com> To: "Louis A. Mamakos" Cc: "Rodney W. Grimes" , ahl@austclear.com.au (Tony Landells), ipfw@freebsd.org, arch@freebsd.org Subject: Re: new IPFW In-reply-to: Your message of "Wed, 24 Nov 1999 17:31:30 EST." <199911242231.RAA21036@whizzo.transsys.com> Date: Wed, 24 Nov 1999 17:42:38 -0500 From: Bakul Shah Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > It worked quite well. The one extension which would be valuable is more > an extension of the BPF expression compiler rather than the engine itself; > if would be valuable to be able to return a value from the BPF-engine > program so that it could be acted on. The engine itself has this capability, > but the existing tcpdump intended expression compiler doesn't currently > have syntax to support it. What would be neat is an extensible filter language that maps symbolic names to a filter expression on packet fields as well as a printer language that allows specifying how things get printed. Right now you have to extend tcpdump's print routines for the latter. Also, there is no good reason why the print routines shouldn't be in a library like libpcap so that tcpdump is just a main program relying almost completely on a library. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 14:54:21 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id A2420154D2 for ; Wed, 24 Nov 1999 14:54:17 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA10762 for ; Wed, 24 Nov 1999 23:54:12 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA36581 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 23:54:11 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 4B5051552D; Wed, 24 Nov 1999 14:52:19 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id OAA53709; Wed, 24 Nov 1999 14:49:34 -0800 (PST) Date: Wed, 24 Nov 1999 14:49:33 -0800 (PST) From: Julian Elischer To: "Louis A. Mamakos" Cc: "Rodney W. Grimes" , Tony Landells , ipfw@freebsd.org, arch@freebsd.org Subject: Re: new IPFW In-Reply-To: <199911242231.RAA21036@whizzo.transsys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG We are playing with the idea of a 'bpf' node in netgraph. ALso a DPF node and a firewall node. We are also playing with the idea of puting the telnet daemon in a node too :-) Louis, have you looked at the pppoe node? (as you are the author of the RFC I'd like your comments) Is uunet implementing pppoe yet? I notice all our dsl line s are still 'routed'. (can you select which method to use with each custommer on a line by line basis? On Wed, 24 Nov 1999, Louis A. Mamakos wrote: > > > [ using BPF for ipfw ] > > > > > > One concern I would have with that is that there are a lot of tools > > > built on BPF that I would prefer to not be able to run on the firewall. > > > > > > Well, to be more accurate, I'd love to be able to run them on the > > > firewall, but I don't want attackers to have access to them, and > > > the safest option is to not even have support in the kernel for them > > > (I can always plug in a separate sniffer if I really need it). > > > > Non-issue. The fcode engine is in net/bpf_filter.c, the bpf tapping > > routings that actually get packets to/from the cards is in net/bpf.c. > > > > I din't mean to imply that the filtering should be done using the /dev/bpf > > interface, just that the engine code for filtering could be reused. > > I've actually used the BFP engine for just such an application. It was > on another platform (NeXTSTEP), and it was sorta a netgraph-like system, > but all in user space. I used a BPF-based engine for such things as > "firewall" type filtering, as well as classifing traffic for dial-on-demand > and idle-timeout reset. > > It worked quite well. The one extension which would be valuable is more > an extension of the BPF expression compiler rather than the engine itself; > if would be valuable to be able to return a value from the BPF-engine > program so that it could be acted on. The engine itself has this capability, > but the existing tcpdump intended expression compiler doesn't currently > have syntax to support it. > > louie > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 14:57:53 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id C0FE0154D2 for ; Wed, 24 Nov 1999 14:57:48 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA10817 for ; Wed, 24 Nov 1999 23:56:41 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA36636 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 23:56:40 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id BA60F154D2; Wed, 24 Nov 1999 14:56:30 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id OAA54155; Wed, 24 Nov 1999 14:55:34 -0800 (PST) Date: Wed, 24 Nov 1999 14:55:34 -0800 (PST) From: Julian Elischer To: Bakul Shah Cc: "Louis A. Mamakos" , "Rodney W. Grimes" , Tony Landells , ipfw@freebsd.org, arch@freebsd.org Subject: Re: new IPFW In-Reply-To: <199911242242.RAA13782@chai.torrentnet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 24 Nov 1999, Bakul Shah wrote: > > It worked quite well. The one extension which would be valuable is more > > an extension of the BPF expression compiler rather than the engine itself; > > if would be valuable to be able to return a value from the BPF-engine > > program so that it could be acted on. The engine itself has this capability, > > but the existing tcpdump intended expression compiler doesn't currently > > have syntax to support it. > > What would be neat is an extensible filter language that maps > symbolic names to a filter expression on packet fields as > well as a printer language that allows specifying how things > get printed. Right now you have to extend tcpdump's print > routines for the latter. Also, there is no good reason why > the print routines shouldn't be in a library like libpcap so > that tcpdump is just a main program relying almost completely > on a library. We've been doing some work on something similar but I had never thought of trying to apply it to bpf... hmmmmm. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 15:43:11 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id D864715404 for ; Wed, 24 Nov 1999 15:42:57 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA11348 for ; Thu, 25 Nov 1999 00:40:23 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA36859 for freebsd-arch@freebsd.org; Thu, 25 Nov 1999 00:40:22 +0100 (MET) Received: from test.tar.com (test.tar.com [204.95.187.4]) by hub.freebsd.org (Postfix) with ESMTP id 6639C1553B for ; Wed, 24 Nov 1999 15:40:05 -0800 (PST) (envelope-from dick@test.tar.com) Received: (from dick@localhost) by test.tar.com (8.9.3/8.9.3) id RAA95758; Wed, 24 Nov 1999 17:39:47 -0600 (CST) (envelope-from dick) Date: Wed, 24 Nov 1999 17:39:47 -0600 From: "Richard Seaman, Jr." To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <19991124173947.K1408@tar.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Nov 24, 1999 at 02:40:52PM -0800, Julian Elischer wrote: > here are some common points that I think everyone agrees on: > > The proc structure get's broken down to separate out those parts needed > to schedule. (i.e. context etc) This is probably the best. But, if you wanted to start out in a less invasive manner (ie. less kernel changes), I don't know why the KSE couldn't be an rforked proc (with appropriate flags), with only minor changes to the proc structure (eg. you might need to hold a pointer to the UTS, though if your "upcall" was just a signal, maybe the pointer to the UTS could be a signal handler). In this case your KSE would be "heavier", in terms of kernel context, than you would really need, but hopefully you wouldn't need all that many of them (one for each processor plus one for each thread blocked in a syscall, plus maybe a few more if you need more scheduler classes for your thread pool). The aio kernel code manages a pool of "kernel threads" that might provide a template for how to manage a pool of KSE's in this manner. Doing this might get you up and running sooner, with a longer term goal of reivsing the proc structure more extensively. Just a thought. -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 15:54:23 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3C0721520C for ; Wed, 24 Nov 1999 15:54:20 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA11540 for ; Thu, 25 Nov 1999 00:53:44 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA36900 for freebsd-arch@freebsd.org; Thu, 25 Nov 1999 00:53:44 +0100 (MET) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 28C1115404; Wed, 24 Nov 1999 15:52:30 -0800 (PST) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.9.3/8.9.1) with ESMTP id SAA21464; Wed, 24 Nov 1999 18:50:56 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <199911242350.SAA21464@whizzo.transsys.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Julian Elischer Cc: "Rodney W. Grimes" , Tony Landells , ipfw@freebsd.org, arch@freebsd.org From: "Louis A. Mamakos" Subject: Re: new IPFW References: In-reply-to: Your message of "Wed, 24 Nov 1999 14:49:33 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Nov 1999 18:50:56 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [as I don my pointy, er, UUNET hat..] > Louis, have you looked at the pppoe node? (as you are the author > of the RFC I'd like your comments) I've looked at the PPPOE node and the pppoed daemon code recently check in. I'm going to try to set up a FreeBSD test environment in my lab and play with it. We just moved a few weeks ago, and are trying to recover from the chaos of that :-( > Is uunet implementing pppoe yet? I notice all our dsl line s are still > 'routed'. (can you select which method to use with each custommer on a > line by line basis? Yes, though its generally only deployed these days for the consumer/residential product, rather than the business service. That reflects what was there first (the business service using what was available, IP/RFC1483/ATM or IP/RFC1490/Frame Relay). I don't know that it's easy to choose between the two, based on the back-end provisioning and OSS software that "knows" how each of the various products are supposed to be configured. The real driver for the PPPoE development was to support large scale deployments for residential/consumer users, and to support a resale model like we do on our dial network. louie (a.k.a. louie@UU.NET) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 15:56:30 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id BAC7D15556 for ; Wed, 24 Nov 1999 15:56:27 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA11584 for ; Thu, 25 Nov 1999 00:56:25 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA36939 for freebsd-arch@freebsd.org; Thu, 25 Nov 1999 00:56:25 +0100 (MET) Received: from bachue.usc.unal.edu.co (bachue.usc.unal.edu.co [168.176.3.20]) by hub.freebsd.org (Postfix) with ESMTP id 414E014E54 for ; Wed, 24 Nov 1999 15:56:14 -0800 (PST) (envelope-from pfgiffun@bachue.usc.unal.edu.co) Received: from bachue.usc.unal.edu.co ([168.176.3.32]) by bachue.usc.unal.edu.co (Netscape Messaging Server 3.6) with ESMTP id AAA319C for ; Wed, 24 Nov 1999 18:57:13 -0500 Message-ID: <383C7D78.5305704C@bachue.usc.unal.edu.co> Date: Wed, 24 Nov 1999 19:06:16 -0500 From: "Pedro Fernando Giffuni" Organization: U. Nacional de Colombia X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Re: Reentrant library to-do list References: <383B7EB4.6497E65@softweyr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wes Peters wrote: > > Pedro Giffuni called me on some belated deliveries on my work on the _r > routines this afternoon. ;^) > FWIW, Wes Peters took was taking newlib as a reference (last time I checked it wasn't GPL'd). Here's the new URL: ftp://sourceware.cygnus.com/pub/newlib/newlib-1.8.2.tar.gz cheers, PEdro. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 16:57: 2 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id F04C114FB1 for ; Wed, 24 Nov 1999 16:56:53 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id BAA12458 for ; Thu, 25 Nov 1999 01:56:52 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA37141 for freebsd-arch@freebsd.org; Thu, 25 Nov 1999 01:56:50 +0100 (MET) Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 62F4C15298 for ; Wed, 24 Nov 1999 16:55:45 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id QAA12746; Wed, 24 Nov 1999 16:54:37 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id QAA00531; Wed, 24 Nov 1999 16:54:37 -0800 Received: from softweyr.com (dyn0.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA16922; Wed, 24 Nov 99 16:54:36 PST Message-Id: <383C88CB.8DE9D19C@softweyr.com> Date: Wed, 24 Nov 1999 17:54:35 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Alfred Perlstein Cc: freebsd-arch@freebsd.org Subject: Re: Reentrant library to-do list References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > > On Tue, 23 Nov 1999, Wes Peters wrote: > > > Probably simple: > > readdir_r directory (3c) - directory operations > > this is in my port of the OpenBSD pthread_cancel functionality. Will you add it to the man page, or would you like me to do that? I can do man pages quickly, just point me at the code. If you used a man page from an existing system as a design spec, point me at that, too. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 16:57: 9 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id DDBC4151C6 for ; Wed, 24 Nov 1999 16:57:07 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id BAA12469 for ; Thu, 25 Nov 1999 01:57:06 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA37163 for freebsd-arch@freebsd.org; Thu, 25 Nov 1999 01:57:06 +0100 (MET) Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id A84C81558F for ; Wed, 24 Nov 1999 16:55:57 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id QAA12758; Wed, 24 Nov 1999 16:55:52 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id QAA00561; Wed, 24 Nov 1999 16:55:52 -0800 Received: from softweyr.com (dyn0.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA16986; Wed, 24 Nov 99 16:55:51 PST Message-Id: <383C8916.9945EFCB@softweyr.com> Date: Wed, 24 Nov 1999 17:55:50 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Pedro Fernando Giffuni Cc: freebsd-arch@freebsd.org Subject: Re: Reentrant library to-do list References: <383B7EB4.6497E65@softweyr.com> <383C7D78.5305704C@bachue.usc.unal.edu.co> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Pedro Fernando Giffuni wrote: > > Wes Peters wrote: > > > > Pedro Giffuni called me on some belated deliveries on my work on the _r > > routines this afternoon. ;^) > > > FWIW, > > Wes Peters took was taking newlib as a reference (last time I checked it > wasn't GPL'd). Here's the new URL: > > ftp://sourceware.cygnus.com/pub/newlib/newlib-1.8.2.tar.gz As well as the Solaris man pages, but I don't have an on-line reference for them. A copy of the relevant Posix spec might be a good idea, but they seem to want money for EVERYTHING. ;^( -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 17:19: 1 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 4B0B115541 for ; Wed, 24 Nov 1999 17:18:55 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id CAA12934 for ; Thu, 25 Nov 1999 02:18:08 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA37328 for freebsd-arch@freebsd.org; Thu, 25 Nov 1999 02:18:07 +0100 (MET) Received: from pau-amma.whistle.com (pau-amma.whistle.com [207.76.205.64]) by hub.freebsd.org (Postfix) with ESMTP id 1A3BD150D5 for ; Wed, 24 Nov 1999 17:18:00 -0800 (PST) (envelope-from dhw@whistle.com) Received: (from dhw@localhost) by pau-amma.whistle.com (8.9.2/8.9.2) id RAA00630 for freebsd-arch@FreeBSD.ORG; Wed, 24 Nov 1999 17:15:26 -0800 (PST) Date: Wed, 24 Nov 1999 17:15:26 -0800 (PST) From: David Wolfskill Message-Id: <199911250115.RAA00630@pau-amma.whistle.com> Subject: Re: Reentrant library to-do list Cc: freebsd-arch@freebsd.org In-Reply-To: <383C8916.9945EFCB@softweyr.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Date: Wed, 24 Nov 1999 17:55:50 -0700 >From: Wes Peters >As well as the Solaris man pages, but I don't have an on-line reference >for them. A copy of the relevant Posix spec might be a good idea, but >they seem to want money for EVERYTHING. ;^( For on-line Solaris docs, please see http://docs.sun.com/. Cheers, david -- David Wolfskill dhw@whistle.com UNIX System Administrator voice: (650) 577-7158 pager: (888) 347-0197 FAX: (650) 372-5915 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 21:27:19 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 16EF414BEB for ; Wed, 24 Nov 1999 21:27:16 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id GAA15598 for ; Thu, 25 Nov 1999 06:26:31 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA37862 for freebsd-arch@freebsd.org; Thu, 25 Nov 1999 06:26:30 +0100 (MET) Received: from canonware.com (canonware.com [207.20.242.18]) by hub.freebsd.org (Postfix) with SMTP id 950FB14BEB for ; Wed, 24 Nov 1999 21:26:15 -0800 (PST) (envelope-from jasone@canonware.com) Received: (qmail 17547 invoked by uid 1001); 25 Nov 1999 05:25:21 -0000 Date: Wed, 24 Nov 1999 21:25:21 -0800 From: Jason Evans To: Matthew Dillon Cc: freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <19991124212521.W301@sturm.canonware.com> References: <199911241905.LAA20045@apollo.backplane.com> <14396.15070.190669.25400@avalon.east> <199911241941.LAA20231@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <199911241941.LAA20231@apollo.backplane.com>; from dillon@apollo.backplane.com on Wed, Nov 24, 1999 at 11:41:41AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Nov 24, 1999 at 11:41:41AM -0800, Matthew Dillon wrote: > > :It would be nice to keep an eye out for the future... SMP > :coscheduling of threads. I'd like to see FreeBSD become the OS of the > :fastest computer in the world. Making it easy to coschedule threads > :(or processes for that matter) would go a long way towards displacing > :Linux in this category. > > Coscheduling is a fairly simple mechanism to implement. No real special > cases need to be added to the scheduler itself, you simply ensure that it > is 'most likely' for the threads to be scheduled together by placing them > next to each other in the run queue. > > For example, if you have a single scheduling queue (which I really think > is what we want) and the scheduler on each cpu picks off the next ready > thread from the same queue, and two threads wakeup simultaniously, > you can construct the queueing code such that it is highly likely that > the two threads will each be (nearly) simultaniously assigned a different > cpu and be able to run in parallel. Until reading about DEC's threading efforts (http://www.digital.com/info/DTJF03/DTJF03SC.TXT) a few days ago, I would have agreed with you. However, that paper makes some very valid arguments for needing multiple scheduling queues. The paper is very worthwhile reading. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 24 22: 8:41 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 03FC414D10 for ; Wed, 24 Nov 1999 22:08:29 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id HAA15830 for ; Thu, 25 Nov 1999 07:07:55 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id HAA38011 for freebsd-arch@freebsd.org; Thu, 25 Nov 1999 07:07:55 +0100 (MET) Received: from canonware.com (canonware.com [207.20.242.18]) by hub.freebsd.org (Postfix) with SMTP id 42A2414BC8 for ; Wed, 24 Nov 1999 22:07:28 -0800 (PST) (envelope-from jasone@canonware.com) Received: (qmail 17599 invoked by uid 1001); 25 Nov 1999 06:04:07 -0000 Date: Wed, 24 Nov 1999 22:04:07 -0800 From: Jason Evans To: "Daniel M. Eischen" Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <19991124220406.X301@sturm.canonware.com> References: <383BF031.B52BC41F@vigrid.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <383BF031.B52BC41F@vigrid.com>; from eischen@vigrid.com on Wed, Nov 24, 1999 at 09:03:29AM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Nov 24, 1999 at 09:03:29AM -0500, Daniel M. Eischen wrote: > Julian Elischer wrote: > > > I think nearly all syscalls can block given page faults etc. and having all > > syscalls potentially return via the UTS is going to mean some change > > in the kernel/process protocol. > > I guess we just disagree on how the kernel is entered. I just don't see > why we need to change the method of entering the kernel. We just want > to switch to a new context (UTS) when a KSE blocks, and that can be done > from within the kernel without changing the method entering the kernel. One of the main advantages I see to adding an asnchronous call gate (ACG) rather than changing the semantics of the current syscalls is that mixing traditional and asynchronous syscalls is very easy. I don't see this benefiting the threads effort much in the final product, but it does have the advantages of: 1) Asynchronous syscalls are useable by programs other than those that use threads. 2) The ability to mix and match traditional and asynchronous syscalls should make incremental development much less painful. Toggling the style of syscalls (traditional versus asynchronous) via some per-process flag would be possible, but it doesn't seem as clean to me, and it forfeits functionality without reducing complexity. > > If a blocked syscall returns, then when it returns the UTS needs to > > be able to decide whether it is the most important thread to continue or not. > > So it can't just 'return', but has to come back via the UTS. This requires > > that things be considerably different. At least this is how I see it. > > Right. And just because it woke up from a tsleep doesn't mean that it > will eventually be able to finish and return to userland. It may > encounter more tsleeps before leaving the kernel. The UTS needs > to enter the kernel in order to resume the thread. And it needs a > way of telling the kernel which blocked KSE to resume. > > The UTS is notified that a KSE has unblocked, but it doesn't have to > immediately resume it - other threads may have higher priority. I think > we are in agreement here. I'm just advocating using the stack of the > UTS event handler context (in the form of parameters to the event handlers) > to tell the UTS that threads have blocked/unblocked in the kernel. There > doesn't have to be any magic/wizardry in the system calling convention > to do this. The kernel can return directly to the predefined UTS event > handlers (also on a predefined stack) and totally bypass the original system > call in which it entered the kernel. At some point later, the UTS resumes > the (now unblocked) KSE and returns the same way it entered. > > You also want the ability to inform the UTS of _more_ than just one > event at a time. Several KSEs may unblock before a subprocess is run. > You should be able to notify the UTS of them all at once. How does > that work in your method? This sounds similar to Solaris LWPs in that there are potentially KSEs blocked in the kernel, whereas with scheduler activations (SA), that doesn't happen under normal circumstances. It sounds to me like the disagreement between you two (Daniel and Julian) is much more significant than what decisions are made by the UTS. Daniel, you say "The UTS is notified that a KSE has unblocked ...". However, if I understand the SA way of doing things, there is no KSE associated with a blocked syscall. The syscall context has some kernel context, but there is no bonifide context, such as with Solaris's LWP model. When the syscall completes, a new activation is created for the upcall to the UTS. That said, I disagree with the idea of the UTS having explicit control over scheduling of KSEs. I think that there should be exactly one KSE per processor (with the exception of PTHREAD_SCOPE_SYSTEM (bound) threads), and that threads should be multiplexed onto the KSEs. This lets the kernel schedule KSEs as it sees fit, and lets the UTS divide the runtime of the KSEs as it sees fit. > > I think you and I are in agreement, but having trouble saying that. I don't think you guys are in agreement, but one can hope. =) Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 25 1:10:51 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id D517F14CAD for ; Thu, 25 Nov 1999 01:10:47 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id KAA18651 for ; Thu, 25 Nov 1999 10:10:45 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id KAA38397 for freebsd-arch@freebsd.org; Thu, 25 Nov 1999 10:10:44 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 5209E14D7E for ; Thu, 25 Nov 1999 01:10:05 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id BAA65194; Thu, 25 Nov 1999 01:09:13 -0800 (PST) Date: Thu, 25 Nov 1999 01:09:13 -0800 (PST) From: Julian Elischer To: "Richard Seaman, Jr." Cc: freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: <19991124173947.K1408@tar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 24 Nov 1999, Richard Seaman, Jr. wrote: > On Wed, Nov 24, 1999 at 02:40:52PM -0800, Julian Elischer wrote: > > > here are some common points that I think everyone agrees on: > > > > The proc structure get's broken down to separate out those parts needed > > to schedule. (i.e. context etc) > > This is probably the best. But, if you wanted to start out in a > less invasive manner (ie. less kernel changes), I don't know why > the KSE couldn't be an rforked proc (with appropriate flags), > with only minor changes to the proc structure (eg. you might need > to hold a pointer to the UTS, though if your "upcall" was just > a signal, maybe the pointer to the UTS could be a signal handler). > > In this case your KSE would be "heavier", in terms of kernel context, > than you would really need, but hopefully you wouldn't need all that > many of them (one for each processor plus one for each thread blocked > in a syscall, plus maybe a few more if you need more scheduler classes > for your thread pool). I was thinking about this. but I think it may be better to actually start the split. at the moment we have in our mental model three kinds of entities involved: 1/ A process. Basically looks like a unx process. it can use a variant of rfork() to produce several subprocesses. 2/ To run on multiple CPUs you need multiple subprocesses. Also if you want to run some code in a differnet scheduling environment (e.g different priority), you would need a subprocess for that. For example on a 4 processor machine you could have 4 low priority subprocesses, each bound to one machine, and a high priority subprocess that might or might not be bound to a processor. Subprocesses compete with non MT processes as equals for CPU slices, but share address space etc. they are basically the LINUXthreads system. 3/ KSE's Each Subprocess has at least ONE KSE. In Linux threads, that's the end of the story. However in our ideal world, once a mode was flipped, then any KSE that blocked in the kernel would immediatly be replaced by another that would be made available to the subprocess, to allow it to finish out its quantum. Thus the real definition would be that a SUbprocess had at least one KSE, and at most one Running KSE. A KSE is basically a holder to hold context for a thread of control within the kernel. i.e it has a kernel stack and a few fields to allow it to sleep on the sleep queues and space for storage of all the registers. (maybe on the stack:-) A KSE is woken up, It's taken off the sleep queue an hung on the subprocess (which is put on the run queue). When the subprocess is next run, one of two things happens (depending on whether you use Matt's theory or mine/Dan's) In Matt's world, one of the KSE's hanging off the subprocess is fired off to return to user space. In My world, a UTS is started, and completion information on all waiting KSE's is passed back to the UTS, and the KSE's are all freed. > > The aio kernel code manages a pool of "kernel threads" that might > provide a template for how to manage a pool of KSE's in this manner. I was looking at this just yesterday :-) > > Doing this might get you up and running sooner, with a longer term > goal of reivsing the proc structure more extensively. > > Just a thought. > > > -- > Richard Seaman, Jr. email: dick@tar.com > 5182 N. Maple Lane phone: 262-367-5450 > Chenequa WI 53058 fax: 262-367-5852 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 25 1:31:11 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 61B7814DF1 for ; Thu, 25 Nov 1999 01:31:07 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id KAA19031 for ; Thu, 25 Nov 1999 10:31:00 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id KAA38461 for freebsd-arch@freebsd.org; Thu, 25 Nov 1999 10:30:59 +0100 (MET) Received: by hub.freebsd.org (Postfix, from userid 758) id DE7EF14C4A; Thu, 25 Nov 1999 01:30:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id CBFA11CD623; Thu, 25 Nov 1999 01:30:53 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Thu, 25 Nov 1999 01:30:53 -0800 (PST) From: Kris Kennaway To: Julian Elischer Cc: "Rodney W. Grimes" , Brian Fundakowski Feldman , arch@freebsd.org Subject: Re: new IPFW In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 24 Nov 1999, Julian Elischer wrote: > > Have you looked at or though about using the bpf routines in the > > kernel? bpf match rules are very powerful, compile to some pretty > > fast code, and the code is already written, and it knows about a lot > > more than just IP. > > iThen there is a reference that Garret Wollman pointed out some time ago. > a package at MIT called 'DPF' You should definitely look at this possibility. The downside is that we'd have to have a fallback generic option for non-x86 architectures (I'm pretty sure the DPF code was for x86). On another track, someone already raised the issue of ipfilter - this is as close to a standard as there is in the UNIX firewalling world (especially as the other BSDs use it exclusively). Of course, basing work on ipfilter isn't necessarily compatible with revolutionising the guts of the code, but we could provide a compatible interface. An ipfw->ipfilter rule translator can't be that difficult (I'm assuming the ipfilter functionality is a superset of ipfw, which seems to be at least approximately true). The other standard which network people are almost guaranteed to be familiar with is the cisco IOS model. This is probably less easy to emulate, but it's worth giving thought to IMO. The more familiar the interface is to people the easier it will be for them to secure their network with a freebsd box. Here's a wacky idea - we could have all three interfaces, by keeping the parser abstracted from the internal representation :-) The only other design goal I can think of now is to keep it as extensible as possible..(hmm..ipfw as netgraph node? :) Kris ---- Cthulhu for President! For when you're tired of choosing the _lesser_ of two evils.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 25 1:36:25 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 21D2214D87 for ; Thu, 25 Nov 1999 01:36:22 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id KAA19088 for ; Thu, 25 Nov 1999 10:34:30 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id KAA38491 for freebsd-arch@freebsd.org; Thu, 25 Nov 1999 10:34:29 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 367FF14C4A for ; Thu, 25 Nov 1999 01:34:21 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id BAA65566; Thu, 25 Nov 1999 01:33:36 -0800 (PST) Date: Thu, 25 Nov 1999 01:33:35 -0800 (PST) From: Julian Elischer To: Jason Evans Cc: "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: <19991124220406.X301@sturm.canonware.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 24 Nov 1999, Jason Evans wrote: > On Wed, Nov 24, 1999 at 09:03:29AM -0500, Daniel M. Eischen wrote: > > Julian Elischer wrote: > > > > > I think nearly all syscalls can block given page faults etc. and having all > > > syscalls potentially return via the UTS is going to mean some change > > > in the kernel/process protocol. > > > > I guess we just disagree on how the kernel is entered. I just don't see > > why we need to change the method of entering the kernel. We just want > > to switch to a new context (UTS) when a KSE blocks, and that can be done > > from within the kernel without changing the method entering the kernel. > > One of the main advantages I see to adding an asnchronous call gate (ACG) > rather than changing the semantics of the current syscalls is that mixing > traditional and asynchronous syscalls is very easy. I don't see this > benefiting the threads effort much in the final product, but it does have > the advantages of: > > 1) Asynchronous syscalls are useable by programs other than those that use > threads. > > 2) The ability to mix and match traditional and asynchronous syscalls > should make incremental development much less painful. If you have aseparate call-gate you can start off by making all the entries identical to the present call-gate, and change them one by one as you make them fit the new world. We continue to support the old callgate untouhed and old programs continue to work. Mixing old and new libraries also works so we can start with a new threaded libc with nothing in it and build it up a bit at a time, relying on libc to fill in the gaps. > > Toggling the style of syscalls (traditional versus asynchronous) via some > per-process flag would be possible, but it doesn't seem as clean to me, and > it forfeits functionality without reducing complexity. YECH! > > > > If a blocked syscall returns, then when it returns the UTS needs to > > > be able to decide whether it is the most important thread to continue or not. > > > So it can't just 'return', but has to come back via the UTS. This requires > > > that things be considerably different. At least this is how I see it. > > > > Right. And just because it woke up from a tsleep doesn't mean that it > > will eventually be able to finish and return to userland. It may > > encounter more tsleeps before leaving the kernel. The UTS needs > > to enter the kernel in order to resume the thread. And it needs a > > way of telling the kernel which blocked KSE to resume. > > > > The UTS is notified that a KSE has unblocked, but it doesn't have to > > immediately resume it - other threads may have higher priority. I think > > we are in agreement here. I'm just advocating using the stack of the > > UTS event handler context (in the form of parameters to the event handlers) > > to tell the UTS that threads have blocked/unblocked in the kernel. There > > doesn't have to be any magic/wizardry in the system calling convention > > to do this. The kernel can return directly to the predefined UTS event > > handlers (also on a predefined stack) and totally bypass the original system > > call in which it entered the kernel. At some point later, the UTS resumes > > the (now unblocked) KSE and returns the same way it entered. > > > > You also want the ability to inform the UTS of _more_ than just one > > event at a time. Several KSEs may unblock before a subprocess is run. > > You should be able to notify the UTS of them all at once. How does > > that work in your method? The next time the subproces (or maybe any subprocess) is run, all returned KSE's (which are hung under the subproc (or maybe even the proc) have their status and user context passed in to the UTS, (and as they have no purpose left, are freed) The UTS then starts up whatever thread it wants to. > > This sounds similar to Solaris LWPs in that there are potentially KSEs > blocked in the kernel, whereas with scheduler activations (SA), that > doesn't happen under normal circumstances. No, under SA KSE's block. and another KSE is generated to act as a replacement. it is used to run the activation that is passed to the scheduler, and this the next thread the process runs. > It sounds to me like the > disagreement between you two (Daniel and Julian) is much more significant > than what decisions are made by the UTS. Daniel, you say "The UTS is > notified that a KSE has unblocked ...". However, if I understand the SA > way of doing things, there is no KSE associated with a blocked syscall. there must be. there is a stack that must be saved, and registers. this is a KSE. > The syscall context has some kernel context, but there is no bonifide > context, such as with Solaris's LWP model. When the syscall completes, a > new activation is created for the upcall to the UTS. A KSE is basicaly saved proocessor state, including a stack, and some linkage points to allow that to be hug of various other structures, e.g. sleep queues, procs , subprocs, etc. > > That said, I disagree with the idea of the UTS having explicit control over > scheduling of KSEs. I think that there should be exactly one KSE per > processor (with the exception of PTHREAD_SCOPE_SYSTEM (bound) threads), and > that threads should be multiplexed onto the KSEs. This lets the kernel > schedule KSEs as it sees fit, and lets the UTS divide the runtime of the > KSEs as it sees fit. exactly what we are saying except make it exactly one RUNNING KSE per (sub)process, (and 0 or more blocked ones) You get your SMP support by rforking subprocesses, on efor each new processor/priority combination you want to use. Each has one or more KSEs and 0 or 1 Runnable KSEs. > > > > I think you and I are in agreement, but having trouble saying that. > > I don't think you guys are in agreement, but one can hope. =) I think this could all be sorted out with a few pictures. I'm going to try draw some.. :-) (gotta find a drawing tool.. hmm need to rummage around in ports..) pitty we can't use 'wb'. Julian > > Jason > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 25 3: 9:24 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id B1F8A14D85 for ; Thu, 25 Nov 1999 03:09:22 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id MAA21626 for ; Thu, 25 Nov 1999 12:09:20 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id MAA38676 for freebsd-arch@freebsd.org; Thu, 25 Nov 1999 12:09:19 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id D3ABF14D85 for ; Thu, 25 Nov 1999 03:09:12 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt40.pcnet.net [206.105.29.114]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id GAA16131; Thu, 25 Nov 1999 06:09:11 -0500 (EST) Message-ID: <383D18A9.884D6155@vigrid.com> Date: Thu, 25 Nov 1999 06:08:25 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Jason Evans Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads References: <383BF031.B52BC41F@vigrid.com> <19991124220406.X301@sturm.canonware.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jason Evans wrote: > > One of the main advantages I see to adding an asnchronous call gate (ACG) > rather than changing the semantics of the current syscalls is that mixing I'm advocating _not_ changing the semantics of current syscalls. I don't think it's necessary. > > Right. And just because it woke up from a tsleep doesn't mean that it > > will eventually be able to finish and return to userland. It may > > encounter more tsleeps before leaving the kernel. The UTS needs > > to enter the kernel in order to resume the thread. And it needs a > > way of telling the kernel which blocked KSE to resume. > > > > The UTS is notified that a KSE has unblocked, but it doesn't have to > > immediately resume it - other threads may have higher priority. I think > > we are in agreement here. I'm just advocating using the stack of the > > UTS event handler context (in the form of parameters to the event handlers) > > to tell the UTS that threads have blocked/unblocked in the kernel. There > > doesn't have to be any magic/wizardry in the system calling convention > > to do this. The kernel can return directly to the predefined UTS event > > handlers (also on a predefined stack) and totally bypass the original system > > call in which it entered the kernel. At some point later, the UTS resumes > > the (now unblocked) KSE and returns the same way it entered. > > > > You also want the ability to inform the UTS of _more_ than just one > > event at a time. Several KSEs may unblock before a subprocess is run. > > You should be able to notify the UTS of them all at once. How does > > that work in your method? > > This sounds similar to Solaris LWPs in that there are potentially KSEs > blocked in the kernel, whereas with scheduler activations (SA), that > doesn't happen under normal circumstances. Sure it does. And if an application has a lot of I/O bound threads, you want to inform the UTS of all the unblocked threads at once - some threads may have higher priority than other threads so let the UTS decide which one to resume. If you only notify the UTS of one unblocked thread at a time, then the kernel arbitrarily decides the priority. > It sounds to me like the > disagreement between you two (Daniel and Julian) is much more significant > than what decisions are made by the UTS. No, it's really only the issue of whether the we need a different syscall gate. > Daniel, you say "The UTS is > notified that a KSE has unblocked ...". However, if I understand the SA > way of doing things, there is no KSE associated with a blocked syscall. Well, up until now, we've been using KSE to mean the "saved kernel context, flags, queue management, and perhaps some portion of saved user context". A KSE is not a kernel thread or subprocess. I think we might be abusing this definition, because KSE seems more like a kernel thread. Perhaps we should be calling it kernel context or something. > The syscall context has some kernel context, but there is no bonifide > context, such as with Solaris's LWP model. When the syscall completes, a > new activation is created for the upcall to the UTS. > > That said, I disagree with the idea of the UTS having explicit control over > scheduling of KSEs. I think that there should be exactly one KSE per > processor (with the exception of PTHREAD_SCOPE_SYSTEM (bound) threads), and > that threads should be multiplexed onto the KSEs. This lets the kernel > schedule KSEs as it sees fit, and lets the UTS divide the runtime of the > KSEs as it sees fit. Yes, Julian and I agree on this, it's just that you're mixing up the terms that he and I were using. The application will have control over the priority of the subprocesses (or KSEs as you're calling them) by use of setpriority/rtprio if they have the proper privileges. I don't see the UTS having control of the subprocesses priority. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 25 3:22:11 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id CA01B14D80 for ; Thu, 25 Nov 1999 03:22:07 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id MAA21899 for ; Thu, 25 Nov 1999 12:22:05 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id MAA38728 for freebsd-arch@freebsd.org; Thu, 25 Nov 1999 12:22:05 +0100 (MET) Received: from tardis.patho.gen.nz (tardis.patho.gen.nz [203.97.2.226]) by hub.freebsd.org (Postfix) with ESMTP id 4C3F114D80 for ; Thu, 25 Nov 1999 03:21:50 -0800 (PST) (envelope-from jabley@tardis.patho.gen.nz) Received: (from jabley@localhost) by tardis.patho.gen.nz (8.9.3/8.9.3) id AAA24400 for freebsd-arch@freebsd.org; Fri, 26 Nov 1999 00:21:49 +1300 (NZDT) Date: Fri, 26 Nov 1999 00:21:48 +1300 From: Joe Abley To: freebsd-arch@freebsd.org Subject: Multiple MAC filters on a local multi-access interface Message-ID: <19991126002147.A10153@patho.gen.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0i X-Files: the Truth is Out There Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Is there an interface to: + determine whether a local multi-access interface (e.g. ethernet) is capable of filtering more than one unicast MAC address? + modify the MAC filter on a local interface? Application is support of VRRP (RFC2338), for which the virtual router addresses need to be associated with an overloaded (i.e. non-local) unicast MAC address. I'm hunting through the kernel, but have yet to find any clean interface to do this. I'm quite happy to implement such an interface, but some advice on an acceptable approach would be most welcome. Joe -- Ua lawa küpono ka hakahaka pä o këia pä malule To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 25 7:36:44 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id E952514E66 for ; Thu, 25 Nov 1999 07:36:34 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id QAA26536 for ; Thu, 25 Nov 1999 16:36:32 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA39820 for freebsd-arch@freebsd.org; Thu, 25 Nov 1999 16:36:32 +0100 (MET) Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id B6F8014CED; Thu, 25 Nov 1999 07:36:06 -0800 (PST) (envelope-from cy@cschuber.net.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id HAA12448; Thu, 25 Nov 1999 07:36:05 -0800 Received: from cschuber.net.gov.bc.ca(142.31.240.113), claiming to be "cwsys.cwsent.com" via SMTP by point.osg.gov.bc.ca, id smtpda12446; Thu Nov 25 07:35:47 1999 Received: (from uucp@localhost) by cwsys.cwsent.com (8.9.3/8.9.1) id HAA67071; Thu, 25 Nov 1999 07:34:03 -0800 (PST) Message-Id: <199911251534.HAA67071@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdD67066; Thu Nov 25 07:33:14 1999 X-Mailer: exmh version 2.1.1 10/15/1999 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 3.3-RELEASE X-Sender: cy To: Tony Landells Cc: ipfw@freebsd.org, arch@freebsd.org Subject: Re: new IPFW In-reply-to: Your message of "Thu, 25 Nov 1999 08:48:10 +1100." <199911242148.IAA25984@tungsten.austclear.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Nov 1999 07:33:13 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199911242148.IAA25984@tungsten.austclear.com.au>, Tony Landells wri tes: > I'd be much happier with something in ipfw that just marked the next line > number to be used, preferably in a way that I could get it to move to the > next "grouping"--like "set the next rule number to the next multiple of > 1000". This is what I use in one of my dialup scripts at home: #!/usr/local/bin/bash - # # Generic firewall routines. # fw() { set $@ if /sbin/ipfw -q $@; then : ; else /usr/bin/logger -t "net[$$]" -p auth.error error in: /sbin/ipfw -q $@ echo error in: /sbin/ipfw -q $@ fi } firewall() { set $@ fw add $NUMBER $@ let NUMBER=$NUMBER+1 } ... NUMBER=23000 fw add 29998 reset log ... firewall deny log ... firewall deny log ... ... NUMBER=1100 for SYSTEM in $SERVERS; do firewall divert natd ... out via $DEVICE firewall divert natd ... in via $DEVICE firewall accept ip ... out via $DEVICE firewall accept ip ... in via $DEVICE done ... Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Sun/DEC Team, UNIX Group Internet: Cy.Schubert@uumail.gov.bc.ca ITSD Cy.Schubert@gems8.gov.bc.ca Province of BC "e**(i*pi)+1=0" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 25 10:42:42 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id BDA0414BCD for ; Thu, 25 Nov 1999 10:42:16 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA28220 for ; Thu, 25 Nov 1999 19:42:13 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA40473 for freebsd-arch@freebsd.org; Thu, 25 Nov 1999 19:42:07 +0100 (MET) Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 65F4914DBB; Thu, 25 Nov 1999 10:39:48 -0800 (PST) (envelope-from rgrimes@gndrsh.dnsmgr.net) Received: (from rgrimes@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id KAA49143; Thu, 25 Nov 1999 10:39:24 -0800 (PST) (envelope-from rgrimes) From: "Rodney W. Grimes" Message-Id: <199911251839.KAA49143@gndrsh.dnsmgr.net> Subject: Re: new IPFW In-Reply-To: <199911251534.HAA67071@cwsys.cwsent.com> from Cy Schubert - ITSD Open Systems Group at "Nov 25, 1999 07:33:13 am" To: Cy.Schubert@uumail.gov.bc.ca (Cy Schubert - ITSD Open Systems Group) Date: Thu, 25 Nov 1999 10:39:23 -0800 (PST) Cc: ahl@austclear.com.au (Tony Landells), ipfw@freebsd.org, arch@freebsd.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In message <199911242148.IAA25984@tungsten.austclear.com.au>, Tony Landells wri > tes: > > I'd be much happier with something in ipfw that just marked the next line > > number to be used, preferably in a way that I could get it to move to the > > next "grouping"--like "set the next rule number to the next multiple of > > 1000". > > This is what I use in one of my dialup scripts at home: ... And here is another one thats designed to simply handling client/server type tcp and udp protocols it uses fixed rule bases and the port # as an offset. Makes for grepping specific types of accept log data from the ipfw.log files easier [Tab formats probably destroyed by cut-n-paste]: This is just a snippet of the whole file, but I think one can get the idea of what we did here. Note also this is a very open rule set in the calls to clnsrv, we mainly just monitor for suspecious activity. The contents of rc.firewall.conf is up to the reader to figure out... #!/bin/sh # GLOBALS to control things, like testing. Setting fire="echo" # is real nice for debugging. fire="/sbin/ipfw" fadd="${fire} add" # clnsrv(action, proto, sport, dport, clients, servers) clnsrv() { action=$1; shift proto=$1; shift sport=$1; shift dport=$1; shift clients=$1; shift servers=$1; shift if [ X"${proto}" = X"tcp" ]; then setup="setup" base=10000 else setup="" base=40000 fi if [ X"${dport}" = X"" ]; then ruleoffset=${sport} else ruleoffset=${dport} fi if [ ${ruleoffset} -gt 1899 ]; then ruleoffset=1900 fi rule=`expr ${base} + \( ${ruleoffset} \* 10 \)` for cln in ${clients} ; do for srv in ${servers} ; do from ${cln} ${sport} to ${srv} ${dport} ${setup} done done rule=`expr ${rule} + 9` ${fadd} ${rule} ${CLASS} log ${proto} from any ${sport} to any ${dport} } # Pull in the address variables from the conf file or error out if # there is not one (keeps one from shooting your feet off!) if [ -f /etc/rc.firewall.conf ]; then . /etc/rc.firewall.conf else echo "$0 - no rc.firewall.conf file!!! Not loading!!!" exit 1 fi ... [basic stuff for lo0, rfc1918, and some other not so public data] ... ################################################################################ # TCP/* # ${fadd} 10000 allow tcp from any to any established clnsrv "allow " tcp 20 "" "${tcp_ftpdata_c}" "${tcp_ftpdata_s}" clnsrv "allow " tcp "" 21 "${tcp_ftp_c}" "${tcp_ftp_s}" clnsrv "allow " tcp "" 22 "${tcp_ssh_c}" "${tcp_ssh_s}" clnsrv "allow " tcp "" 23 "${tcp_telnet_c}" "${tcp_telnet_s}" clnsrv "allow " tcp "" 25 "${tcp_smtp_c}" "${tcp_smtp_s}" clnsrv "allow " tcp "" 43 "${tcp_nicname_c}" "${tcp_nicname_s}" clnsrv "allow " tcp "" 53 "${tcp_domain_c}" "${tcp_domain_s}" clnsrv "allow " tcp "" 79 "${tcp_finger_c}" "${tcp_finger_s}" clnsrv "allow " tcp "" 80 "${tcp_http_c}" "${tcp_http_s}" clnsrv "allow " tcp "" 110 "${tcp_pop3_c}" "${tcp_pop3_s}" clnsrv "allow " tcp "" 111 "${tcp_sunrpc_c}" "${tcp_sunrpc_s}" clnsrv "allow " tcp "" 113 "${tcp_auth_c}" "${tcp_auth_s}" clnsrv "allow " tcp "" 119 "${tcp_nntp_c}" "${tcp_nntp_s}" clnsrv "allow " tcp "" 123 "${tcp_ntp_c}" "${tcp_ntp_s}" clnsrv "allow " tcp "" 137 "${tcp_netbios_ns_c}" "${tcp_netbios_ns_s}" clnsrv "allow " tcp "" 138 "${tcp_netbios_dgm_c}" "${tcp_netbios_dgm_s}" clnsrv "allow " tcp "" 139 "${tcp_netbios_ssn_c}" "${tcp_netbios_ssn_s}" clnsrv "allow " tcp "" 179 "${tcp_bgp_c}" "${tcp_bgp_s}" clnsrv "allow " tcp "" 443 "${tcp_https_c}" "${tcp_https_s}" clnsrv "allow " tcp "" 515 "${tcp_printer_c}" "${tcp_printer_s}" clnsrv "allow " tcp "" 5190 "${tcp_aol_c}" "${tcp_aol_s}" # XXX For now log all other TCP setups ${fadd} 29999 allow log tcp from any to any setup ################################################################################ # UDP/* # clnsrv "allow " udp "" 53 "${udp_domain_c}" "${udp_domain_s}" clnsrv "allow " udp 53 "" "${udp_domain_s}" "${udp_domain_c}" clnsrv "allow " udp "" 123 "${udp_ntp_c}" "${udp_ntp_s}" clnsrv "allow " udp "" 137 "${udp_netbios_ns_c}" "${udp_netbios_ns_s}" clnsrv "allow " udp "" 138 "${udp_netbios_dgm_c}" "${udp_netbios_dgm_s}" clnsrv "allow log" udp "" 139 "${udp_netbios_ssn_c}" "${udp_netbios_ssn_s}" clnsrv "allow " udp "" 161 "${udp_snmp_c}" "${udp_snmp_s}" clnsrv "allow " udp 161 "" "${udp_snmp_s}" "${udp_snmp_c}" clnsrv "allow " udp "" 162 "${udp_snmptrap_c}" "${udp_snmptrap_s}" clnsrv "allow " udp 162 "" "${udp_snmptrap_s}" "${udp_snmptrap_c}" clnsrv "allow " udp "" 512 "${udp_biff_c}" "${udp_biff_s}" clnsrv "allow " udp "" 513 "${udp_who_c}" "${udp_who_s}" clnsrv "allow " udp "" 514 "${udp_syslog_c}" "${udp_syslog_s}" clnsrv "allow " udp "" 515 "${udp_printer_c}" "${udp_printer_s}" clnsrv "allow " udp "" 516 "${udp_videotex_c}" "${udp_videotex_s}" clnsrv "allow " udp "" 517 "${udp_talk_c}" "${udp_talk_s}" clnsrv "allow " udp "" 518 "${udp_ntalk_c}" "${udp_ntalk_s}" clnsrv "allow " udp "" 519 "${udp_utime_c}" "${udp_utime_s}" clnsrv "allow " udp "" 520 "${udp_router_c}" "${udp_router_s}" clnsrv "allow " udp "" 521 "${udp_ripng_c}" "${udp_ripng_s}" clnsrv "allow " udp 1645 1645 "${udp_radius_c}" "${udp_radius_s}" clnsrv "allow " udp 1645 1645 "${udp_radius_s}" "${udp_radius_c}" clnsrv "allow " udp 1646 1646 "${udp_radacct_c}" "${udp_radacct_s}" clnsrv "allow " udp 1646 1646 "${udp_radacct_s}" "${udp_radacct_c}" clnsrv "allow " udp 1812 1812 "${udp_radius_c}" "${udp_radius_s}" clnsrv "allow " udp 1812 1812 "${udp_radius_s}" "${udp_radius_c}" clnsrv "allow " udp 1813 1813 "${udp_radacct_c}" "${udp_radacct_s}" clnsrv "allow " udp 1813 1813 "${udp_radacct_s}" "${udp_radacct_c}" clnsrv "allow " udp "" 4000 "${udp_4000_c}" "${udp_4000_s}" clnsrv "allow " udp 4000 "" "${udp_4000_s}" "${udp_4000_c}" ${fadd} 59999 allow log udp from any to any much much more below here deleted... -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 25 11:41:30 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 1176514D9F for ; Thu, 25 Nov 1999 11:41:27 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA28616 for ; Thu, 25 Nov 1999 20:41:26 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA40923 for freebsd-arch@freebsd.org; Thu, 25 Nov 1999 20:41:26 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 9B4FD14C86; Thu, 25 Nov 1999 11:41:13 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id LAA73476; Thu, 25 Nov 1999 11:40:58 -0800 (PST) Date: Thu, 25 Nov 1999 11:40:58 -0800 (PST) From: Julian Elischer To: Cy Schubert - ITSD Open Systems Group Cc: Tony Landells , ipfw@freebsd.org, arch@freebsd.org Subject: Re: new IPFW In-Reply-To: <199911251534.HAA67071@cwsys.cwsent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 25 Nov 1999, Cy Schubert - ITSD Open Systems Group wrote: > In message <199911242148.IAA25984@tungsten.austclear.com.au>, Tony Landells wri > tes: > > I'd be much happier with something in ipfw that just marked the next line > > number to be used, preferably in a way that I could get it to move to the > > next "grouping"--like "set the next rule number to the next multiple of > > 1000". have you tried this? ipfw will add new un-numbered rules on the next 100 boundary after the rule you specified. > > This is what I use in one of my dialup scripts at home: > > #!/usr/local/bin/bash - > # > # Generic firewall routines. > # > fw() { > set $@ > if /sbin/ipfw -q $@; then : ; else > /usr/bin/logger -t "net[$$]" -p auth.error error in: /sbin/ipfw > -q $@ > echo error in: /sbin/ipfw -q $@ > fi > } > > firewall() { > set $@ > fw add $NUMBER $@ > let NUMBER=$NUMBER+1 > } > ... > NUMBER=23000 > fw add 29998 reset log ... > firewall deny log ... > firewall deny log ... > ... > NUMBER=1100 > for SYSTEM in $SERVERS; do > firewall divert natd ... out via $DEVICE > firewall divert natd ... in via $DEVICE > firewall accept ip ... out via $DEVICE > firewall accept ip ... in via $DEVICE > done > ... > > > Regards, Phone: (250)387-8437 > Cy Schubert Fax: (250)387-5766 > Sun/DEC Team, UNIX Group Internet: Cy.Schubert@uumail.gov.bc.ca > ITSD Cy.Schubert@gems8.gov.bc.ca > Province of BC > "e**(i*pi)+1=0" > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 25 13:12:38 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 67B2714C99 for ; Thu, 25 Nov 1999 13:12:35 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA29120 for ; Thu, 25 Nov 1999 22:12:15 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA41279 for freebsd-arch@freebsd.org; Thu, 25 Nov 1999 22:12:14 +0100 (MET) Received: from awfulhak.org (dynamic-17.max4-du-ws.dialnetwork.pavilion.co.uk [212.74.9.145]) by hub.freebsd.org (Postfix) with ESMTP id 216CA14C99; Thu, 25 Nov 1999 13:12:05 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by awfulhak.org (8.9.3/8.9.3) with ESMTP id VAA01069; Thu, 25 Nov 1999 21:12:02 GMT (envelope-from brian@lan.awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost.lan.Awfulhak.org [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id JAA00527; Thu, 25 Nov 1999 09:44:58 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <199911250944.JAA00527@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.0 09/18/1999 To: "Louis A. Mamakos" Cc: Julian Elischer , "Rodney W. Grimes" , Tony Landells , ipfw@freebsd.org, arch@freebsd.org, brian@hak.lan.Awfulhak.org Subject: Re: new IPFW In-Reply-To: Message from "Louis A. Mamakos" of "Wed, 24 Nov 1999 18:50:56 EST." <199911242350.SAA21464@whizzo.transsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Nov 1999 09:44:58 +0000 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > [as I don my pointy, er, UUNET hat..] > > > Louis, have you looked at the pppoe node? (as you are the author > > of the RFC I'd like your comments) > > I've looked at the PPPOE node and the pppoed daemon code recently > check in. I'm going to try to set up a FreeBSD test environment in > my lab and play with it. We just moved a few weeks ago, and are trying > to recover from the chaos of that :-( There's an example in share/examples/ppp/ppp.conf.sample. [.....] > louie > (a.k.a. louie@UU.NET) -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 25 13:22:46 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 8F10114E9C for ; Thu, 25 Nov 1999 13:22:40 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA29184 for ; Thu, 25 Nov 1999 22:22:39 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA41332 for freebsd-arch@freebsd.org; Thu, 25 Nov 1999 22:22:39 +0100 (MET) Received: from gvr.gvr.org (gvr.gvr.org [194.151.74.97]) by hub.freebsd.org (Postfix) with ESMTP id 4EE9B14C99; Thu, 25 Nov 1999 13:22:30 -0800 (PST) (envelope-from guido@gvr.org) Received: by gvr.gvr.org (Postfix, from userid 657) id AE51CA84A; Thu, 25 Nov 1999 22:22:29 +0100 (CET) Date: Thu, 25 Nov 1999 22:22:29 +0100 From: Guido van Rooij To: Kris Kennaway Cc: Julian Elischer , "Rodney W. Grimes" , Brian Fundakowski Feldman , arch@freebsd.org Subject: Re: new IPFW Message-ID: <19991125222229.A55360@gvr.gvr.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: ; from Kris Kennaway on Thu, Nov 25, 1999 at 01:30:53AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Nov 25, 1999 at 01:30:53AM -0800, Kris Kennaway wrote: > > On another track, someone already raised the issue of ipfilter - this is > as close to a standard as there is in the UNIX firewalling world > (especially as the other BSDs use it exclusively). Of course, basing work > on ipfilter isn't necessarily compatible with revolutionising the guts of > the code, but we could provide a compatible interface. An ipfw->ipfilter > rule translator can't be that difficult (I'm assuming the ipfilter > functionality is a superset of ipfw, which seems to be at least > approximately true). Darren Reed also makes a filter compilr that can output ipfilter stuff, cisco access lists etc. Perhaps it's worthwhile to add ipfw support. I believe ne can find it at http://coombs.anu.edu.au/~avalon/ -Guido To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 25 22:52:15 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id B7B5A14E1F for ; Thu, 25 Nov 1999 22:52:11 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id HAA05879 for ; Fri, 26 Nov 1999 07:52:08 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id HAA42712 for freebsd-arch@freebsd.org; Fri, 26 Nov 1999 07:52:08 +0100 (MET) Received: from staff.accessus.net (staff.accessus.net [209.145.151.3]) by hub.freebsd.org (Postfix) with ESMTP id CC70714D93; Thu, 25 Nov 1999 22:51:43 -0800 (PST) (envelope-from doogie@staff.accessus.net) Received: by staff.accessus.net with Internet Mail Service (5.5.2650.21) id ; Fri, 26 Nov 1999 00:51:42 -0600 Message-ID: From: Jason Young To: "'Brian Fundakowski Feldman'" , ipfw@freebsd.org Cc: arch@freebsd.org Subject: RE: new IPFW Date: Fri, 26 Nov 1999 00:51:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF37DA.B217A81A" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF37DA.B217A81A Content-Type: text/plain; charset="iso-8859-1" I've had the privelege of using BSD/OS 4.0's firewalling code, and it's incredibly powerful. It's based on BPF. You actually write one or more filtering "programs" of sorts that get run through the C preprocessor and run as a BPF filter. I wish I had some docs on it handy to post here. There were several places to plug filters in - pre-input, input, input for the machine, pre-output and output, the input/output ones being per-interface (again, if I recall correctly). The pre-input phase was for dealing with fragmentation and some other things, and the input stage would present all packets reassembled, etc. This let you compile and emplace rulesets to be run exactly when and where you need them to be run. It's morally wrong to just rip off the code from BSDI, but if I had to pick just one piece of code for something to steal from somewhere, for any purpose, this would be it hands down. It's just incredibly elegant. It's The Way To Go(tm). If a BPF-like solution isn't adopted, I would say that per-interface rulesets would be my number one wish. > -----Original Message----- > From: Brian Fundakowski Feldman [mailto:green@freebsd.org] > Sent: Wednesday, November 24, 1999 12:33 AM > To: ipfw@freebsd.org > Cc: arch@freebsd.org > Subject: new IPFW > > > I've finally sat myself down to take the first step in getting the new > IPFW done. I'll start by listing some of the different ideas > I've had, [snip] ------_=_NextPart_001_01BF37DA.B217A81A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: new IPFW

I've had the privelege of using BSD/OS 4.0's = firewalling code, and it's incredibly powerful. It's based on BPF. You = actually write one or more filtering "programs" of sorts that = get run through the C preprocessor and run as a BPF filter.

I wish I had some docs on it handy to post here. = There were several places to plug filters in - pre-input, input, input = for the machine, pre-output and output, the input/output ones being = per-interface (again, if I recall correctly). The pre-input phase was = for dealing with fragmentation and some other things, and the input = stage would present all packets reassembled, etc. This let you compile = and emplace rulesets to be run exactly when and where you need them to = be run.

It's morally wrong to just rip off the code from = BSDI, but if I had to pick just one piece of code for something to = steal from somewhere, for any purpose, this would be it hands down. = It's just incredibly elegant. It's The Way To Go(tm).

If a BPF-like solution isn't adopted, I would say = that per-interface rulesets would be my number one wish.

> -----Original Message-----
> From: Brian Fundakowski Feldman [mailto:green@freebsd.org]
> Sent: Wednesday, November 24, 1999 12:33 = AM
> To: ipfw@freebsd.org
> Cc: arch@freebsd.org
> Subject: new IPFW
>
>
> I've finally sat myself down to take the first = step in getting the new
> IPFW done.  I'll start by listing some of = the different ideas
> I've had,
[snip]

------_=_NextPart_001_01BF37DA.B217A81A-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 26 2:56:35 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3000614E9A for ; Fri, 26 Nov 1999 02:56:32 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id LAA09837 for ; Fri, 26 Nov 1999 11:56:30 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id LAA43361 for freebsd-arch@freebsd.org; Fri, 26 Nov 1999 11:56:26 +0100 (MET) Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 23B2C14E9A for ; Fri, 26 Nov 1999 02:56:13 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id LAA82178; Fri, 26 Nov 1999 11:01:26 GMT (envelope-from dfr@nlsystems.com) Date: Fri, 26 Nov 1999 11:01:26 +0000 (GMT) From: Doug Rabson To: Jason Evans Cc: Anthony Kimball , freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: <19991124141718.Q301@sturm.canonware.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 24 Nov 1999, Jason Evans wrote: > On Wed, Nov 24, 1999 at 02:47:22PM -0600, Anthony Kimball wrote: > > Quoth Julian Elischer on Wed, 24 November: > > : > And I just hate to think of the crocks that debuggers will need to have to > > : > be aware of this thread multiplexing going on in user space. > > : > > : That is a worry certainly. But it was solved for Solaris > > > > For some value of 'solved' ;-) > > Debugging multi-threaded applications is just plain complex. I've found > gdb's threads support on Solaris to be surprisingly good. I for one will > be really happy if threads debugging is that well supported on FreeBSD. I'm planning to finish off my gdb thread support tomorrow and commit it. Could you take over maintenance after? -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 26 10:35:35 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id CAE7915041 for ; Fri, 26 Nov 1999 10:35:30 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA16087 for ; Fri, 26 Nov 1999 19:35:29 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA45457 for freebsd-arch@freebsd.org; Fri, 26 Nov 1999 19:35:28 +0100 (MET) Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id C6F69151D8 for ; Fri, 26 Nov 1999 10:34:52 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id KAA13630; Fri, 26 Nov 1999 10:34:17 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) To: Doug Rabson Cc: Jason Evans , Anthony Kimball , freebsd-arch@freebsd.org Subject: Re: Threads In-reply-to: Your message of "Fri, 26 Nov 1999 11:01:26 GMT." Date: Fri, 26 Nov 1999 10:34:17 -0800 Message-ID: <13626.943641257@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Debugging multi-threaded applications is just plain complex. I've found > > gdb's threads support on Solaris to be surprisingly good. I for one will > > be really happy if threads debugging is that well supported on FreeBSD. > > I'm planning to finish off my gdb thread support tomorrow and commit it. > Could you take over maintenance after? Don't forget Ron's offer to take over gdb support entirely - perhaps you and Jason could coordinate the hand-over with him? I'm sure he wouldn't mind Jason's threads expertise, but he'll need to know what's going on if he's to be an effective maintainer. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 26 12:12:57 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id C9BCC15189 for ; Fri, 26 Nov 1999 12:12:54 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA16985 for ; Fri, 26 Nov 1999 21:12:53 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA46277 for freebsd-arch@freebsd.org; Fri, 26 Nov 1999 21:12:53 +0100 (MET) Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 5A4C915182 for ; Fri, 26 Nov 1999 12:10:54 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id UAA17434; Fri, 26 Nov 1999 20:16:15 GMT (envelope-from dfr@nlsystems.com) Date: Fri, 26 Nov 1999 20:16:14 +0000 (GMT) From: Doug Rabson To: "Jordan K. Hubbard" Cc: Jason Evans , Anthony Kimball , freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: <13626.943641257@zippy.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 26 Nov 1999, Jordan K. Hubbard wrote: > > > Debugging multi-threaded applications is just plain complex. I've found > > > gdb's threads support on Solaris to be surprisingly good. I for one will > > > be really happy if threads debugging is that well supported on FreeBSD. > > > > I'm planning to finish off my gdb thread support tomorrow and commit it. > > Could you take over maintenance after? > > Don't forget Ron's offer to take over gdb support entirely - perhaps you > and Jason could coordinate the hand-over with him? I'm sure he wouldn't > mind Jason's threads expertise, but he'll need to know what's going on > if he's to be an effective maintainer. Of course. I'm also talking to Ron and getting him up to speed with the strange (to him) way that the FreeBSD source tree is put together. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 26 14:47:43 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 7B36C151C8 for ; Fri, 26 Nov 1999 14:47:40 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA18361 for ; Fri, 26 Nov 1999 23:47:39 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA47171 for freebsd-arch@freebsd.org; Fri, 26 Nov 1999 23:47:32 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 498EA151C8 for ; Fri, 26 Nov 1999 14:47:13 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id OAA93183 for ; Fri, 26 Nov 1999 14:47:13 -0800 (PST) Date: Fri, 26 Nov 1999 14:47:13 -0800 (PST) From: Julian Elischer To: arch@freebsd.org Subject: Re: Threads diagrams Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG first round diagrams.. (gee I find xfig unintuitive.. give me tgif any day) :-) ---------- Forwarded message ---------- Date: Fri, 26 Nov 1999 16:19:18 -0500 From: Daniel M. Eischen To: Julian Elischer Subject: Re: Threads stuff The updated diagram is at: http://freefall.freebsd.org/~deischen/figs/thr_overview.jpg xfig version: http://freefall.freebsd.org/~deischen/figs/thr_overview.fig Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 26 14:49:32 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 98BD71528C for ; Fri, 26 Nov 1999 14:49:30 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA18378 for ; Fri, 26 Nov 1999 23:49:29 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA47198 for freebsd-arch@freebsd.org; Fri, 26 Nov 1999 23:49:29 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id BF1181527B for ; Fri, 26 Nov 1999 14:49:21 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id OAA93210 for ; Fri, 26 Nov 1999 14:49:21 -0800 (PST) Date: Fri, 26 Nov 1999 14:49:21 -0800 (PST) From: Julian Elischer To: arch@freebsd.org Subject: Re: Threads diagrams. (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ---------- Forwarded message ---------- Date: Fri, 26 Nov 1999 15:55:42 -0500 From: Daniel M. Eischen To: Julian Elischer Subject: Re: Threads stuff Julian Elischer wrote: > Ok I fetched it and have been looking at it. > > comments: > > circles P1 and P2 are? Just the UTS' view of its allocated subprocesses. The UTS asks the kernel (or rforks) for additional subprocesses. Either P1 or P2 is the main process, and the other one is the rfork'd process. > I assume the two boxes are the subprocesses that the program has forked to > give itself parallelism. Yes. > > there are two aync nootify contexts because there is one per subprocess > right? Yes. > > kse_current.. > ok > > kse_notify.. > this is effectively the saved context that will be used to upcall? Yes. There is only one for now, there may be a need for more than one though. > > kse_unblockedq > ok > > kse_blockedq.. > hmmm maybe.. the KSE's that are blocked are onthe sleep queues but I guess > you need a way of being able to find them, so, ok.. Right. The UTS might also want to cancel them. > I presume that t4, t6, and t9 are blocked in userspace.. No, those are blocked in kernel space. Their respective KSEs are shown hung off of proc P1 and P2. Oops, the kse_blockedq and kse_unblockedq tags on proc P1 are reversed. P1->kse_blockedq should read kse_unblockedq, and P1->kse_unblockedq should read kse_blockedq. > can we presume that threads blocked in user space and threads blocked in the > kernel are indetical? (At this moment I don't think we can, though it is a > design goal') Threads blocked in user space (let's say waiting on a mutex), don't have a KSE. There are only KSEs for threads blocked in the kernel, the UTS event notifications, and the currently running threads. When a thread blocked in user space unblocks, the UTS can simply do a _longjmp to resume it (using the same KSE as the thread being swapped out). Perhaps we should show examples of threads blocked in user space in the diagram also. I don't think we want to require a kernel call to resume a thread that is blocked in user space, right? And I really don't think we want KSEs for every thread in an application, right? So other than the above, threads blocked in user space and threads blocked in kernel space are exactly the same. There will just be a flag and perhaps KSE ID in the user thread struct to indicate whether it can be resumed with a _longjmp or a thread_resume(2). > > kde_freeq.. > I don't think this is needed. we can have a systemwide cache of free KSEs > without much problem, and even a per-processor cache maybe.. Good point. I'll remove them. We might want the proc to know the maximum number of KSEs it's suppose to have, though. Consider thread groups and subprocesses at other-than-default-priority. Once a processes blocked KSE limit is reached, the process can be put to sleep until at least one of the KSEs wakeup. > > We need some more diagrams, but I wanted to make sure we're in > > general agreement before I make any more. > > basically I agree. > I had an interesting thought yesterday.. > > If every thread stores all it's context on the end of it's stack, then > we only have to store the stack right? OK, makes sense. > so at teh moment using the current system call-gate, we store all teh > context in the kernel stack, Hmm, I was under the impression it was on the USER stack. Isn't that why we have to copyin/copyout to access the trapframe from the kernel? > but if we were to save it onto the USER stack before it did the > KERNCALL, and didn't do it onto the kernel stack > then the information we needed to move a blocked syscall thread onto the > blocked thread list (as you show) would already all be in the right place. > returned values would be placed into a separate async completion block > that is allocated at the beginning of every thread's stack rather than > straight into the context. Basically this all happens anyhow, but > at the present it's all done on the kernel side of the line. > I suggest instead moving it to the user side, and making each syscall > load it's return values from the status block after it returns from the > kernel. ERRNO lives in the block permanently and need not be moved out. I think I follow you, but diagrams would help :-) Would there be some sort of unique ID returned from a blocked syscall, so that the UTS could later resume/cancel the thread? > This is the kind of thing that mean when I say that using a different > protocol might make sense. I'm open to the idea, but it just seems like there might be a real easy and fast way to switch to a predefined context/trapframe that would take us directly to the UTS. The only thing the UTS needs to know is what process blocked and a unique ID for resuming/suspending the blocked system call. Based on which process blocked, the UTS will know what thread blocked, and can tag it with the unique ID and place it in the blocked queue. For threads that are preempted, you can additionally send the program counter so the UTS can decide if it was in a critical region. > what are you using to make the drawings? > If it's tgif or xfig, then maybe we can get at the sources so we can > submit suggestions for changes in picture format :-) I'm using xfig. I wish there was something better, though. Let me make your changes, and I'll send you the .fig file. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 26 14:50:44 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 6F4321527C for ; Fri, 26 Nov 1999 14:50:41 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA18393 for ; Fri, 26 Nov 1999 23:50:41 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA47222 for freebsd-arch@freebsd.org; Fri, 26 Nov 1999 23:50:41 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id A0A891528A for ; Fri, 26 Nov 1999 14:50:32 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id OAA93252 for ; Fri, 26 Nov 1999 14:50:32 -0800 (PST) Date: Fri, 26 Nov 1999 14:50:31 -0800 (PST) From: Julian Elischer To: arch@freebsd.org Subject: Re: Threads stuff (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ---------- Forwarded message ---------- Date: Fri, 26 Nov 1999 13:42:34 -0800 (PST) From: Julian Elischer To: Daniel M. Eischen Subject: Re: Threads stuff On Fri, 26 Nov 1999, Daniel M. Eischen wrote: > Julian Elischer wrote: > > Ok I fetched it and have been looking at it. > > > > comments: > > > > circles P1 and P2 are? > > Just the UTS' view of its allocated subprocesses. The UTS asks the kernel > (or rforks) for additional subprocesses. Either P1 or P2 is the main > process, and the other one is the rfork'd process. > > > I assume the two boxes are the subprocesses that the program has forked to > > give itself parallelism. > > Yes. > > > > > there are two aync nootify contexts because there is one per subprocess > > right? > > Yes. > > > > > kse_current.. > > ok > > > > kse_notify.. > > this is effectively the saved context that will be used to upcall? > > Yes. There is only one for now, there may be a need for more than one > though. > > > > > kse_unblockedq > > ok > > > > kse_blockedq.. > > hmmm maybe.. the KSE's that are blocked are onthe sleep queues but I guess > > you need a way of being able to find them, so, ok.. > > Right. The UTS might also want to cancel them. > > > I presume that t4, t6, and t9 are blocked in userspace.. > I screwed up reading it.. ignore that one.. > No, those are blocked in kernel space. Their respective KSEs are > shown hung off of proc P1 and P2. Oops, the kse_blockedq and > kse_unblockedq tags on proc P1 are reversed. P1->kse_blockedq > should read kse_unblockedq, and P1->kse_unblockedq should read > kse_blockedq. ok but then in your diagram you should show some threads blocked in userland as well. > > > can we presume that threads blocked in user space and threads blocked in the > > kernel are indetical? (At this moment I don't think we can, though it is a > > design goal') > > Threads blocked in user space (let's say waiting on a mutex), don't > have a KSE. exactly. But I was thinking of what context the UTS had access to for the thread. For example, could the UTS time-out an IO and return a 'failed' result and restart a thread that had made an IO request, even though the IO hadn't returned? If all the context that was needed to restart a thread blocked in the kernel was available to teh UTS then that saved thread info must be pretty much the same as what a thread blocked in the userland must be. > There are only KSEs for threads blocked in the kernel, > the UTS event notifications, and the currently running threads. agreed > When > a thread blocked in user space unblocks, the UTS can simply do a > _longjmp to resume it (using the same KSE as the thread being swapped > out). Perhaps we should show examples of threads blocked in user > space in the diagram also. yes that was my comment above. > > I don't think we want to require a kernel call to resume a thread > that is blocked in user space, right? And I really don't think we > want KSEs for every thread in an application, right? no, though you are suggesting it in other email because you say you need to block/unblock signals, and your {s,g}et_context calls would require it. > > So other than the above, threads blocked in user space and threads > blocked in kernel space are exactly the same. There will just be > a flag and perhaps KSE ID in the user thread struct to indicate > whether it can be resumed with a _longjmp or a thread_resume(2). After a UTS has been notified that a thread has blocked in the kernel, it should end up being identical to one that is blocked in user space, except it is waiting on an event that the kernel must supply (i.e. an IO completion block or something.) Until it is notified of the blocking it is 'running' > > > > > kde_freeq.. > > I don't think this is needed. we can have a systemwide cache of free KSEs > > without much problem, and even a per-processor cache maybe.. > > Good point. I'll remove them. We might want the proc to know the > maximum number of KSEs it's suppose to have, though. Consider > thread groups and subprocesses at other-than-default-priority. > Once a processes blocked KSE limit is reached, the process can > be put to sleep until at least one of the KSEs wakeup. sure > > > > We need some more diagrams, but I wanted to make sure we're in > > > general agreement before I make any more. > > > > basically I agree. > > I had an interesting thought yesterday.. > > > > If every thread stores all it's context on the end of it's stack, then > > we only have to store the stack right? > > OK, makes sense. > > > so at teh moment using the current system call-gate, we store all teh > > context in the kernel stack, > > Hmm, I was under the impression it was on the USER stack. Isn't > that why we have to copyin/copyout to access the trapframe from > the kernel? I need my x86 book, but it's at work.. /* * Call gate entry for FreeBSD ELF Linux/NetBSD syscall (int 0x80) */ SUPERALIGN_TEXT IDTVEC(int0x80_syscall) subl $8,%esp /* skip over tf_trapno and tf_err */ pushal <---- pushl %ds <---- pushl %es <---- pushl %fs <---- movl $KDSEL,%eax /* switch to kernel segments */ movl %ax,%ds movl %ax,%es MOVL_KPSEL_EAX movl %ax,%fs movl $2,TF_ERR(%esp) /* sizeof "int 0x80" */ FAKE_MCOUNT(13*4(%esp)) MPLOCKED incl _cnt+V_SYSCALL ALTSYSCALL_LOCK call _syscall and in ipl.s in doreti() .globl doreti_popl_fs doreti_popl_fs: popl %fs .globl doreti_popl_es doreti_popl_es: popl %es .globl doreti_popl_ds doreti_popl_ds: popl %ds popal addl $8,%esp .globl doreti_iret doreti_iret: iret we've already switched to the kernel stack. and we save all the regs (pushal) abd then the segment registers. the stack segment has already been changed I think. Of course if I need my x86 book it might not work for alpha.. but if the syscall itself did: (this is my version of the 'syscall()' syscall.) ENTRY(syscall) pop %ecx /* rta */ pop %eax /* syscall number */ push %ecx pushal <----------- pushl %ds <----------- pushl %es <----------- pushl %fs <----------- KERNCALL call _UTS_syscall_end <----------- may decide to schedule something else. popal <----------- popl %fs <----------- popl %es <----------- popl %ds <----------- push %ecx /* need to push a word to keep stack frame intact upon return; the word must be the return address. */ jb 1f ret 1: PIC_PROLOGUE jmp PIC_PLT(HIDENAME(cerror)) <-- not needed.. already in return status b then the same stuff would not be needed in the first code segment and all that context would be available to the UTS immediatly without needing it to cross the kernel boundary at all. The only problem I see is we would have to be very careful about getting a pagefault while saving it.. pagefaults on stack segments are allowed to block? > > > but if we were to save it onto the USER stack before it did the > > KERNCALL, and didn't do it onto the kernel stack > > then the information we needed to move a blocked syscall thread onto the > > blocked thread list (as you show) would already all be in the right place. > > returned values would be placed into a separate async completion block > > that is allocated at the beginning of every thread's stack rather than > > straight into the context. Basically this all happens anyhow, but > > at the present it's all done on the kernel side of the line. > > I suggest instead moving it to the user side, and making each syscall > > load it's return values from the status block after it returns from the > > kernel. ERRNO lives in the block permanently and need not be moved out. > > I think I follow you, but diagrams would help :-) Would there be some > sort of unique ID returned from a blocked syscall, so that the UTS could > later resume/cancel the thread? the blockage notification is from the syscall you think you are doing. > > > This is the kind of thing that mean when I say that using a different > > protocol might make sense. > > I'm open to the idea, but it just seems like there might be a real > easy and fast way to switch to a predefined context/trapframe that > would take us directly to the UTS. The only thing the UTS needs > to know is what process blocked and a unique ID for resuming/suspending > the blocked system call. Based on which process blocked, the UTS > will know what thread blocked, and can tag it with the unique ID > and place it in the blocked queue. For threads that are preempted, > you can additionally send the program counter so the UTS can decide > if it was in a critical region. > > > what are you using to make the drawings? > > If it's tgif or xfig, then maybe we can get at the sources so we can > > submit suggestions for changes in picture format :-) > > I'm using xfig. I wish there was something better, though. Let me > make your changes, and I'll send you the .fig file. > > Dan Eischen > eischen@vigrid.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 26 14:52:39 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 684121528C for ; Fri, 26 Nov 1999 14:52:36 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA18424 for ; Fri, 26 Nov 1999 23:52:36 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA47282 for freebsd-arch@freebsd.org; Fri, 26 Nov 1999 23:52:36 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 3CE8C1528C for ; Fri, 26 Nov 1999 14:52:30 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id OAA93274 for ; Fri, 26 Nov 1999 14:52:29 -0800 (PST) Date: Fri, 26 Nov 1999 14:52:29 -0800 (PST) From: Julian Elischer To: arch@freebsd.org Subject: Re: Threads stuff (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ---------- Forwarded message ---------- Date: Fri, 26 Nov 1999 12:59:28 -0800 (PST) From: Julian Elischer To: Daniel M. Eischen Subject: Re: Threads stuff Mind if I forward this to arch? we seem to have gone 'off the record' [dan says ok] (I just want to have everything 'on the record so people can catch up if needs be) On Fri, 26 Nov 1999, Daniel M. Eischen wrote: > Julian Elischer wrote: > > > > Dan, I've been reading your context stuff. > > (in ~deischen/public_html on freefall) > > It's not up to date, but probably close enough to discuss. > > > I'm very confused about it.. > > I don't understand what it's for.. > > It's basically a setjmp/longjmp, but done from the kernel. > It could probably be done from libc like setjmp/longjmp, > but as long as you have to make a system call to set the > signal mask, it might as well be it's own system call. > Solaris and True64 UNIX both have getcontext(2) and > setcontext(2) system calls. > > http://www.opengroup.org/onlinepubs/7908799/xsh/getcontext.html > http://www.unix.digital.com/faqs/publications/base_doc/DOCUMENTATION/V50_HTML/MAN/MAN2/INDEX.HTM > http://docs.sun.com:80/ab2/coll.40.5/REFMAN2/@Ab2TocView?Ab2Lang=C&Ab2Enc=iso-8859-1 > > I found the Solaris manpages for _lwp_makecontext(2) and > _lwp_create(2) interesting. > > One of my comments to Marcels signal changes was to use > a ucontext_t in signal handling so we would be able to > support {set|get|make|swap}context. > > > my reading of it is that it only sets and gets context from > > the process that is running, and since the process is > > running teh context in teh proc structure is of no interest.. > > Whether a running process is making a call to getcontext(2) or > a call to read(2), it's context can be retrieved in the same > way. So if a read(2) blocks, the kernel can switch to a new > context (similar to setcontext) that was provided at UTS > initialization. > > This was my original idea as to how the kernel could switch to > a new context when the process blocked. But this would involve > copying in and saving the current trapframe from the system > call that blocked, and copying out a new trapframe (destroying > the original trapframe). It seems like it would be much easier > to leave the current trapframe intact, and just change the > kernels pointer to a new trapframe that has already been set up. > What do you think? > > > Now I know that you wouldn't go to so much work for such a thing > > so I'm obviously misunderstand it.. > > Hmm, maybe I _am_ confused :-) > > > do you have any man-pages or docs as to how/why/where/when > > this is to be used? > > Yep, see above. I'll attach a test program that I used to verify > my implementation. > > Dan Eischen > eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 26 15: 7:48 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3922E152AE for ; Fri, 26 Nov 1999 15:07:45 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA18493 for ; Sat, 27 Nov 1999 00:07:44 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA47351 for freebsd-arch@freebsd.org; Sat, 27 Nov 1999 00:07:44 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id D226D152AE for ; Fri, 26 Nov 1999 15:07:36 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt30.pcnet.net [206.105.29.104]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id SAA22215; Fri, 26 Nov 1999 18:07:37 -0500 (EST) Message-ID: <383F12B4.DB0AC9C0@vigrid.com> Date: Fri, 26 Nov 1999 18:07:32 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: [Fwd: Threads stuff] Content-Type: multipart/mixed; boundary="------------0B9A3253ADCB1E12297D5F04" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------0B9A3253ADCB1E12297D5F04 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------0B9A3253ADCB1E12297D5F04 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Received: from vigrid.com (pm3-pt30.pcnet.net [206.105.29.104]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id SAA21196; Fri, 26 Nov 1999 18:00:30 -0500 (EST) Sender: deischen@pcnet.com Message-ID: <383F1109.48AB132D@vigrid.com> Date: Fri, 26 Nov 1999 18:00:25 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Subject: Re: Threads stuff References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mozilla-Status2: 00000000 Julian Elischer wrote: > > > No, those are blocked in kernel space. Their respective KSEs are > > shown hung off of proc P1 and P2. Oops, the kse_blockedq and > > kse_unblockedq tags on proc P1 are reversed. P1->kse_blockedq > > should read kse_unblockedq, and P1->kse_unblockedq should read > > kse_blockedq. > > ok but then in your diagram you should show some threads blocked in > userland as well. OK > > Threads blocked in user space (let's say waiting on a mutex), don't > > have a KSE. > > exactly. > > But I was thinking of what context the UTS had access to for the thread. > For example, could the UTS time-out an IO and return a 'failed' result > and restart a thread that had made an IO request, even though the IO > hadn't returned? If all the context that was needed to restart a thread > blocked in the kernel was available to teh UTS then that saved thread info > must be pretty much the same as what a thread blocked in the userland must > be. For the most part, the UTS doesn't need the context for threads blocked on I/O. It just needs to know how to resume and cancel them. If we optimize for the common case, then we don't need to make the context of the blocked thread available to the UTS. For threads that are preempted, the UTS only needs the program counter. If you wanted to be able to time-out an I/O from the UTS (not a common case, we don't do it now), you could then add a system call to return the context of a blocked thread based on its unique KSE ID. This could also be used to retrieve the context of a thread that was preempted in the unlikely chance it was in a critical region. For threads that block in the kernel, we also need to save the kernel register set and stack. This will be stored in a KSE and we'll switch to a different KSE to return back to userland. The UTS still needs some way of identifying the KSE to be resumed. In your new syscall gate, are you returning something back from the kernel that can be used to identify the KSE that blocked? > > I don't think we want to require a kernel call to resume a thread > > that is blocked in user space, right? And I really don't think we > > want KSEs for every thread in an application, right? > > no, though you are suggesting it in other email because you say you need > to block/unblock signals, and your {s,g}et_context calls would require it. In an MT application, I think we can ignore signal masks for individual threads. As long as we have a method that lets the UTS act as signal proxy anyways. Actually, we should be able to safely use _setjmp/_longjmp instead of setjmp/longjmp now in libc_r. The UTS wouldn't use {g,s}etcontext other than for initially creating the UTS event handlers. > > > > So other than the above, threads blocked in user space and threads > > blocked in kernel space are exactly the same. There will just be > > a flag and perhaps KSE ID in the user thread struct to indicate > > whether it can be resumed with a _longjmp or a thread_resume(2). > > After a UTS has been notified that a thread has blocked in the kernel, > it should end up being identical to one that is blocked in user space, > except it is waiting on an event that the kernel must supply > (i.e. an IO completion block or something.) > > Until it is notified of the blocking it is 'running' Right. > > Hmm, I was under the impression it was on the USER stack. Isn't > > that why we have to copyin/copyout to access the trapframe from > > the kernel? > > I need my x86 book, but it's at work.. > > /* > * Call gate entry for FreeBSD ELF Linux/NetBSD syscall (int 0x80) > */ > SUPERALIGN_TEXT > IDTVEC(int0x80_syscall) > subl $8,%esp /* skip over tf_trapno and tf_err > */ At this point, doesn't %esp point at the user stack? Or does the int 0x80 somehow change the segments to be kernel segments? > pushal <---- > pushl %ds <---- > pushl %es <---- > pushl %fs <---- > movl $KDSEL,%eax /* switch to kernel segments */ The above comment is what confuses me. This makes me think that the push{al,l} statements above work on the user stack. > we've already switched to the kernel stack. > and we save all the regs (pushal) abd then the segment registers. > the stack segment has already been changed I think. OK, so the int 0x80 trap does switch segment registers and we are already on the kernel stack by the time that int0x80_syscall is entered? > > Of course if I need my x86 book it might not work for alpha.. > but if the syscall itself did: (this is my version of the 'syscall()' syscall.) > ENTRY(syscall) > pop %ecx /* rta */ > pop %eax /* syscall number */ > push %ecx > pushal <----------- > pushl %ds <----------- > pushl %es <----------- > pushl %fs <----------- > KERNCALL > call _UTS_syscall_end <----------- may decide to schedule something else. What information is passed to _UTS_syscall_end? In the case that the thread blocks, is event information passed? > popal <----------- > popl %fs <----------- > popl %es <----------- > popl %ds <----------- > push %ecx /* need to push a word to keep stack frame intact > upon return; the word must be the return address. */ > jb 1f > ret > 1: > PIC_PROLOGUE > jmp PIC_PLT(HIDENAME(cerror)) <-- not needed.. already in return status b > > then the same stuff would not be needed in the first code segment > and all that context would be available to the UTS immediatly without > needing it to cross the kernel boundary at all. Why does the UTS need any of this, though? It just needs notification that the thread blocked and some "thingy" that can be used to resume or cancel it? > The only problem I see is we would have to be very careful about getting a pagefault > while saving it.. pagefaults on stack segments are allowed to block? Sounds OK to me. I think the "Adding SA to Mach 3.0" paper talked about how pagefaults were handled. > > I think I follow you, but diagrams would help :-) Would there be some > > sort of unique ID returned from a blocked syscall, so that the UTS could > > later resume/cancel the thread? > > the blockage notification is from the syscall you think you are doing. How do you resume the thread? Longjmp'ing to the blocked system call won't work because the kernel doesn't know if it's a new system call or one that is being resumed. Dan Eischen eischen@vigrid.com --------------0B9A3253ADCB1E12297D5F04-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 26 15:38:13 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 0B4121521F for ; Fri, 26 Nov 1999 15:38:10 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA18776 for ; Sat, 27 Nov 1999 00:38:09 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA47531 for freebsd-arch@freebsd.org; Sat, 27 Nov 1999 00:38:09 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 0F9B31521F for ; Fri, 26 Nov 1999 15:37:58 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id PAA93864; Fri, 26 Nov 1999 15:37:58 -0800 (PST) Date: Fri, 26 Nov 1999 15:37:58 -0800 (PST) From: Julian Elischer To: arch@freebsd.org, "Daniel M. Eischen" Subject: Re: Threads stuff In-Reply-To: <383F1109.48AB132D@vigrid.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 26 Nov 1999, Daniel M. Eischen wrote: > Julian Elischer wrote: > > > > But I was thinking of what context the UTS had access to for the thread. > > For example, could the UTS time-out an IO and return a 'failed' result > > and restart a thread that had made an IO request, even though the IO > > hadn't returned? If all the context that was needed to restart a thread > > blocked in the kernel was available to the UTS then that saved thread info > > must be pretty much the same as what a thread blocked in the userland must > > be. > > For the most part, the UTS doesn't need the context for threads blocked > on I/O. It just needs to know how to resume and cancel them. If we > optimize for the common case, then we don't need to make the context > of the blocked thread available to the UTS. For threads that are > preempted, the UTS only needs the program counter. > Let me make myself more clear.. I wasn't saying we needed to do that, but that if the state that the UTS has available to it about a thread that is blocked in the kernel, and a thread that is blocked in userland is the same, then it simplifies things and such tricks become possible. It depends on what state the thread leaves behind when it dives into the kernel, and grabs a KSE stack. Alternatively it could have that state saved to it's context when it is declared "blocked" by the upcall. Either way, the UTS could have all the context needed to restart a thread, regardless of whether the kernel wants it to :-) > If you wanted to be able to time-out an I/O from the UTS (not a common > case, we don't do it now), you could then add a system call to return > the context of a blocked thread based on its unique KSE ID. This could > also be used to retrieve the context of a thread that was preempted in > the unlikely chance it was in a critical region. > > For threads that block in the kernel, we also need to save the kernel > register set and stack. This will be stored in a KSE and we'll switch > to a different KSE to return back to userland. The UTS still needs > some way of identifying the KSE to be resumed. In your new syscall > gate, are you returning something back from the kernel that can be > used to identify the KSE that blocked? > > > > I don't think we want to require a kernel call to resume a thread > > > that is blocked in user space, right? And I really don't think we > > > want KSEs for every thread in an application, right? > > > > no, though you are suggesting it in other email because you say you need > > to block/unblock signals, and your {s,g}et_context calls would require it. > > In an MT application, I think we can ignore signal masks for individual > threads. As long as we have a method that lets the UTS act as signal > proxy anyways. Actually, we should be able to safely use _setjmp/_longjmp > instead of setjmp/longjmp now in libc_r. The UTS wouldn't use {g,s}etcontext > other than for initially creating the UTS event handlers. I don't think we need them for that.. see older email example. > > > > > > > So other than the above, threads blocked in user space and threads > > > blocked in kernel space are exactly the same. There will just be > > > a flag and perhaps KSE ID in the user thread struct to indicate > > > whether it can be resumed with a _longjmp or a thread_resume(2). > > > > After a UTS has been notified that a thread has blocked in the kernel, > > it should end up being identical to one that is blocked in user space, > > except it is waiting on an event that the kernel must supply > > (i.e. an IO completion block or something.) > > > > Until it is notified of the blocking it is 'running' > > Right. > > > > Hmm, I was under the impression it was on the USER stack. Isn't > > > that why we have to copyin/copyout to access the trapframe from > > > the kernel? > > > > I need my x86 book, but it's at work.. > > > > /* > > * Call gate entry for FreeBSD ELF Linux/NetBSD syscall (int 0x80) > > */ > > SUPERALIGN_TEXT > > IDTVEC(int0x80_syscall) > > subl $8,%esp /* skip over tf_trapno and tf_err > > */ > > At this point, doesn't %esp point at the user stack? Or does the > int 0x80 somehow change the segments to be kernel segments? I need the book but I think we are now runing on kernel stack > > > pushal <---- > > pushl %ds <---- > > pushl %es <---- > > pushl %fs <---- > > movl $KDSEL,%eax /* switch to kernel segments */ > > The above comment is what confuses me. This makes me think that the > push{al,l} statements above work on the user stack. > > > we've already switched to the kernel stack. > > and we save all the regs (pushal) abd then the segment registers. > > the stack segment has already been changed I think. > > OK, so the int 0x80 trap does switch segment registers and we > are already on the kernel stack by the time that int0x80_syscall > is entered? That is my belief > > > > > Of course if I need my x86 book it might not work for alpha.. > > but if the syscall itself did: (this is my version of the 'syscall()' syscall.) > > ENTRY(syscall) > > pop %ecx /* rta */ > > pop %eax /* syscall number */ > > push %ecx > > pushal <----------- > > pushl %ds <----------- > > pushl %es <----------- > > pushl %fs <----------- > > KERNCALL > > call _UTS_syscall_end <----------- may decide to schedule something else. > > What information is passed to _UTS_syscall_end? In the case that the > thread blocks, is event information passed? In the case the syscall blocked, it came back via the UPCALL, not via here. > > > popal <----------- > > popl %fs <----------- > > popl %es <----------- > > popl %ds <----------- > > push %ecx /* need to push a word to keep stack frame intact > > upon return; the word must be the return address. */ > > jb 1f > > ret > > 1: > > PIC_PROLOGUE > > jmp PIC_PLT(HIDENAME(cerror)) <-- not needed.. already in return status b > > > > then the same stuff would not be needed in the first code segment > > and all that context would be available to the UTS immediatly without > > needing it to cross the kernel boundary at all. > > Why does the UTS need any of this, though? It just needs notification > that the thread blocked and some "thingy" that can be used to resume > or cancel it? When the syscall blocks, the saved information above is to be turned into a full frame. The PC (eip) is added (pointing to where we want it to resume when the IO completes) and the thread is set up looking as though it's waiting on it's IO completion block. The UTS gets (actualy should already know) the KSE-ID. On completion of the IO, the io completion block is updated just as it would have been had the syscall not blocked, and the KSE is hung off the subprocess. When the subprocess is next run, an upcall is made to the UTS, with some ID to let it know which completion block to look at. This is simply the same as is some other thread had released a mutex. The whole KSE in fact need not be hung off the subproc because all that is needed is the single mutex address to report. > > > The only problem I see is we would have to be very careful about getting a pagefault > > while saving it.. pagefaults on stack segments are allowed to block? > > Sounds OK to me. I think the "Adding SA to Mach 3.0" paper talked about > how pagefaults were handled. > > > > I think I follow you, but diagrams would help :-) Would there be some > > > sort of unique ID returned from a blocked syscall, so that the UTS could > > > later resume/cancel the thread? > > > > the blockage notification is from the syscall you think you are doing. > > How do you resume the thread? Longjmp'ing to the blocked system call > won't work because the kernel doesn't know if it's a new system call > or one that is being resumed. If the userland context of the thread looks just like the context of any other thread, then you just run it. When the thread is reported as blocked, you fiddle the context it left behind to make it look like it's blocked on a mutex on the io completion block. when the syscall completes, the result is the equivalent of releasing that mutex. i.e. the thread continues. The result of syscalls is always reported using an IO completion block, so on continuing from the mutex it checks to see the status etc, just like is always done. If the syscall didn't block, then the mutex is never hit even. It's all done with mirrors, (and a little creative stack surgery). > > Dan Eischen > eischen@vigrid.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 26 16:16:54 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 5374514DBA for ; Fri, 26 Nov 1999 16:16:51 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id BAA18954 for ; Sat, 27 Nov 1999 01:16:50 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA47681 for freebsd-arch@freebsd.org; Sat, 27 Nov 1999 01:16:46 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 5993614DBA for ; Fri, 26 Nov 1999 16:16:39 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt35.pcnet.net [206.105.29.109]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id TAA29273; Fri, 26 Nov 1999 19:16:40 -0500 (EST) Message-ID: <383F22E4.31155FC7@vigrid.com> Date: Fri, 26 Nov 1999 19:16:36 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: arch@freebsd.org Subject: Re: Threads stuff References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > > > Why does the UTS need any of this, though? It just needs notification > > that the thread blocked and some "thingy" that can be used to resume > > or cancel it? > > When the syscall blocks, the saved information above is to be turned into > a full frame. The PC (eip) is added (pointing to where we want it to > resume when the IO completes) and the thread is set up looking as though > it's waiting on it's IO completion block. The UTS gets (actualy should > already know) the KSE-ID. > > On completion of the IO, the io completion block is updated > just as it would have been had the syscall not blocked, and > the KSE is hung off the subprocess. When the subprocess is next run, > an upcall is made to the UTS, with some ID to let it know which > completion block to look at. This is simply the same as is some > other thread had released a mutex. The whole KSE in fact need not be hung > off the subproc because all that is needed is the single mutex address > to report. So when the IO completion block is updated, how exactly is the the thread continued? It _has_ to go back into the kernel in order to resume. I don't see the similarity between threads blocked in userland (on a mutex) and threads blocked in the kernel. > > How do you resume the thread? Longjmp'ing to the blocked system call > > won't work because the kernel doesn't know if it's a new system call > > or one that is being resumed. > > If the userland context of the thread looks just like the context of > any other thread, then you just run it. > When the thread is reported as blocked, you fiddle the context it left > behind to make it look like it's blocked on a mutex on the io completion > block. when the syscall completes, the result is the equivalent of > releasing that mutex. i.e. the thread continues. What I don't quite see yet is how you resume a thread at the kernel level. You can't just "run the thread" after the IO control block was updated indicating that the thread unblocked. You need to resume the thread within the kernel. As long as you need a kernel call to resume/cancel a blocked thread, why try to hide it behind smoke and mirrors ;-) Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 26 17:19:13 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 1536D1507B for ; Fri, 26 Nov 1999 17:19:10 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id CAA19779 for ; Sat, 27 Nov 1999 02:19:09 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA47955 for freebsd-arch@freebsd.org; Sat, 27 Nov 1999 02:19:08 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id BD4CF15578 for ; Fri, 26 Nov 1999 17:11:12 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id RAA94896; Fri, 26 Nov 1999 17:11:11 -0800 (PST) Date: Fri, 26 Nov 1999 17:11:10 -0800 (PST) From: Julian Elischer To: "Daniel M. Eischen" Cc: arch@freebsd.org Subject: Re: Threads stuff In-Reply-To: <383F22E4.31155FC7@vigrid.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG firstly: You HAVE to sing this to get the full effect.... -(-(--_ / ( ( \ DO-RE-MI BEER,by Homer J. Simpson. | | | | DOUGH... the stuff... | __ __) that buys me beer... | / \/ \ RAY..... the guy that /\/\ (o )o ) sells me beer... /c \__/ --. ME...... the guy... ( ) who drinks the beer, \_ _-------' FAR..... the distance to my beer. | / \ SO...... I think I'll have a beer. | | '\_______) LA...... La, la la la la beer | \_____) TEA..... no thanks, |_____ | I'm drinking beer... |______/\/\ That will bring us back to... / \ (Looks into an empty glass) D'OH! Now that we have that out of the way: On Fri, 26 Nov 1999, Daniel M. Eischen wrote: > Julian Elischer wrote: > > > > > Why does the UTS need any of this, though? It just needs notification > > > that the thread blocked and some "thingy" that can be used to resume > > > or cancel it? > > > > When the syscall blocks, the saved information above is to be turned into > > a full frame. The PC (eip) is added (pointing to where we want it to > > resume when the IO completes) and the thread is set up looking as though > > it's waiting on it's IO completion block. The UTS gets (actualy should > > already know) the KSE-ID. > > > > On completion of the IO, the io completion block is updated > > just as it would have been had the syscall not blocked, and > > the KSE is hung off the subprocess. When the subprocess is next run, > > an upcall is made to the UTS, with some ID to let it know which > > completion block to look at. This is simply the same as is some > > other thread had released a mutex. The whole KSE in fact need not be hung > > off the subproc because all that is needed is the single mutex address > > to report. > > So when the IO completion block is updated, how exactly is the > the thread continued? It _has_ to go back into the kernel in > order to resume. I don't see the similarity between threads > blocked in userland (on a mutex) and threads blocked in the > kernel. The thread context is entirely in user space. it is waitomg on a mutex that will tell it that some other thread (in this cas the kernel) has completed tranfering the data it requested and has updated the io status block. it was 'transformed' to this when it was reported blocked by the first upcall. Since most of the status was alreday present on the (user) stack, all that was required at that time was it's entry into the mutex hash table and it's eip to be modified so that when it is run it thinks it has completed the IO. it will then proceed exactly as though the IO had been completed synchronously.. i.e. checks the status in the IO status block and retunrs to it's caller. Each thread has a pernamently assigned IO status block and it's errno lives there. The contents of the IO status block are updated when the KSE that was blocked returns. SInce it was blocked it then hangs itself (or a proxy) off the sub-proc "unblocked" queue. Had it not blocked, it would simply update the status block and retunr to the userland which would check the status and return to the caller. code path in library for (write); set IO status to 'incomplete' setjmp(mycontext) /* save all the regs in thread context*/ set saved mycontext->eip to point to 'A' call kernel lngjmp (mycontext) /* notreached */ B: while status == incomplete wait on mutex in IO status block A: check status return to calling code ---- when the thread is reported blocked: the return mycontect->eip is changed from "A" to "B" code is run to put the thread into whatever structures the UTS maintains for mutexes. That completes all processing. It then goes on to schedule another thread. from the thread's point of view, it has just woken up from waiting on a mutex. The IO is mysteriously complete. > > > > How do you resume the thread? Longjmp'ing to the blocked system call > > > won't work because the kernel doesn't know if it's a new system call > > > or one that is being resumed. > > > > If the userland context of the thread looks just like the context of > > any other thread, then you just run it. > > When the thread is reported as blocked, you fiddle the context it left > > behind to make it look like it's blocked on a mutex on the io completion > > block. when the syscall completes, the result is the equivalent of > > releasing that mutex. i.e. the thread continues. > > What I don't quite see yet is how you resume a thread at the kernel > level. You can't just "run the thread" after the IO control block > was updated indicating that the thread unblocked. You need to resume > the thread within the kernel. As long as you need a kernel call to > resume/cancel a blocked thread, why try to hide it behind smoke and > mirrors ;-) No you don't need to go back to the kernel. All kernel processing has completed. All your upcall needs is the address of the IO completion block that contains the mutex to release. All copyin()s and copyout()s have been completed, and the IO status block has been updated, just as if the call would have been synchronous. (in fact the code that did it didn't know that it was not going to go back to the user.) just before it was going to go back to the user, it checked a bit and discoverd that instead, it should hang itself (or a small struct holding the address of the IO completion block) off the subproc. (If the latter the KSE can actually be freed now). At some stage in the future (maybe immediatly) an upcall reports to the UTS the addresses of all completed IO status blocks, and the UTS releases all the mutexes. > > Dan Eischen > eischen@vigrid.com > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 26 17:19:20 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 6172415298 for ; Fri, 26 Nov 1999 17:19:17 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id CAA19789 for ; Sat, 27 Nov 1999 02:19:17 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA47977 for freebsd-arch@freebsd.org; Sat, 27 Nov 1999 02:19:16 +0100 (MET) Received: from 24.66.174.118.bc.wave.home.com (24.66.174.118.bc.wave.home.com [24.66.174.118]) by hub.freebsd.org (Postfix) with ESMTP id 4B52015339 for ; Fri, 26 Nov 1999 17:13:43 -0800 (PST) (envelope-from jburkhol@home.com) Received: from 24.66.174.118.bc.wave.home.com (localhost [127.0.0.1]) by 24.66.174.118.bc.wave.home.com (Postfix) with ESMTP id 156031FDA; Fri, 26 Nov 1999 17:13:44 -0800 (PST) X-Mailer: exmh version 2.1.1 10/15/1999 To: Julian Elischer Cc: arch@freebsd.org, "Daniel M. Eischen" Subject: Re: Threads stuff In-reply-to: Your message of "Fri, 26 Nov 1999 15:37:58 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Nov 1999 17:13:43 -0800 From: Jake Burkholder Message-Id: <19991127011344.156031FDA@24.66.174.118.bc.wave.home.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > OK, so the int 0x80 trap does switch segment registers and we > > are already on the kernel stack by the time that int0x80_syscall > > is entered? > > That is my belief Yes, that's right. A good reference for this is the Intel Architecture Software Developer's Manual: http://developer.intel.com/design/pentiumIII/xeon/manuals/ volumes 2 and 3 are most useful. 'int' loads the new ss and esp (kernel stack) from the TSS and then push a far pointer to the old (user) stack, eflags, a far pointer to the return address, and an error code on to that stack. I agree that it would be useful to have the context saved in userland, and it doesn't seem that hard to do so. Restarting system calls would have to be handled differently. > When the syscall blocks, the saved information above is to be turned into > a full frame. The PC (eip) is added (pointing to where we want it to > resume when the IO completes) and the thread is set up looking as though > it's waiting on it's IO completion block. Is an IO completion block just a data structure that allows the UTS to keep track of threads in the kernel? > On completion of the IO, the io completion block is updated > just as it would have been had the syscall not blocked, and The UTS is notified that the IO has completed, and updates the completion block. Is that right? When a thread does a system call, does it first call a scheduler routine that creates the IO completion block? (part of the new system call gate?) > the KSE is hung off the subprocess. When the subprocess is next run, [...] > with mirrors, (and a little creative stack surgery). Yeah, this sounds interesting. Thanks for forwarding this stuff to the list! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 26 17:31:28 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id B574614EC2 for ; Fri, 26 Nov 1999 17:31:26 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id CAA24660 for ; Sat, 27 Nov 1999 02:31:25 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA48046 for freebsd-arch@freebsd.org; Sat, 27 Nov 1999 02:31:25 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 2E9DD14EC2 for ; Fri, 26 Nov 1999 17:31:18 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id RAA95169; Fri, 26 Nov 1999 17:31:13 -0800 (PST) Date: Fri, 26 Nov 1999 17:31:13 -0800 (PST) From: Julian Elischer To: Jake Burkholder Cc: arch@freebsd.org, "Daniel M. Eischen" Subject: Re: Threads stuff In-Reply-To: <19991127011344.156031FDA@24.66.174.118.bc.wave.home.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 26 Nov 1999, Jake Burkholder wrote: > > > OK, so the int 0x80 trap does switch segment registers and we > > > are already on the kernel stack by the time that int0x80_syscall > > > is entered? > > > > That is my belief > > Yes, that's right. A good reference for this is the Intel > Architecture Software Developer's Manual: > > http://developer.intel.com/design/pentiumIII/xeon/manuals/ Wonderful, I knew someone would point me at an online version :-) > > volumes 2 and 3 are most useful. > > 'int' loads the new ss and esp (kernel stack) from the TSS and > then push a far pointer to the old (user) stack, eflags, a far > pointer to the return address, and an error code on to that stack. > > I agree that it would be useful to have the context saved in userland, > and it doesn't seem that hard to do so. Restarting system calls would > have to be handled differently. > > > When the syscall blocks, the saved information above is to be turned into > > a full frame. The PC (eip) is added (pointing to where we want it to > > resume when the IO completes) and the thread is set up looking as though > > it's waiting on it's IO completion block. Actualy thinking about it.. the userland might as well do a setjmp() (or something that looks a lot like it) as it needs to save everything and that seems to be a good way.. does setjmp save %ds %es etc? > > Is an IO completion block just a data structure that allows > the UTS to keep track of threads in the kernel? Basically as I see it, a new thread starts out with a new stack. Before it gets to start running, a number of things are pushed onto that stack. This means that every thread has one.. this is basically the thread local storage.. (how it FINDS it is another matter). In any case, teh IO completeion block is one of the things there. Every syscall that is altered, uses this to pass the completion code, the return values and the errno value back. It also contains a mutex. How we FIND this thread local storage is a completely different problem. Under Mach threads the stacks were limitted to (from memory) 60KB each with a 1 page guard page allocated above each to protect it from the previous one. that the thread local storage was easily found as: %esp & 0xffff000 - 1024 where 1024 was the space allocated to it. > > > On completion of the IO, the io completion block is updated > > just as it would have been had the syscall not blocked, and > > The UTS is notified that the IO has completed, and updates the > completion block. Is that right? No the kernel updtes the completion block. just before queueing tself for notification to the UTS. > > When a thread does a system call, does it first call a scheduler > routine that creates the IO completion block? (part of the new > system call gate?) No it has one permanently assiged. (though your idea would work) > > > the KSE is hung off the subprocess. When the subprocess is next run, > [...] > > with mirrors, (and a little creative stack surgery). > > Yeah, this sounds interesting. > > Thanks for forwarding this stuff to the list! > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 26 19: 8:45 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 39C0214F5E for ; Fri, 26 Nov 1999 19:08:41 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA01333 for ; Sat, 27 Nov 1999 04:08:39 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA51531 for freebsd-arch@freebsd.org; Sat, 27 Nov 1999 04:08:38 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 3D08414F5E for ; Fri, 26 Nov 1999 19:08:29 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt87.pcnet.net [206.105.29.161]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id WAA16592; Fri, 26 Nov 1999 22:08:30 -0500 (EST) Message-ID: <383F4B2D.C0E9182F@vigrid.com> Date: Fri, 26 Nov 1999 22:08:29 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: arch@freebsd.org Subject: Re: Threads stuff References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > > firstly: > > You HAVE to sing this to get the full effect.... > -(-(--_ > / ( ( \ DO-RE-MI BEER,by Homer J. Simpson. > | | > | | DOUGH... the stuff... > | __ __) that buys me beer... > | / \/ \ RAY..... the guy that > /\/\ (o )o ) sells me beer... > /c \__/ --. ME...... the guy... > ( ) who drinks the beer, > \_ _-------' FAR..... the distance to my beer. > | / \ SO...... I think I'll have a beer. > | | '\_______) LA...... La, la la la la beer > | \_____) TEA..... no thanks, > |_____ | I'm drinking beer... > |______/\/\ That will bring us back to... > / \ (Looks into an empty glass) > D'OH! > > Now that we have that out of the way: > > On Fri, 26 Nov 1999, Daniel M. Eischen wrote: > > > Julian Elischer wrote: > > > > > > > Why does the UTS need any of this, though? It just needs notification > > > > that the thread blocked and some "thingy" that can be used to resume > > > > or cancel it? > > > > > > When the syscall blocks, the saved information above is to be turned into > > > a full frame. The PC (eip) is added (pointing to where we want it to > > > resume when the IO completes) and the thread is set up looking as though > > > it's waiting on it's IO completion block. The UTS gets (actualy should > > > already know) the KSE-ID. > > > > > > On completion of the IO, the io completion block is updated > > > just as it would have been had the syscall not blocked, and > > > the KSE is hung off the subprocess. When the subprocess is next run, > > > an upcall is made to the UTS, with some ID to let it know which > > > completion block to look at. This is simply the same as is some > > > other thread had released a mutex. The whole KSE in fact need not be hung > > > off the subproc because all that is needed is the single mutex address > > > to report. > > > > So when the IO completion block is updated, how exactly is the > > the thread continued? It _has_ to go back into the kernel in > > order to resume. I don't see the similarity between threads > > blocked in userland (on a mutex) and threads blocked in the > > kernel. > > The thread context is entirely in user space. > it is waitomg on a mutex that will tell it that some other thread > (in this cas the kernel) has completed tranfering the data it requested > and has updated the io status block. > > it was 'transformed' to this when it was reported blocked by the > first upcall. Since most of the status was alreday present on the (user) > stack, all that was required at that time was it's entry into the > mutex hash table and it's eip to be modified so that when it is run it > thinks it has completed the IO. it will then proceed exactly as though > the IO had been completed synchronously.. i.e. checks the status in the > IO status block and retunrs to it's caller. > > Each thread has a pernamently assigned IO status block and it's errno > lives there. The contents of the IO status block are updated when the > KSE that was blocked returns. SInce it was blocked it then hangs itself > (or a proxy) off the sub-proc "unblocked" queue. Had it not blocked, > it would simply update the status block and retunr to the userland > which would check the status and return to the caller. > > code path in library for (write); > > set IO status to 'incomplete' > setjmp(mycontext) /* save all the regs in thread context*/ > set saved mycontext->eip to point to 'A' > call kernel > lngjmp (mycontext) > /* notreached */ > > B: > while status == incomplete > wait on mutex in IO status block > A: > check status > return to calling code > > ---- > > when the thread is reported blocked: > the return mycontect->eip is changed from "A" to "B" > code is run to put the thread into whatever > structures the UTS maintains for mutexes. That completes all processing. > It then goes on to schedule another thread. > from the thread's point of view, it has just woken up from waiting > on a mutex. The IO is mysteriously complete. > > > > > > > How do you resume the thread? Longjmp'ing to the blocked system call > > > > won't work because the kernel doesn't know if it's a new system call > > > > or one that is being resumed. > > > > > > If the userland context of the thread looks just like the context of > > > any other thread, then you just run it. > > > When the thread is reported as blocked, you fiddle the context it left > > > behind to make it look like it's blocked on a mutex on the io completion > > > block. when the syscall completes, the result is the equivalent of > > > releasing that mutex. i.e. the thread continues. > > > > What I don't quite see yet is how you resume a thread at the kernel > > level. You can't just "run the thread" after the IO control block > > was updated indicating that the thread unblocked. You need to resume > > the thread within the kernel. As long as you need a kernel call to > > resume/cancel a blocked thread, why try to hide it behind smoke and > > mirrors ;-) > > No you don't need to go back to the kernel. > All kernel processing has completed. > All your upcall needs is the address of the IO completion block that contains > the mutex to release. All copyin()s and copyout()s have been completed, and the > IO status block has been updated, just as if the call would > have been synchronous. (in fact the code that did it didn't know that it > was not going to go back to the user.) > just before it was going to go back to the user, it checked a bit and > discoverd that instead, it should hang itself (or a small struct holding the > address of the IO completion block) off the subproc. (If the latter the > KSE can actually be freed now). At some stage in the future (maybe immediatly) > an upcall reports to the UTS the addresses of all completed IO status blocks, > and the UTS releases all the mutexes. > > > > > Dan Eischen > > eischen@vigrid.com > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-arch" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 26 20: 9:58 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id CD67E14D49 for ; Fri, 26 Nov 1999 20:09:50 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id FAA02087 for ; Sat, 27 Nov 1999 05:09:48 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA51749 for freebsd-arch@freebsd.org; Sat, 27 Nov 1999 05:09:48 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 4249D14D49 for ; Fri, 26 Nov 1999 20:09:37 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt72.pcnet.net [206.105.29.146]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id XAA22646; Fri, 26 Nov 1999 23:09:37 -0500 (EST) Message-ID: <383F5982.CC9F132C@vigrid.com> Date: Fri, 26 Nov 1999 23:09:38 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: arch@freebsd.org Subject: Re: Threads stuff References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sorry about the last post; I accidently hit send. Julian Elischer wrote: > You HAVE to sing this to get the full effect.... Thanks! > Each thread has a pernamently assigned IO status block and it's errno > lives there. The contents of the IO status block are updated when the > KSE that was blocked returns. SInce it was blocked it then hangs itself > (or a proxy) off the sub-proc "unblocked" queue. Had it not blocked, > it would simply update the status block and retunr to the userland > which would check the status and return to the caller. > > code path in library for (write); > > set IO status to 'incomplete' > setjmp(mycontext) /* save all the regs in thread context*/ > set saved mycontext->eip to point to 'A' > call kernel > lngjmp (mycontext) > /* notreached */ > > B: > while status == incomplete > wait on mutex in IO status block > A: > check status > return to calling code This seems overly complicated just to perform a system call, but OK. You were talking about putting the trapframe (or most of it) on the user stack, so why not just put the address of the trapframe (stack pointer) in the IO control block. No need for setjmp/longjmp unless the system call blocks. > > when the thread is reported blocked: > the return mycontect->eip is changed from "A" to "B" > code is run to put the thread into whatever > structures the UTS maintains for mutexes. That completes all processing. > It then goes on to schedule another thread. > from the thread's point of view, it has just woken up from waiting > on a mutex. The IO is mysteriously complete. Why mutexes? It just needs to be marked blocked/suspended/whatever. The UTS will only run threads that are in the run state. There is some overhead with mutexes. > > What I don't quite see yet is how you resume a thread at the kernel > > level. You can't just "run the thread" after the IO control block > > was updated indicating that the thread unblocked. You need to resume > > the thread within the kernel. As long as you need a kernel call to > > resume/cancel a blocked thread, why try to hide it behind smoke and > > mirrors ;-) > > No you don't need to go back to the kernel. > All kernel processing has completed. This is what I don't see. When KSEs are woken-up in the kernel, how are they resumed? If you have 10 blocked KSEs hanging off a process, and they all become unblocked before the process runs again, what happens the next time the process runs? KSEs can also hit tsleep more than once before leaving the kernel. If the kernel automatically completes the KSEs, then the kernel is arbitrarily deciding the priority of the threads. There could be runnable threads with higher priority than any of the threads blocked in the kernel. > All your upcall needs is the address of the IO completion block that contains > the mutex to release. All copyin()s and copyout()s have been completed, and the > IO status block has been updated, just as if the call would > have been synchronous. (in fact the code that did it didn't know that it > was not going to go back to the user.) > just before it was going to go back to the user, it checked a bit and > discoverd that instead, it should hang itself (or a small struct holding the > address of the IO completion block) off the subproc. (If the latter the > KSE can actually be freed now). At some stage in the future (maybe immediatly) > an upcall reports to the UTS the addresses of all completed IO status blocks, > and the UTS releases all the mutexes. OK, I think this answers some of my questions. KSEs are automatically completed by the kernel to the point where they would return control to the application. I'm not sure I like that because the UTS can't decide which blocked KSEs are resumed - they are all resumed, possibly stealing time from other higher priority threads. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 27 0:15:42 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id B99C814FE8 for ; Sat, 27 Nov 1999 00:15:36 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id JAA04510 for ; Sat, 27 Nov 1999 09:15:34 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id JAA52143 for freebsd-arch@freebsd.org; Sat, 27 Nov 1999 09:15:34 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 49E0514D55 for ; Fri, 26 Nov 1999 21:34:05 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id VAA97919; Fri, 26 Nov 1999 21:34:04 -0800 (PST) Date: Fri, 26 Nov 1999 21:34:03 -0800 (PST) From: Julian Elischer To: "Daniel M. Eischen" Cc: arch@freebsd.org Subject: Re: Threads stuff In-Reply-To: <383F5982.CC9F132C@vigrid.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 26 Nov 1999, Daniel M. Eischen wrote: > Sorry about the last post; I accidently hit send. > > Julian Elischer wrote: > > You HAVE to sing this to get the full effect.... > > Thanks! > > > Each thread has a pernamently assigned IO status block and it's errno > > lives there. The contents of the IO status block are updated when the > > KSE that was blocked returns. SInce it was blocked it then hangs itself > > (or a proxy) off the sub-proc "unblocked" queue. Had it not blocked, > > it would simply update the status block and retunr to the userland > > which would check the status and return to the caller. > > > > code path in library for (write); > > > > set IO status to 'incomplete' > > setjmp(mycontext) /* save all the regs in thread context*/ > > set saved mycontext->eip to point to 'A' > > call kernel > > lngjmp (mycontext) > > /* notreached */ > > > > B: > > while status == incomplete > > wait on mutex in IO status block > > A: > > check status > > return to calling code > > This seems overly complicated just to perform a system call, > but OK. You were talking about putting the trapframe (or most of it) > on the user stack, so why not just put the address of the trapframe > (stack pointer) in the IO control block. No need for setjmp/longjmp > unless the system call blocks. you have to save all your registers. if you didn't do it then the kernel would have to to do it. (which is what happens now). you can eithe rsave the registers on the user stack, or elsewhere. I prefer elsewhere because it reduces the chances of a pagefault half way through, but it's as you say, an implementation detail as to where they are saved, as long as the UTS know where to find them. Saving to stack is quicker, saving to somewhere else has less chance of pagefaults. take your pick. > > > > > when the thread is reported blocked: > > the return mycontect->eip is changed from "A" to "B" > > code is run to put the thread into whatever > > structures the UTS maintains for mutexes. That completes all processing. > > It then goes on to schedule another thread. > > from the thread's point of view, it has just woken up from waiting > > on a mutex. The IO is mysteriously complete. > > Why mutexes? It just needs to be marked blocked/suspended/whatever. > The UTS will only run threads that are in the run state. There is > some overhead with mutexes. It doesn't have to be a mutex. I was just trying to get the point across that the thread ends up suspended in exactly the same way that it would be if it had done a 'yield'. All that matters is that it's supended, and can be woken up at a later time by an external event. It can be done any way that is quickest and easiest. > > > > What I don't quite see yet is how you resume a thread at the kernel > > > level. You can't just "run the thread" after the IO control block > > > was updated indicating that the thread unblocked. You need to resume > > > the thread within the kernel. As long as you need a kernel call to > > > resume/cancel a blocked thread, why try to hide it behind smoke and > > > mirrors ;-) > > > > No you don't need to go back to the kernel. > > All kernel processing has completed. > > This is what I don't see. When KSEs are woken-up in the kernel, > how are they resumed? EXACTLY AS THEY ARE NOW.. NO ()zilch, zippo, nada) difference to what happens now. The KSE's on the sleep queue that are sleeping are taken off teh sleep queue, and hung off the subproc (well I guess that's a differrence), and when the subproc is scheduled (which it willbe if it has (N > 0) KSE's scheduled, then each of them is run to completion or blocks again. When the last KSE has run and they have all done their IO and are waiting up at the user/kernel boundary, (having updated all their IO staus blocks) the upcall isperformed notifying hte UTS of which status blocks have been updated. The UTS schedules all appropriate threads. and starts the one with the higest priority. All the KSEs that were blocked are freed and back in the KSE cache. > If you have 10 blocked KSEs hanging off a > process, and they all become unblocked before the process runs again, > what happens the next time the process runs? KSEs can also hit > tsleep more than once before leaving the kernel. what happens now? before they are unblocked they are sitting in the system's sleep queues. When they are unblocked they are transfered to the 'unblocked' queue on the subprocess, and the subproocess is scheduled onto the run queue for it's processor. When the processor is scheduled all the waiting KSE's are run, one after another until they complete. WHenthey are all done, then control -passes to userland. there is a possibility that as an optimisation, you might report to the UTS after each completion so that it might decide that it could let the completed thread run on some other processor while we get on with more IO, but that is an optimisation. > > If the kernel automatically completes the KSEs, then the kernel is > arbitrarily deciding the priority of the threads. There could be > runnable threads with higher priority than any of the threads blocked > in the kernel. That's Matt's argument. If we had a thread that was super High priority, we should have assigned it a subproc (scheduling class) that was high priority. Then it wouldn't be competing with the others. > > > All your upcall needs is the address of the IO completion block that contains > > the mutex to release. All copyin()s and copyout()s have been completed, and the > > IO status block has been updated, just as if the call would > > have been synchronous. (in fact the code that did it didn't know that it > > was not going to go back to the user.) > > just before it was going to go back to the user, it checked a bit and > > discoverd that instead, it should hang itself (or a small struct holding the > > address of the IO completion block) off the subproc. (If the latter the > > KSE can actually be freed now). At some stage in the future (maybe immediatly) > > an upcall reports to the UTS the addresses of all completed IO status blocks, > > and the UTS releases all the mutexes. > > OK, I think this answers some of my questions. KSEs are automatically > completed by the kernel to the point where they would return control > to the application. I'm not sure I like that because the UTS can't > decide which blocked KSEs are resumed - they are all resumed, possibly > stealing time from other higher priority threads. yes but that's why we can separate them ou tinto separate subprocs. To get predictable behaviour and parallelisation. > > Dan Eischen > eischen@vigrid.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 27 6:14:46 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 6D83114CCF for ; Sat, 27 Nov 1999 06:14:43 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id PAA07869 for ; Sat, 27 Nov 1999 15:14:42 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA52620 for freebsd-arch@freebsd.org; Sat, 27 Nov 1999 15:14:42 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 996F414D98 for ; Sat, 27 Nov 1999 02:20:21 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id CAA01287; Sat, 27 Nov 1999 02:20:17 -0800 (PST) Date: Sat, 27 Nov 1999 02:20:17 -0800 (PST) From: Julian Elischer To: "Daniel M. Eischen" Cc: arch@freebsd.org Subject: Re: Threads stuff In-Reply-To: <383F7309.5D18949D@vigrid.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ok well I'm only sketching out one solutionso don't feel that ai'm bullying you into anything.. in this scheme however there is nothing to say that we can't keep track of time spent in IO. On Sat, 27 Nov 1999, Daniel M. Eischen wrote: > Julian Elischer wrote: > > > If the kernel automatically completes the KSEs, then the kernel is > > > arbitrarily deciding the priority of the threads. There could be > > > runnable threads with higher priority than any of the threads blocked > > > in the kernel. > > > > That's Matt's argument. > > > > If we had a thread that was super High priority, we should have assigned > > it a subproc (scheduling class) that was high priority. Then it wouldn't > > be competing with the others. > > There's another problem too. If the kernel arbitrarily completes IO requests, > then the UTS has no idea how much system time was spent for each thread. The > UTS needs to know this in order to effectively schedule threads. There was > a PR describing this problem in our threads library. Libc_r used to use > ITIMER_VIRTUAL for timing, but IO bound threads would starve out other threads > because their accrued run time didn't reflect the time spent in the system. > I changed the timer to be ITIMER_PROF to fix the problem. > > If you hide time spent in the system from the UTS, the same thing can happen. > I/O bound threads will starve out other threads. > > Dan Eischen > eischen@vigrid.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 27 6:14:50 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 432A014D22 for ; Sat, 27 Nov 1999 06:14:45 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id PAA07873 for ; Sat, 27 Nov 1999 15:14:44 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA52681 for freebsd-arch@freebsd.org; Sat, 27 Nov 1999 15:14:44 +0100 (MET) Received: from io.yi.org (24.66.174.118.bc.wave.home.com [24.66.174.118]) by hub.freebsd.org (Postfix) with ESMTP id 8B97514FE3 for ; Sat, 27 Nov 1999 01:04:11 -0800 (PST) (envelope-from jburkhol@home.com) Received: from io.yi.org (localhost [127.0.0.1]) by io.yi.org (Postfix) with ESMTP id 64B121FDA; Sat, 27 Nov 1999 01:04:11 -0800 (PST) X-Mailer: exmh version 2.1.1 10/15/1999 To: Julian Elischer Cc: arch@freebsd.org Subject: Re: Threads stuff In-reply-to: Your message of "Fri, 26 Nov 1999 21:34:03 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Nov 1999 01:04:11 -0800 From: Jake Burkholder Message-Id: <19991127090411.64B121FDA@io.yi.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > what happens now? > before they are unblocked they are sitting in the system's sleep queues. > When they are unblocked they are transfered to the 'unblocked' queue on > the subprocess, and the subproocess is scheduled onto the run queue for > it's processor. I think that maybe what Daniel is getting at, and what is in the scheduler activations paper, is that when a thread unblocks in the kernel it is _not_ automatically scheduled by the kernel. There is another scheduler activation, notifying the UTS of the event. If there is a higher priority thread in userland, ready to run, the just unblocked thread will remain blocked in the kernel until it is the highest priority thread. The UTS then makes another kernel call, which resumes the thread where it left off when it unblocked from the original system call; it may have more to do, and as Daniel said, hit tsleep again. Allowing it to continue right up to bridge to userland uses up resources that the UTS might rather use on a higher priority thread. > That's Matt's argument. > > > If we had a thread that was super High priority, we should have assigned > it a subproc (scheduling class) that was high priority. Then it wouldn't > be competing with the others. Having a sub-proc designated as higher priority means that the proc would need to know about that, and be sure that when a sub-proc unblocked, higher priority sub-procs were scheduled first. The kernel then has to know alot about priorities, which I think is something Daniel would like to avoid. Also, is it not the case that when a process is making a system call it is not pre-emptable? So when a thread unblocks in the kernel, but there is a higher priority thread in userland, the UTS cannot pre-empt the thread; it must allow it to continue what its doing in the kernel and return to user-land before the higher priority thread can run (on this kse). Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 27 6:14:54 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 042D915544 for ; Sat, 27 Nov 1999 06:14:50 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id PAA07877 for ; Sat, 27 Nov 1999 15:14:50 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA52770 for freebsd-arch@freebsd.org; Sat, 27 Nov 1999 15:14:49 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 26C0914FA7 for ; Fri, 26 Nov 1999 21:58:29 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt26.pcnet.net [206.105.29.100]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id AAA03497; Sat, 27 Nov 1999 00:58:29 -0500 (EST) Message-ID: <383F7309.5D18949D@vigrid.com> Date: Sat, 27 Nov 1999 00:58:33 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: arch@freebsd.org Subject: Re: Threads stuff References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > > If the kernel automatically completes the KSEs, then the kernel is > > arbitrarily deciding the priority of the threads. There could be > > runnable threads with higher priority than any of the threads blocked > > in the kernel. > > That's Matt's argument. > > If we had a thread that was super High priority, we should have assigned > it a subproc (scheduling class) that was high priority. Then it wouldn't > be competing with the others. There's another problem too. If the kernel arbitrarily completes IO requests, then the UTS has no idea how much system time was spent for each thread. The UTS needs to know this in order to effectively schedule threads. There was a PR describing this problem in our threads library. Libc_r used to use ITIMER_VIRTUAL for timing, but IO bound threads would starve out other threads because their accrued run time didn't reflect the time spent in the system. I changed the timer to be ITIMER_PROF to fix the problem. If you hide time spent in the system from the UTS, the same thing can happen. I/O bound threads will starve out other threads. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 27 6:30:22 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id CDFB414C9F for ; Sat, 27 Nov 1999 06:30:20 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id PAA08036 for ; Sat, 27 Nov 1999 15:30:18 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA52974 for freebsd-arch@freebsd.org; Sat, 27 Nov 1999 15:30:18 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 57E8B14C9B for ; Sat, 27 Nov 1999 04:04:05 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id EAA02377; Sat, 27 Nov 1999 04:04:04 -0800 (PST) Date: Sat, 27 Nov 1999 04:04:03 -0800 (PST) From: Julian Elischer To: "Daniel M. Eischen" Cc: arch@freebsd.org Subject: Re: Threads stuff In-Reply-To: <383FC334.F96FDAB1@vigrid.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Now that is a good idea.. :-) On Sat, 27 Nov 1999, Daniel M. Eischen wrote: > Julian Elischer wrote: > > > > ok well I'm only sketching out one solutionso don't feel that ai'm > > bullying you into anything.. > > > > in this scheme however there is nothing to say that we can't keep track of > > time spent in IO. > > As long as the UTS was informed of the time spent in the kernel (I suppose > via the IO control block?) for each KSE, then that would probably be good > enough. > > Currently under libc_r, it is almost inevitable that every thread switch > needs to make a system call or two, even if you ignore setting the signal > masks and use _setjmp/_longjmp. We have to call gettimeofday() to get the > time, calculate the time that the current thread should be switched out > (assuming it doesn't block before then), and make a call to setitimer(). > > If we are going to try and optimize away the system call needed to > resume a thread after its work in the kernel is completed, then let > us also look at other ways to eliminate system calls :-) > > If the upcall that notifies the UTS of unblocked threads also supplies > the current time, as well as time spent in the kernel for each completed > KSE, then that would eliminate the need to perform gettimeofday(). We > still need to schedule some sort of signal (or upcall) to tell us when > the current threads quantum has been reached. If we supply a > thread_resume_with_quantum(), then we can resume the thread and schedule > the signal (or whatever) all in one system call. > > Dan Eischen > eischen@vigrid.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 27 6:30:26 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id E0B5014C9F for ; Sat, 27 Nov 1999 06:30:22 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id PAA08040 for ; Sat, 27 Nov 1999 15:30:21 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA53012 for freebsd-arch@freebsd.org; Sat, 27 Nov 1999 15:30:20 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 307A214D09 for ; Sat, 27 Nov 1999 03:40:27 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt37.pcnet.net [206.105.29.111]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id GAA03816; Sat, 27 Nov 1999 06:40:27 -0500 (EST) Message-ID: <383FC334.F96FDAB1@vigrid.com> Date: Sat, 27 Nov 1999 06:40:36 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: arch@freebsd.org Subject: Re: Threads stuff References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > > ok well I'm only sketching out one solutionso don't feel that ai'm > bullying you into anything.. > > in this scheme however there is nothing to say that we can't keep track of > time spent in IO. As long as the UTS was informed of the time spent in the kernel (I suppose via the IO control block?) for each KSE, then that would probably be good enough. Currently under libc_r, it is almost inevitable that every thread switch needs to make a system call or two, even if you ignore setting the signal masks and use _setjmp/_longjmp. We have to call gettimeofday() to get the time, calculate the time that the current thread should be switched out (assuming it doesn't block before then), and make a call to setitimer(). If we are going to try and optimize away the system call needed to resume a thread after its work in the kernel is completed, then let us also look at other ways to eliminate system calls :-) If the upcall that notifies the UTS of unblocked threads also supplies the current time, as well as time spent in the kernel for each completed KSE, then that would eliminate the need to perform gettimeofday(). We still need to schedule some sort of signal (or upcall) to tell us when the current threads quantum has been reached. If we supply a thread_resume_with_quantum(), then we can resume the thread and schedule the signal (or whatever) all in one system call. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 27 14:39:36 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 8BB3714BDC for ; Sat, 27 Nov 1999 14:39:31 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA13010 for ; Sat, 27 Nov 1999 23:39:30 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA54840 for freebsd-arch@freebsd.org; Sat, 27 Nov 1999 23:39:29 +0100 (MET) Received: from io.yi.org (24.66.174.118.bc.wave.home.com [24.66.174.118]) by hub.freebsd.org (Postfix) with ESMTP id 0185A14BDC for ; Sat, 27 Nov 1999 14:39:03 -0800 (PST) (envelope-from jburkhol@home.com) Received: from io.yi.org (localhost [127.0.0.1]) by io.yi.org (Postfix) with ESMTP id 22A511FCF; Sat, 27 Nov 1999 14:39:09 -0800 (PST) X-Mailer: exmh version 2.1.1 10/15/1999 To: "Daniel M. Eischen" Cc: Julian Elischer , arch@freebsd.org Subject: Re: Threads stuff In-reply-to: Your message of "Sat, 27 Nov 1999 06:40:36 EST." <383FC334.F96FDAB1@vigrid.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Nov 1999 14:39:08 -0800 From: Jake Burkholder Message-Id: <19991127223909.22A511FCF@io.yi.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Julian Elischer wrote: > > > > ok well I'm only sketching out one solutionso don't feel that ai'm > > bullying you into anything.. > > > > in this scheme however there is nothing to say that we can't keep track of > > time spent in IO. > > As long as the UTS was informed of the time spent in the kernel (I suppose > via the IO control block?) for each KSE, then that would probably be good > enough. I've put a diagram up on my web page that tries to incorporate some of these ideas. I haven't included the queue-ing, because that seems basically agreed upon. http://24.66.174.118/ Both a gif and the tgif obj file are there. I hope its not confusing. The arrows are meant trace the path that the scheduler and a thread making a blocking or non-blocking system call might take, and the ellipses are states I guess. I'm just going from what Daniel said about libc_r having to get the time of day and set the interval timer in order to do a context switch, which can probably be done in one system call. Either the context can be saved in userland, in which case the scheduler returns normally, and does a longjmp or the equivalent, or the thread could be resumed as part of the system call. Let me know what you think. thanks, Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 27 15:49:23 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2AA6214D01 for ; Sat, 27 Nov 1999 15:49:20 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA13538 for ; Sun, 28 Nov 1999 00:49:19 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA55126 for freebsd-arch@freebsd.org; Sun, 28 Nov 1999 00:49:18 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id CF00714D01 for ; Sat, 27 Nov 1999 15:49:11 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id PAA10321 for ; Sat, 27 Nov 1999 15:49:11 -0800 (PST) Date: Sat, 27 Nov 1999 15:49:11 -0800 (PST) From: Julian Elischer To: arch@freebsd.org Subject: Re: Threads stuff In-Reply-To: <19991127223909.22A511FCF@io.yi.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 27 Nov 1999, Jake Burkholder wrote: > > Julian Elischer wrote: > > > > > > > As long as the UTS was informed of the time spent in the kernel (I suppose > > via the IO control block?) for each KSE, then that would probably be good > > enough. > > I've put a diagram up on my web page that tries to incorporate > some of these ideas. I haven't included the queue-ing, because > that seems basically agreed upon. [...] > I'm just going from what Daniel said about libc_r having > to get the time of day and set the interval timer in > order to do a context switch, which can probably be > done in one system call. Either the context can be > saved in userland, in which case the scheduler returns > normally, and does a longjmp or the equivalent, > or the thread could be resumed as part of the > system call. > I don't know what Danthiks but this has alot more involvement or the kernel and boundary crossing than I was envisionning. I will try make aset of diagrams that outline the state of various objects related to a thread at various stages.. Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 27 19:39:46 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id E5AD014EF6 for ; Sat, 27 Nov 1999 19:39:42 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA16148 for ; Sun, 28 Nov 1999 04:39:37 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA56083 for freebsd-arch@freebsd.org; Sun, 28 Nov 1999 04:39:36 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 2011314EF6 for ; Sat, 27 Nov 1999 19:38:57 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id TAA40637; Sat, 27 Nov 1999 19:38:52 -0800 (PST) (envelope-from dillon) Date: Sat, 27 Nov 1999 19:38:52 -0800 (PST) From: Matthew Dillon Message-Id: <199911280338.TAA40637@apollo.backplane.com> To: Jason Evans Cc: freebsd-arch@freebsd.org Subject: Re: Threads References: <199911241905.LAA20045@apollo.backplane.com> <14396.15070.190669.25400@avalon.east> <199911241941.LAA20231@apollo.backplane.com> <19991124212521.W301@sturm.canonware.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Until reading about DEC's threading efforts :(http://www.digital.com/info/DTJF03/DTJF03SC.TXT) a few days ago, I would :have agreed with you. However, that paper makes some very valid arguments :for needing multiple scheduling queues. The paper is very worthwhile :reading. : :Jason hmm. A very interesting article. They could well be correct - certainly a single scheduling queue would become a problem if you have many processors. I don't think there would be much contention with 4-8 cpu's, at least not if we limit the lock to *just* the operation surrounding the addition and removal of the KSE (using Julian's terminology) from the queue. Also, this contention would *not* occur during a context switch, only when a task is scheduled and descheduled. For a task switch, we simply trylock the next task in the queue relative to the current one - no locking of the 'queue' itself is really required. Many cpu's could be operating on the same queue and scale just fine for the task switch. Oh fubar, I went back to my own terminology. task == KSE. We have to balance the time lost through potential lock contention against the extra overhead of managing multiple queues, so perhaps an examination of the overhead required to manage multiple queues is in order. Here's my take: Lets say that each cpu has its own queue. Let us further say that we implement a simple aggregate priority mechanism to balance the load on each cpu, and further say that we have a rollover mechanism when a cpu's queue is empty - the scheduler for that cpu rolls over to another cpu's queue. Ok, so we have three situations: * task is woken up. Must select cpu to place task on. There is some extra overhead here. * task goes to sleep, is removed from current queue. Lock current queue. No additional overhead verses one-queue model. * task switch. No additional overhead under load (which may be all that matters), some additional overhead if queue is empty (we have to pull a task off another queue or ask the system to rebalance the queues). Overheads in a single queue system: * Skip-over. N cpu's, thus N tasks running, N+1 tasks runnable. cpu doing the switching must skip over N tasks to find the one that is runnable. * Lock contention The added complexity does not seem too bad, but we would have to deal with queue rebalancing issues which could get pretty sticky. Having a single queue is a lot easier to manage in regards to implementing various sorts of schedulers. For example, you can create a recursive scheduler hierarchy very easily. On the otherhand, I totally forgot about the skip-over problem which you have with a single queue. The only real way to deal with skip-over is to actually dequeue the task currently running (on any given cpu). The advantage is that then you don't have to do anything to it if it goes to sleep, the disadvantage is greater scheduler overhead because a separate pointer into the circular runnable list must be maintained. Another possible solution to the single-queue case is to not lock the queue for sleep/wakeup operations but to instead shared-lock the surrounding task(s). This would allow multiple cpu's to add and remove tasks from different parts of a single queue simultaniously. I've never done this myself -- it's never seemed worthwhile. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 27 20:38:55 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id A4B9014DD8 for ; Sat, 27 Nov 1999 20:38:52 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id FAA16685 for ; Sun, 28 Nov 1999 05:38:51 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA56205 for freebsd-arch@freebsd.org; Sun, 28 Nov 1999 05:38:51 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 4876114DD8 for ; Sat, 27 Nov 1999 20:38:44 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt104.pcnet.net [206.105.29.178]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id XAA16392; Sat, 27 Nov 1999 23:38:45 -0500 (EST) Message-ID: <3840B1EC.4614AAF0@vigrid.com> Date: Sat, 27 Nov 1999 23:39:08 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: arch@freebsd.org Subject: Re: Threads stuff References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > > > I've put a diagram up on my web page that tries to incorporate > > some of these ideas. I haven't included the queue-ing, because > > that seems basically agreed upon. > [...] > > I'm just going from what Daniel said about libc_r having > > to get the time of day and set the interval timer in > > order to do a context switch, which can probably be > > done in one system call. Either the context can be > > saved in userland, in which case the scheduler returns > > normally, and does a longjmp or the equivalent, > > or the thread could be resumed as part of the > > system call. > > > > I don't know what Danthiks but this has alot more involvement or the > kernel and boundary crossing than I was envisionning. I think it's basically right. If you saw the diagram at different stages, it would be easier to see. o A thread blocks in kernel, the KSE is saved, a new KSE is allocated, and an upcall is made to the scheduler with a unique KSE ID provided to identify the now blocked thread. o Scheduler receives notification of a thread blocking, tags the currently running thread with the KSE ID, chooses a new thread to run, switches to the new thread, and makes a system call to schedule a signal/upcall when the new threads quantum expires. o A KSE is woken up in the kernel. o Scheduler receives notification of a thread unblocking (finishing?) in the kernel. o At the request of the scheduler, the kernel schedules a timeout for the new quantum and resumes the now unblocked thread. > I will try make aset of diagrams that outline the state of various > objects related to a thread at various stages.. How about an animated GIF or MOV? ;-) Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 27 20:58: 7 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3706314E74 for ; Sat, 27 Nov 1999 20:58:01 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id FAA16864 for ; Sun, 28 Nov 1999 05:58:00 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA56260 for freebsd-arch@freebsd.org; Sun, 28 Nov 1999 05:58:00 +0100 (MET) Received: from c62443-a.frmt1.sfba.home.com (c62443-a.frmt1.sfba.home.com [24.0.69.165]) by hub.freebsd.org (Postfix) with ESMTP id 9EECF14E74 for ; Sat, 27 Nov 1999 20:57:53 -0800 (PST) (envelope-from adsharma@c62443-a.frmt1.sfba.home.com) Received: (from adsharma@localhost) by c62443-a.frmt1.sfba.home.com (8.9.3/8.9.3) id UAA07234; Sat, 27 Nov 1999 20:57:53 -0800 Date: Sat, 27 Nov 1999 20:57:52 -0800 From: Arun Sharma To: Matthew Dillon Cc: freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <19991127205752.A7145@sharmas.dhs.org> References: <199911241905.LAA20045@apollo.backplane.com> <14396.15070.190669.25400@avalon.east> <199911241941.LAA20231@apollo.backplane.com> <19991124212521.W301@sturm.canonware.com> <199911280338.TAA40637@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <199911280338.TAA40637@apollo.backplane.com>; from Matthew Dillon on Sat, Nov 27, 1999 at 07:38:52PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Nov 27, 1999 at 07:38:52PM -0800, Matthew Dillon wrote: > > hmm. A very interesting article. They could well be correct - certainly > a single scheduling queue would become a problem if you have many > processors. I don't think there would be much contention with 4-8 cpu's, > at least not if we limit the lock to *just* the operation surrounding > the addition and removal of the KSE (using Julian's terminology) from > the queue. Also, this contention would *not* occur during a context > switch, only when a task is scheduled and descheduled. Locking of the runqueue is a problem, unless changes are made to the current BSD scheduler. (a) schedcpu() is called every hz ticks. This requires locking the runqueues. On a SMP system, all other processors are completely locked out. Clearly, someone needs to redesign the system such that priorities get recomputed in an event driven fashion. Uresh Vahalia's book (Ch 5.5.6) talks about this. (b) If you want to implement processor binding, the implementation is simpler with per cpu runqueues. (c) Although not a justification by itself, I remember reading that the most recent version of AIX uses per cpu runqueues to scale better on SMP. On the other hand, implementing scheduler activations and SMP scaling simultaneously would be too much of a change. It might be a good idea to do one thing at a time. -Arun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 27 22:34:52 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 19A7514D69 for ; Sat, 27 Nov 1999 22:34:48 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id HAA17842 for ; Sun, 28 Nov 1999 07:34:47 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id HAA56423 for freebsd-arch@freebsd.org; Sun, 28 Nov 1999 07:34:46 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id C14CC1558E for ; Sat, 27 Nov 1999 22:34:18 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id WAA14771; Sat, 27 Nov 1999 22:34:16 -0800 (PST) Date: Sat, 27 Nov 1999 22:34:16 -0800 (PST) From: Julian Elischer To: "Daniel M. Eischen" Cc: arch@freebsd.org Subject: Re: Threads stuff In-Reply-To: <3840B1EC.4614AAF0@vigrid.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 27 Nov 1999, Daniel M. Eischen wrote: > I think it's basically right. If you saw the diagram at different > stages, it would be easier to see. look at: http://www.freebsd.org/~julian/threads The .obj file is the tgif source for the 7 stages. stages 6 and 7 are not wuite worked out yet.. teh question is "Who makes teh decision to pre-empt a running thread, and continue the unblocked thread in the kernel? (step 6) I have shown it in step 6 as though the kernel took it upon itself to do so, (for example at a quantum boundary) but if teh user decided to do it then the situation would skip straight to step 7 because the thread state would already be in the right place. I'm puting these out just to get comments.. The shaded areas are where there has been a change. tell me what you think of this format. > > o A thread blocks in kernel, the KSE is saved, a new KSE is allocated, > and an upcall is made to the scheduler with a unique KSE ID provided > to identify the now blocked thread. > > o Scheduler receives notification of a thread blocking, tags the > currently running thread with the KSE ID, chooses a new thread > to run, switches to the new thread, and makes a system call to > schedule a signal/upcall when the new threads quantum expires. > > o A KSE is woken up in the kernel. > > o Scheduler receives notification of a thread unblocking (finishing?) > in the kernel. Here's where I get into difficulty.. shoul d we notify the UTS on unblocking, or on completion? or both? > > o At the request of the scheduler, the kernel schedules a timeout for > the new quantum and resumes the now unblocked thread. define " the kernel schedules a timeout for the new quantum and resumes the now unblocked thread" > > > I will try make aset of diagrams that outline the state of various > > objects related to a thread at various stages.. > > How about an animated GIF or MOV? ;-) almost.. note that by sheet 7 everything is back where it was in sheet 1 julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message