From owner-freebsd-arch Sun Dec 12 0:42: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 2A89D14D5D for ; Sun, 12 Dec 1999 00:42: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 JAA20981 for ; Sun, 12 Dec 1999 09:42:51 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id JAA48452 for freebsd-arch@freebsd.org; Sun, 12 Dec 1999 09:42:51 +0100 (MET) Received: from smtp05.wxs.nl (smtp05.wxs.nl [195.121.6.57]) by hub.freebsd.org (Postfix) with ESMTP id 9CF8F14D5D; Sun, 12 Dec 1999 00:42:03 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org ([195.121.197.150]) by smtp05.wxs.nl (Netscape Messaging Server 4.05) with ESMTP id FMMDI202.N6G; Sun, 12 Dec 1999 09:42:02 +0100 Received: (from asmodai@localhost) by daemon.ninth-circle.org (8.9.3/8.9.3) id JAA34452; Sun, 12 Dec 1999 09:41:42 +0100 (CET) (envelope-from asmodai) Date: Sun, 12 Dec 1999 09:41:42 +0100 From: Jeroen Ruigrok/Asmodai To: Yoshinobu Inoue Cc: freebsd-arch@freebsd.org, cvs-committers@freebsd.org Subject: Re: [Solicite review for KAME 5th patch] Message-ID: <19991212094142.F32274@daemon.ninth-circle.org> References: <19991212040532I.shin@nd.net.fujitsu.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <19991212040532I.shin@nd.net.fujitsu.co.jp>; from shin@nd.net.fujitsu.co.jp on Sun, Dec 12, 1999 at 04:05:32AM +0900 Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [19991211 20:37], Yoshinobu Inoue (shin@nd.net.fujitsu.co.jp) wrote: >People should be busy, but this is 5th KAME patches. >Please give me any comments if someone have time to check it. >And if not much comments for KAME 4th patches I'll commit it. >It is extensions to libc, but it only includes newly added >IPv6 specific files I will look over it. Just make sure we are given some time before committing. We are in no need to rush it in, for all I know. Waiting a day or two longer doesn't hurt the progress and gives people a chance to review the patches. -- Jeroen Ruigrok van der Werven/Asmodai asmodai@[wxs.nl|bart.nl] Documentation nutter. *BSD: Technical excellence at its best... The BSD Programmer's Documentation Project Atone me to my throes curtail... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 12 0:52: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 6AF1C14F2B for ; Sun, 12 Dec 1999 00:52: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 JAA21055 for ; Sun, 12 Dec 1999 09:52:38 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id JAA48494 for freebsd-arch@freebsd.org; Sun, 12 Dec 1999 09:52:38 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 8C78A14F01 for ; Sun, 12 Dec 1999 00:52: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 AAA79273 for ; Sun, 12 Dec 1999 00:52:31 -0800 (PST) Date: Sun, 12 Dec 1999 00:52:30 -0800 (PST) From: Julian Elischer To: arch@freebsd.org Subject: Recent face to face threads talks. 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 promissed various people that I would report back what was discussed. basically several people were present: Matt Dillon Terry lambert Me, Alfred Perlstein, Matt Jacob Jason Evans Mike Smith Arun Sharma "The Berkeley Guy" (John, Sorry I've forgotten your surname) A bunch of locals. About 20 to 30 people showed up I think. John (The Berleley guy) reported on an experiment he had done in which he added an rfork() to tsleep and thus effected "lazy linux threads" (for want of a better name). The blocked call returned with an EASYNC in the new process while the original waited in the kernel, He reported that this led to similar performance figures to teh straight "linux threads" style approach. He did this in 3.1 and since discarded the code as it had no advantage. We then discussed the ideas involved in a 'SA-style' approach. The discussion was largely spent in getting everyone to understand the same concepts in the same ways, and a lot of it was spent in working out what subset of the SA style of things might be a good first step. A lot of time was spent discussing the mechanisms by which the UTS received upcalls and how KSE's would resume. It was agreed that thread classes could be implemented by a structure half way between a process and a KSE on the linkage scale of things, that would own KSEs and which would be scheduled onto processors. This basically corresponds to what I've been calling a "subproc". In our diagrams it was designapted "Q" as P was already taken (for Proc). This was actually an apt name as this structure si what is put in the run queue. It was also agreed that to start off this would be a virtual structure an it would be part of the "proc" struct for the first revisions. KSE's would be on the sleep queues and Q's are on the run queues when they have 1 or more KSE runnable. Where the User thread state was stored during a syscall was discussed but I think this needs to be discussed more. The discision was that we'd try do this without a new syscall interface (except for one or two new syscalls (like the upcall registration). I will try write another email with more detailed information but in the meanwhile if anyone else wnats to add what they took away from it, that would be great. Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 12 5: 0: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 7797A14E12 for ; Sun, 12 Dec 1999 05:00: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 OAA22240 for ; Sun, 12 Dec 1999 14:00:14 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA48974 for freebsd-arch@freebsd.org; Sun, 12 Dec 1999 14:00:13 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 1A34E14EA0 for ; Sun, 12 Dec 1999 05:00:07 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt10.pcnet.net [206.105.29.84]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id HAA26560; Sun, 12 Dec 1999 07:59:58 -0500 (EST) Message-ID: <38539C2B.9632089A@vigrid.com> Date: Sun, 12 Dec 1999 07:59:23 -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: Recent face to face threads talks. 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 promissed various people that I would report back what was discussed. Thanks! > We then discussed the ideas involved in a 'SA-style' approach. The > discussion was largely spent in getting everyone to understand the same > concepts in the same ways, and a lot of it was spent in working out > what subset of the SA style of things might be a good first step. > > A lot of time was spent discussing the mechanisms by which the UTS > received upcalls and how KSE's would resume. It was agreed that > thread classes could be implemented by a structure half way between a > process and a KSE on the linkage scale of things, that would own KSEs > and which would be scheduled onto processors. This basically corresponds > to what I've been calling a "subproc". In our diagrams it was designapted > "Q" as P was already taken (for Proc). This was actually an apt name as > this structure si what is put in the run queue. It was also agreed that to > start off this would be a virtual structure an it would be part of the > "proc" struct for the first revisions. Wouldn't this be akin to what other systems call a kernel thread or LWP? And could we use the same "Q" in our kernel for async I/O or interrupt threads? It could easily be attached or detached from a user space. It is important that this "Q" be able to have it's own resources though, and not necessarily be tied to a procs resources. > > KSE's would be on the sleep queues and Q's are on the run queues when > they have 1 or more KSE runnable. Where the User thread state was stored > during a syscall was discussed but I think this needs to be discussed > more. The discision was that we'd try do this without a new syscall > interface (except for one or two new syscalls (like the upcall > registration). Yes, we can pass the trapframe/context of a preempted or unblocked thread out to the upcall handler and not have to use a different call-gate. One advantage of another call-gate could be faster access to the unblocked thread. In order for the UTS to locate an unblocked thread from the information provided in the upcall, the UTS has to walk the unblocked thread list looking for the KSE ID. If you use another syscall-gate and provide the address of an IOCB, the address of the IOCB can be given to the blocked upcall handler. The UTS can then place the pointer to the thread struct in the IOCB. When the thread unblocks, the address of the IOCB is provided to the upcall handler and the UTS can just dereference it to find the thread struct. 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 Dec 12 5: 9: 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 CC3E814F0A for ; Sun, 12 Dec 1999 05:09:05 -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 OAA22277 for ; Sun, 12 Dec 1999 14:09:04 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA49020 for freebsd-arch@freebsd.org; Sun, 12 Dec 1999 14:09:04 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 0B7F214E49 for ; Sun, 12 Dec 1999 05:08:57 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt10.pcnet.net [206.105.29.84]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id IAA27757; Sun, 12 Dec 1999 08:08:55 -0500 (EST) Message-ID: <38539E44.537A57E@vigrid.com> Date: Sun, 12 Dec 1999 08:08:20 -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 , arch@freebsd.org Subject: Re: Recent face to face threads talks. References: <38539C2B.9632089A@vigrid.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I should caffeinate before reading Email! "Daniel M. Eischen" wrote: > Yes, we can pass the trapframe/context of a preempted or unblocked thread > out to the upcall handler and not have to use a different call-gate. > One advantage of another call-gate could be faster access to the > unblocked thread. In order for the UTS to locate an unblocked thread > from the information provided in the upcall, the UTS has to walk the > unblocked thread list looking for the KSE ID. If you use another ^^^^^^^^^ blocked > syscall-gate and provide the address of an IOCB, the address of the > IOCB can be given to the blocked upcall handler. The UTS can then > place the pointer to the thread struct in the IOCB. When the thread > unblocks, the address of the IOCB is provided to the upcall handler > and the UTS can just dereference it to find the thread struct. > > 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 Dec 12 5:33: 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 EE1EB14F9C for ; Sun, 12 Dec 1999 05:33: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 OAA22434 for ; Sun, 12 Dec 1999 14:32:58 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA49099 for freebsd-arch@freebsd.org; Sun, 12 Dec 1999 14:32:57 +0100 (MET) Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36]) by hub.freebsd.org (Postfix) with ESMTP id 9D69914F63; Sun, 12 Dec 1999 05:32:50 -0800 (PST) (envelope-from shin@nd.net.fujitsu.co.jp) Received: from m1.gw.fujitsu.co.jp by fgwmail6.fujitsu.co.jp (8.9.3/3.7W-MX9911-Fujitsu Gateway) id WAA27169; Sun, 12 Dec 1999 22:32:49 +0900 (JST) Received: from incapgw.fujitsu.co.jp by m1.gw.fujitsu.co.jp (8.9.3/3.7W-9912-Fujitsu Domain Master) id WAA22540; Sun, 12 Dec 1999 22:32:48 +0900 (JST) Received: from localhost ([192.168.245.169]) by incapgw.fujitsu.co.jp (8.9.3/3.7W-9912) id WAA22723; Sun, 12 Dec 1999 22:32:47 +0900 (JST) To: green@freebsd.org Cc: freebsd-arch@freebsd.org, cvs-committers@freebsd.org Subject: Re: [Solicite review for KAME 5th patch] In-Reply-To: References: <19991212040532I.shin@nd.net.fujitsu.co.jp> X-Prom-Mew: Prom-Mew 1.93.4 (procmail reader for Mew) X-Mailer: Mew version 1.94 on Emacs 20.4 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19991212223306D.shin@nd.net.fujitsu.co.jp> Date: Sun, 12 Dec 1999 22:33:06 +0900 From: Yoshinobu Inoue X-Dispatcher: imput version 990905(IM130) Lines: 15 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Do you think you could investigate updating ip6_fw's functionality to > match that of the IPv4 IPFW? If you need help doing this, I am > certainly willing. > Then again, I'd think it would be possible to merge the two... I agree. Trying to update current IPv4 IPFW to IPv4/IPv6 IPFW will be most straight-forward. I'll try to investigate it and temporally remove IPv6 IPFW part included in the last patches. Yoshinobu Inoue > -- > 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 Sun Dec 12 5:36: 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 134911537B for ; Sun, 12 Dec 1999 05:35: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 OAA22462 for ; Sun, 12 Dec 1999 14:35:53 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA49129 for freebsd-arch@freebsd.org; Sun, 12 Dec 1999 14:35:53 +0100 (MET) Received: from fgwmail7.fujitsu.co.jp (fgwmail7.fujitsu.co.jp [192.51.44.37]) by hub.freebsd.org (Postfix) with ESMTP id 7921D14F65; Sun, 12 Dec 1999 05:35:46 -0800 (PST) (envelope-from shin@nd.net.fujitsu.co.jp) Received: from m4.gw.fujitsu.co.jp by fgwmail7.fujitsu.co.jp (8.9.3/3.7W-MX9911-Fujitsu Gateway) id WAA18499; Sun, 12 Dec 1999 22:35:33 +0900 (JST) Received: from incapgw.fujitsu.co.jp by m4.gw.fujitsu.co.jp (8.9.3/3.7W-9912-Fujitsu Domain Master) id WAA13254; Sun, 12 Dec 1999 22:35:32 +0900 (JST) Received: from localhost ([192.168.245.169]) by incapgw.fujitsu.co.jp (8.9.3/3.7W-9912) id WAA22841; Sun, 12 Dec 1999 22:35:30 +0900 (JST) To: asmodai@wxs.nl Cc: freebsd-arch@freebsd.org, cvs-committers@freebsd.org Subject: Re: [Solicite review for KAME 5th patch] In-Reply-To: <19991212094142.F32274@daemon.ninth-circle.org> References: <19991212040532I.shin@nd.net.fujitsu.co.jp> <19991212094142.F32274@daemon.ninth-circle.org> X-Prom-Mew: Prom-Mew 1.93.4 (procmail reader for Mew) X-Mailer: Mew version 1.94 on Emacs 20.4 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19991212223550M.shin@nd.net.fujitsu.co.jp> Date: Sun, 12 Dec 1999 22:35:50 +0900 From: Yoshinobu Inoue X-Dispatcher: imput version 990905(IM130) Lines: 26 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I will look over it. Just make sure we are given some time before > committing. We are in no need to rush it in, for all I know. Thanks and yes. I thought future maintenance of IPv6 related code parts on HEAD branch and comming 4.0 branch will become easier if as much as possible code is added before 4.0 branch is created. But anyway I don't know yet how new functionalities are put into new branches, and also it becomes more and more likely that enough functionalities for IPv6 won't be added before Dec 15th, as I find new issues which need to be resolved. > Waiting a day or two longer doesn't hurt the progress and gives people a > chance to review the patches. Yes, and also I still need to complete ip_output() part. Yoshinobu Inoue > -- > Jeroen Ruigrok van der Werven/Asmodai asmodai@[wxs.nl|bart.nl] > Documentation nutter. *BSD: Technical excellence at its best... > The BSD Programmer's Documentation Project > Atone me to my throes curtail... > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 12 8:26: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 C0B1C14CE1 for ; Sun, 12 Dec 1999 08:26: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 RAA23356 for ; Sun, 12 Dec 1999 17:26:34 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA49732 for freebsd-arch@freebsd.org; Sun, 12 Dec 1999 17:26:33 +0100 (MET) Received: from knight.cons.org (knight.cons.org [194.233.237.195]) by hub.freebsd.org (Postfix) with ESMTP id 4ED3E14E33; Sun, 12 Dec 1999 08:26:06 -0800 (PST) (envelope-from cracauer@knight.cons.org) Received: (from cracauer@localhost) by knight.cons.org (8.9.3/8.9.3) id RAA10645; Sun, 12 Dec 1999 17:26:03 +0100 (CET) Date: Sun, 12 Dec 1999 17:26:02 +0100 From: Martin Cracauer To: arch@freebsd.org Cc: marcel@freebsd.org, bde@freebsd.org Subject: Concrete plans for ucontext/mcontext changes around 4.0 Message-ID: <19991212172602.A10611@cons.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Here's my summary what to do with signal handler arguments until 4.0: 1) Before feature freeze: get the size of ucontext/mcontext into what we can live with for a longer time (i.e. until 5.0 or serious other changes). - Correct the size of the FPU/FPU-emul reservation so that it is the size of struct save87 (4 bytes too much at this time). - Add space for SSE registers. - Add some more space that allows more flexible use of the SSE register space for other purposes (isn't this pretty equivalent to the 3dnow registers on AMD, BTW?). This will not be enough space for a whole new feature. - Add one int member to use as 32 bitwise booleans to indicate what the SSE/additional space is used for in this signal invocation. FPU state will unconditionally be there. 2) Actually implement the saving of FPU state over signal handlers, ASAP. I'm working on this, but the first review result by Bruce indicates I need some additional homework, so I won't be ready on 15th Dec. I don't consider this to be a new feature, it is required semantics for ANSI C compliance, so I hope its ok to do while the freeze is in effect. 3) Fix the FPU and other CPU feature set representation in struct ucontext/mcontext. As you might have noticed, I would prefer to have real structs, not byte arrays as it is now. However, this is hard to do without serious include file bloat and some people don't want it at all (other OS don't have it as well). The implementation of 1) and 2) as indicated above will have the FPU represented exactly like struct save87 (although it appears as plain array). Thus, people will be able to use the named struct field by just casting this space, not needing to count bytes. I think this is a reasonable compromise for now. When I feel an urgent need to fix this, I will work on a restructuring and unbloat of include files and see if it is considered OK. This may become irrelevant with [sg]etcontext and/or thread changes anyway. Any objections? Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 12 9:57: 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 C835214CA6 for ; Sun, 12 Dec 1999 09:57: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 SAA23984 for ; Sun, 12 Dec 1999 18:56:55 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA50148 for freebsd-arch@freebsd.org; Sun, 12 Dec 1999 18:56:55 +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 8317014C44 for ; Sun, 12 Dec 1999 09:55: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 JAA08043 for arch@FreeBSD.ORG; Sun, 12 Dec 1999 09:55:53 -0800 Date: Sun, 12 Dec 1999 09:55:53 -0800 From: Arun Sharma To: arch@freebsd.org Subject: Re: Recent face to face threads talks. Message-ID: <19991212095553.A7995@sharmas.dhs.org> References: <38539C2B.9632089A@vigrid.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <38539C2B.9632089A@vigrid.com>; from Daniel M. Eischen on Sun, Dec 12, 1999 at 07:59:23AM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Dec 12, 1999 at 07:59:23AM -0500, Daniel M. Eischen wrote: > > A lot of time was spent discussing the mechanisms by which the UTS > > received upcalls and how KSE's would resume. It was agreed that > > thread classes could be implemented by a structure half way between a > > process and a KSE on the linkage scale of things, that would own KSEs > > and which would be scheduled onto processors. This basically corresponds > > to what I've been calling a "subproc". In our diagrams it was designapted > > "Q" as P was already taken (for Proc). This was actually an apt name as > > this structure si what is put in the run queue. It was also agreed that to > > start off this would be a virtual structure an it would be part of the > > "proc" struct for the first revisions. > > Wouldn't this be akin to what other systems call a kernel thread or LWP? A kernel thread or a LWP has a 1-to-1 relationship with a kernel stack. In our discussion, a KSE has a 1-to-1 relationship with a kernel stack. The purpose of the Q structure was to enforce "scheduling classes" - to represent a set of threads having the same priority and to ensure fairness in the scheduler. Apart from this distinction, KSE is the closest to a kernel thread/LWP and could possibly be used to implement blocking interrupt threads. It was also agreed that it doesn't make sense to do everything at once, but do it in some sensible order, without precluding elements of the design. Some of the tasks - break the proc structure into a proc and KSE, per CPU scheduling queues, implementing SA. My personal opinion is that it might be easier to go in steps - rfork/clone based implementation (aka linuxthreads), then a Solaris like m x n implementation and then scheduler activations. Implementation wise, they're in the increasing order of difficulty. From what I heard from Terry, this is also the path that Solaris took. This also lets application writers pick the right model for their work. If we stick to the POSIX threads interface strictly, we shouldn't be afraid of getting stuck with one of the implementations. Other concerns that were expressed - crossing protection boundaries too often to pass messages about blocking and rescheduling. Matt Dillon responded that these messages could be batched and made more efficient. -Arun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 12 11:14: 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 0F2DE14C9F for ; Sun, 12 Dec 1999 11:13: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 UAA24477 for ; Sun, 12 Dec 1999 20:13:54 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA50371 for freebsd-arch@freebsd.org; Sun, 12 Dec 1999 20:13:54 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 77F9C14D4E for ; Sun, 12 Dec 1999 11:13:35 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt29.pcnet.net [206.105.29.103]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id OAA06133; Sun, 12 Dec 1999 14:13:33 -0500 (EST) Message-ID: <3853F3C0.EE96FB16@vigrid.com> Date: Sun, 12 Dec 1999 14:13:04 -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: Arun Sharma Cc: arch@freebsd.org Subject: Re: Recent face to face threads talks. References: <38539C2B.9632089A@vigrid.com> <19991212095553.A7995@sharmas.dhs.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Arun Sharma wrote: > > On Sun, Dec 12, 1999 at 07:59:23AM -0500, Daniel M. Eischen wrote: > > > A lot of time was spent discussing the mechanisms by which the UTS > > > received upcalls and how KSE's would resume. It was agreed that > > > thread classes could be implemented by a structure half way between a > > > process and a KSE on the linkage scale of things, that would own KSEs > > > and which would be scheduled onto processors. This basically corresponds > > > to what I've been calling a "subproc". In our diagrams it was designapted > > > "Q" as P was already taken (for Proc). This was actually an apt name as > > > this structure si what is put in the run queue. It was also agreed that to > > > start off this would be a virtual structure an it would be part of the > > > "proc" struct for the first revisions. > > > > Wouldn't this be akin to what other systems call a kernel thread or LWP? > > A kernel thread or a LWP has a 1-to-1 relationship with a kernel stack. > In our discussion, a KSE has a 1-to-1 relationship with a kernel stack. The > purpose of the Q structure was to enforce "scheduling classes" - to > represent a set of threads having the same priority and to ensure > fairness in the scheduler. > > Apart from this distinction, KSE is the closest to a kernel thread/LWP > and could possibly be used to implement blocking interrupt threads. A KSE can't be placed in the run queue (or isn't in our implementation). A LWP or kernel thread can be. A LWP can have it's own priority. I'd argue that our Q much closer resembles a LWP than does a KSE. > It was also agreed that it doesn't make sense to do everything at once, > but do it in some sensible order, without precluding elements of the > design. Some of the tasks - break the proc structure into a proc and KSE, > per CPU scheduling queues, implementing SA. > > My personal opinion is that it might be easier to go in steps - > rfork/clone based implementation (aka linuxthreads), then a Solaris like > m x n implementation and then scheduler activations. Implementation wise, > they're in the increasing order of difficulty. From what I heard from > Terry, this is also the path that Solaris took. This also lets application > writers pick the right model for their work. I dunno. It seems easier to me to implement SA from the start, concentrating on eliminating much of the extraneous code in libc_r. I'd start with making it only work for one process or Q. The userland part of this seems really easy to me. Once that works, I'd add the ability to have multiple Q's. > If we stick to the POSIX threads interface strictly, we shouldn't be > afraid of getting stuck with one of the implementations. > > Other concerns that were expressed - crossing protection boundaries too > often to pass messages about blocking and rescheduling. Matt Dillon > responded that these messages could be batched and made more efficient. I agree. It seemed like the SA paper went to extremes in notifying the UTS of unblocked threads. I think we can do this at more opportune times, like when a Q is resumed or on a user->kernel crossing. I don't know that we want to be interrupting a Q while it is running a thread just to notify the UTS that another thread has unblocked in the kernel. 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 Dec 12 12:49: 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 7721714CC2 for ; Sun, 12 Dec 1999 12:49:03 -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 VAA25094 for ; Sun, 12 Dec 1999 21:49:01 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA50645 for freebsd-arch@freebsd.org; Sun, 12 Dec 1999 21:49:00 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id BBEC714DA2 for ; Sun, 12 Dec 1999 12:48:39 -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 MAA89701; Sun, 12 Dec 1999 12:48:38 -0800 (PST) Date: Sun, 12 Dec 1999 12:48:37 -0800 (PST) From: Julian Elischer To: Arun Sharma Cc: arch@freebsd.org Subject: Re: Recent face to face threads talks. In-Reply-To: <19991212095553.A7995@sharmas.dhs.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 Sun, 12 Dec 1999, Arun Sharma wrote: > On Sun, Dec 12, 1999 at 07:59:23AM -0500, Daniel M. Eischen wrote: > > > A lot of time was spent discussing the mechanisms by which the UTS > > > received upcalls and how KSE's would resume. It was agreed that > > > thread classes could be implemented by a structure half way between a > > > process and a KSE on the linkage scale of things, that would own KSEs > > > and which would be scheduled onto processors. This basically corresponds > > > to what I've been calling a "subproc". In our diagrams it was designapted > > > "Q" as P was already taken (for Proc). This was actually an apt name as > > > this structure si what is put in the run queue. It was also agreed that to > > > start off this would be a virtual structure an it would be part of the > > > "proc" struct for the first revisions. > > > > Wouldn't this be akin to what other systems call a kernel thread or LWP? > > A kernel thread or a LWP has a 1-to-1 relationship with a kernel stack. > In our discussion, a KSE has a 1-to-1 relationship with a kernel stack. The > purpose of the Q structure was to enforce "scheduling classes" - to > represent a set of threads having the same priority and to ensure > fairness in the scheduler. > > Apart from this distinction, KSE is the closest to a kernel thread/LWP > and could possibly be used to implement blocking interrupt threads. > Yes we agreed that "kernel threads' would hopefully belong to a "Q" that was hung off proc0 and which would have 'realtime' scheduling characteristics. This brings up something that was mentionned but that I dont remember an explicit agreement to, though I think averyone agreed.. There is a syscall that jumpstarts the threading support. It supplies the kernel with the information needed to do upcalls. Until this call is made there can be no upcalls and the process is effectively unthreaded. This call is repeated for each 'thread class', and in fact we call it foreach CPU as well. each time you call it you define another 'virtual cpu', and supply it with upcal information. Each virtual CPU has therefore a different UTS instantiation (read stack) (they can be small). It can therefore be stated that each "Q" structure effectively corresponds to an UTS instance. To start with there will be one schedular queue but we should build with an eye on the fact that we may at some time in the future want to move to "per CPU" scheduling queues. The initital implementation would leave the "Q" struct as part of a proc struct, and we'd just do 'rfork()' to get the functionality of virtual machines. The syscall in fact would start life as a variation on the theme of rfork() > It was also agreed that it doesn't make sense to do everything at once, > but do it in some sensible order, without precluding elements of the > design. Some of the tasks - break the proc structure into a proc and KSE, > per CPU scheduling queues, implementing SA. > > My personal opinion is that it might be easier to go in steps - > rfork/clone based implementation (aka linuxthreads), then a Solaris like > m x n implementation and then scheduler activations. Implementation wise, > they're in the increasing order of difficulty. From what I heard from > Terry, this is also the path that Solaris took. This also lets application > writers pick the right model for their work. I think this is what is happenning.. Jason, Richard and Russell have been working on the linuxthreads stuff and that gives us a purely "rfork-per-thread" system. The next step will be, while people are running that, to break out the fields of the thread structure from the proc structure. We should be able to do that relatively quickly. Fixing ps(1) and procfs(4) will be more 'fun'. Once we have the system with them separated, then we can start supporting "more than one" per process. We'd still be rforking() to get our virtual machines however. At least in the earlier versions of teh upcall variety, The unblocked sysscalls will be completed back as far as the user boundary as soon as that process (Q) is next sceduled to run (which may be immediatly). The delivery of the status to the UTS and thread was discussed but needs more work. > > If we stick to the POSIX threads interface strictly, we shouldn't be > afraid of getting stuck with one of the implementations. > > Other concerns that were expressed - crossing protection boundaries too > often to pass messages about blocking and rescheduling. Matt Dillon > responded that these messages could be batched and made more efficient. Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 12 12:49: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 C87FD14CA2 for ; Sun, 12 Dec 1999 12:49: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 VAA25101 for ; Sun, 12 Dec 1999 21:49:13 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA50659 for freebsd-arch@freebsd.org; Sun, 12 Dec 1999 21:49:13 +0100 (MET) Received: from canonware.com (canonware.com [207.20.242.18]) by hub.freebsd.org (Postfix) with SMTP id 9BCC414CC2 for ; Sun, 12 Dec 1999 12:49:00 -0800 (PST) (envelope-from jasone@canonware.com) Received: (qmail 8439 invoked by uid 1001); 12 Dec 1999 20:48:41 -0000 Date: Sun, 12 Dec 1999 12:48:41 -0800 From: Jason Evans To: "Daniel M. Eischen" Cc: Arun Sharma , arch@freebsd.org Subject: Re: Recent face to face threads talks. Message-ID: <19991212124841.B350@sturm.canonware.com> References: <38539C2B.9632089A@vigrid.com> <19991212095553.A7995@sharmas.dhs.org> <3853F3C0.EE96FB16@vigrid.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3853F3C0.EE96FB16@vigrid.com>; from eischen@vigrid.com on Sun, Dec 12, 1999 at 02:13:04PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Dec 12, 1999 at 02:13:04PM -0500, Daniel M. Eischen wrote: > Arun Sharma wrote: > > Other concerns that were expressed - crossing protection boundaries too > > often to pass messages about blocking and rescheduling. Matt Dillon > > responded that these messages could be batched and made more efficient. > > I agree. It seemed like the SA paper went to extremes in notifying > the UTS of unblocked threads. I think we can do this at more opportune > times, like when a Q is resumed or on a user->kernel crossing. I don't > know that we want to be interrupting a Q while it is running a thread > just to notify the UTS that another thread has unblocked in the kernel. One aspect of the SA paper that we did not strictly adhere to in our design is the idea that activations always upcall into the UTS. In particular, we felt that it would work to restore a preempted activation rather than creating a notification and a new activation. After re-reading the SA paper (yet again), I'm not sure this saves us much performance-wise, and it probably reduces flexibility. Another aspect of the SA paper that we did not adhere to is notification of preemption. I'm not sure this is a good simplification. Without such notifications, it is not possible to know what is or isn't running on other processors, which could make certain scheduling decisions very difficult. Then again, I don't like the idea of preempting an activation so that a notification of preemption on another processor can be delivered. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 12 13: 1: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 48E6B14CA2 for ; Sun, 12 Dec 1999 13:01:38 -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 WAA25189 for ; Sun, 12 Dec 1999 22:01:31 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA50739 for freebsd-arch@freebsd.org; Sun, 12 Dec 1999 22:01:31 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id D65AA14BDA for ; Sun, 12 Dec 1999 13:01:25 -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 NAA89978; Sun, 12 Dec 1999 13:01:23 -0800 (PST) Date: Sun, 12 Dec 1999 13:01:21 -0800 (PST) From: Julian Elischer To: Jason Evans Cc: "Daniel M. Eischen" , Arun Sharma , arch@freebsd.org Subject: Re: Recent face to face threads talks. In-Reply-To: <19991212124841.B350@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 As a general commnet I think that teh 'simplifications' we discussed were basically because we couldn't see easy ways of doing them, or at least not without rewriting large amounts of stuff. I don't think what we talked about precludes any of these things, but that we didn't feen it was important enough to make them out primary objective. The decision that we would allow a process (Q) that had been involuntarily pre-empted to continue with the KSE/thread it was running before teh pre-emption is a simplification because it requires no work where calling the UTS could in fact require a lot of work. However we don't PRECLUDE someone fromd oing that work in the future. On Sun, 12 Dec 1999, Jason Evans wrote: > On Sun, Dec 12, 1999 at 02:13:04PM -0500, Daniel M. Eischen wrote: > > Arun Sharma wrote: > > > Other concerns that were expressed - crossing protection boundaries too > > > often to pass messages about blocking and rescheduling. Matt Dillon > > > responded that these messages could be batched and made more efficient. > > > > I agree. It seemed like the SA paper went to extremes in notifying > > the UTS of unblocked threads. I think we can do this at more opportune > > times, like when a Q is resumed or on a user->kernel crossing. I don't > > know that we want to be interrupting a Q while it is running a thread > > just to notify the UTS that another thread has unblocked in the kernel. > > One aspect of the SA paper that we did not strictly adhere to in our design > is the idea that activations always upcall into the UTS. In particular, we > felt that it would work to restore a preempted activation rather than > creating a notification and a new activation. After re-reading the SA > paper (yet again), I'm not sure this saves us much performance-wise, and it > probably reduces flexibility. > > Another aspect of the SA paper that we did not adhere to is notification of > preemption. I'm not sure this is a good simplification. Without such > notifications, it is not possible to know what is or isn't running on other > processors, which could make certain scheduling decisions very difficult. > Then again, I don't like the idea of preempting an activation so that a > notification of preemption on another processor can be delivered. > > Jason > > > > > 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 Sun Dec 12 13:39: 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 5DF3714D19 for ; Sun, 12 Dec 1999 13:38: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 WAA25429 for ; Sun, 12 Dec 1999 22:38:50 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA50907 for freebsd-arch@freebsd.org; Sun, 12 Dec 1999 22:38:49 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id BEE4F14DB8 for ; Sun, 12 Dec 1999 13:38:34 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt25.pcnet.net [206.105.29.99]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id QAA22653; Sun, 12 Dec 1999 16:38:29 -0500 (EST) Message-ID: <385415BC.CA3DDDC4@vigrid.com> Date: Sun, 12 Dec 1999 16:38:04 -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: Arun Sharma , arch@freebsd.org Subject: Re: Recent face to face threads talks. References: <38539C2B.9632089A@vigrid.com> <19991212095553.A7995@sharmas.dhs.org> <3853F3C0.EE96FB16@vigrid.com> <19991212124841.B350@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: > > On Sun, Dec 12, 1999 at 02:13:04PM -0500, Daniel M. Eischen wrote: > > Arun Sharma wrote: > > > Other concerns that were expressed - crossing protection boundaries too > > > often to pass messages about blocking and rescheduling. Matt Dillon > > > responded that these messages could be batched and made more efficient. > > > > I agree. It seemed like the SA paper went to extremes in notifying > > the UTS of unblocked threads. I think we can do this at more opportune > > times, like when a Q is resumed or on a user->kernel crossing. I don't > > know that we want to be interrupting a Q while it is running a thread > > just to notify the UTS that another thread has unblocked in the kernel. > > One aspect of the SA paper that we did not strictly adhere to in our design > is the idea that activations always upcall into the UTS. In particular, we > felt that it would work to restore a preempted activation rather than > creating a notification and a new activation. After re-reading the SA > paper (yet again), I'm not sure this saves us much performance-wise, and it > probably reduces flexibility. It is OK to resume a preempted activation only if you have one Q. The thing that makes SA work is that the UTS is informed about preemptions so threads can be resumed long enough to leave critical sections. Otherwise, with multiple Q's a preemption could make them all spin for their entire quantum until the preempted Q was finally resumed. And if you allow Q's to have their own priority, a low-priority Q that was preempted might hold up other Q's from running indefinitely. You _need_ preemption notification or else you have to use kernel level locks. I feel very strongly that we need preemption notification. Once you have the ability to make upcalls, it's no more difficult than any other upcall event. > > Another aspect of the SA paper that we did not adhere to is notification of > preemption. I'm not sure this is a good simplification. Without such > notifications, it is not possible to know what is or isn't running on other > processors, which could make certain scheduling decisions very difficult. > Then again, I don't like the idea of preempting an activation so that a > notification of preemption on another processor can be delivered. I agree. Wait until entering the kernel, or upon resuming from another preemption. 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 Dec 12 13:49: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 7C5DE15052 for ; Sun, 12 Dec 1999 13:49: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 WAA25530 for ; Sun, 12 Dec 1999 22:49:19 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA50954 for freebsd-arch@freebsd.org; Sun, 12 Dec 1999 22:49:19 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 62DB1150C1 for ; Sun, 12 Dec 1999 13:49:09 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt25.pcnet.net [206.105.29.99]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id QAA23771; Sun, 12 Dec 1999 16:49:05 -0500 (EST) Message-ID: <38541839.2C2BDF2F@vigrid.com> Date: Sun, 12 Dec 1999 16:48:41 -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: Arun Sharma , arch@freebsd.org Subject: Re: Recent face to face threads talks. 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: > Yes we agreed that "kernel threads' would hopefully belong to a "Q" that > was hung off proc0 and which would have 'realtime' scheduling > characteristics. This brings up something that was mentionned but that I > dont remember an explicit agreement to, though I think averyone agreed.. > > There is a syscall that jumpstarts the threading support. It supplies the > kernel with the information needed to do upcalls. Until this call is made > there can be no upcalls and the process is effectively unthreaded. This > call is repeated for each 'thread class', and in fact we call it foreach each 'Q'? > CPU as well. each time you call it you define another 'virtual cpu', and > supply it with upcal information. Each virtual CPU has therefore a > different UTS instantiation (read stack) (they can be small). It can > therefore be stated that each "Q" structure effectively corresponds to an > UTS instance. There will probably have to be more than "UTS instantion" (UTS stack). During a preemption notification, the UTS might have to resume a preempted thread before dealing with stuff on the UTS stack. Therefore the kernel doesn't know if the UTS stack is still in use. I think it better to have the UTS provide a set of stacks to use for upcall notifications as described in the SA papers. These can be cached and returned to the kernel in bulk. 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 Dec 12 16:10: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 2675F14DDB for ; Sun, 12 Dec 1999 16:10: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 BAA26528 for ; Mon, 13 Dec 1999 01:10:50 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA51347 for freebsd-arch@freebsd.org; Mon, 13 Dec 1999 01:10:49 +0100 (MET) Received: from mass.cdrom.com (castles552.castles.com [208.214.165.116]) by hub.freebsd.org (Postfix) with ESMTP id 9093014EAC for ; Sun, 12 Dec 1999 16:10:43 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id QAA04310; Sun, 12 Dec 1999 16:13:26 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912130013.QAA04310@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Julian Elischer Cc: arch@freebsd.org Subject: Re: Recent face to face threads talks. In-reply-to: Your message of "Sun, 12 Dec 1999 00:52:30 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 12 Dec 1999 16:13:26 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I think that others are going to cover the technical aspects of this discussion, so I'm going to limit myself to one slightly disappointing observation. During the proceedings, it became very clear that only a small number of attendees have taken the time to perform any substantial research on the topic. None of the ideas being discussed are new; they've all been looked at many, many years ago. If we're going to maintain our reputation for careful implementation of time-tested ideas and techniques, we need to avail ourselves of the work of others, and that means hunting down and reading the large volume of research output on the topic. I know that Terry has a reading list, and I'm sure that others do as well. I think it'd be to our great advantage to have these lists distributed as well as a central repository of papers and references created so that we pull ourselves past the discussing of half-baked ideas and avoid several years worth of wheel reinvention. -- \\ 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 Sun Dec 12 16:43: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 40DEC14E32 for ; Sun, 12 Dec 1999 16:43: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 BAA26715 for ; Mon, 13 Dec 1999 01:43:43 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA51515 for freebsd-arch@freebsd.org; Mon, 13 Dec 1999 01:43:42 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id B5B0014E32; Sun, 12 Dec 1999 16:43:37 -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 QAA93517; Sun, 12 Dec 1999 16:43:37 -0800 (PST) Date: Sun, 12 Dec 1999 16:43:36 -0800 (PST) From: Julian Elischer To: Mike Smith Cc: arch@freebsd.org Subject: Re: Recent face to face threads talks. In-Reply-To: <199912130013.QAA04310@mass.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 Sun, 12 Dec 1999, Mike Smith wrote: > > I think that others are going to cover the technical aspects of this > discussion, so I'm going to limit myself to one slightly disappointing > observation. > > During the proceedings, it became very clear that only a small number of > attendees have taken the time to perform any substantial research on the > topic. None of the ideas being discussed are new; they've all been > looked at many, many years ago. If we're going to maintain our > reputation for careful implementation of time-tested ideas and > techniques, we need to avail ourselves of the work of others, and that > means hunting down and reading the large volume of research output on the > topic. The discussion was not so much a description of all that has been done in the past but a discussion of some of the ideas that we have already narrowed down to given that we want to implement it in something vaguely related to the current system. I think a lot of the discussion was from the perspective of: "What can we implement in arealistic time scale". > > I know that Terry has a reading list, and I'm sure that others do as > well. I think it'd be to our great advantage to have these lists > distributed as well as a central repository of papers and references > created so that we pull ourselves past the discussing of half-baked ideas > and avoid several years worth of wheel reinvention. We've already published a list of threading related papers on this mailing list but I am sure we can do it again. Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 12 17:19: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 2418014DDB for ; Sun, 12 Dec 1999 17:19: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 CAA28538 for ; Mon, 13 Dec 1999 02:19:32 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA51726 for freebsd-arch@freebsd.org; Mon, 13 Dec 1999 02:19:31 +0100 (MET) Received: from rah.star-gate.com (216-200-29-190.snj0.flashcom.net [216.200.29.194]) by hub.freebsd.org (Postfix) with ESMTP id 20EBA14ECA for ; Sun, 12 Dec 1999 17:19:26 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.3/8.9.3) with ESMTP id RAA92493; Sun, 12 Dec 1999 17:18:14 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199912130118.RAA92493@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Julian Elischer Cc: arch@freebsd.org Subject: Re: Recent face to face threads talks. In-reply-to: Your message of "Sun, 12 Dec 1999 16:43:36 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 12 Dec 1999 17:18:14 -0800 From: Amancio Hasty Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > We've already published a list of threading related papers on this mailing > list but I am sure we can do it again. > You need a simple web page to hold all the information about the project. -- Amancio Hasty hasty@rah.star-gate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 12 17:36: 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 CD3DC14D2D for ; Sun, 12 Dec 1999 17:36: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 CAA00308 for ; Mon, 13 Dec 1999 02:36:00 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA51800 for freebsd-arch@freebsd.org; Mon, 13 Dec 1999 02:36:00 +0100 (MET) Received: from mass.cdrom.com (castles516.castles.com [208.214.165.80]) by hub.freebsd.org (Postfix) with ESMTP id 6E6F514D2D; Sun, 12 Dec 1999 17:35:54 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id RAA04644; Sun, 12 Dec 1999 17:38:33 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912130138.RAA04644@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Julian Elischer Cc: Mike Smith , arch@freebsd.org Subject: Re: Recent face to face threads talks. In-reply-to: Your message of "Sun, 12 Dec 1999 16:43:36 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 12 Dec 1999 17:38:33 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > During the proceedings, it became very clear that only a small number of > > attendees have taken the time to perform any substantial research on the > > topic. None of the ideas being discussed are new; they've all been > > looked at many, many years ago. If we're going to maintain our > > reputation for careful implementation of time-tested ideas and > > techniques, we need to avail ourselves of the work of others, and that > > means hunting down and reading the large volume of research output on the > > topic. > > The discussion was not so much a description of all that has been done > in the past but a discussion of some of the ideas that we have already > narrowed down to given that we want to implement it in something vaguely > related to the current system. I think a lot of the discussion was > from the perspective of: "What can we implement in arealistic time > scale". It wasn't so much that; a lot of it was "how about this way" followed by "that's a 12-year-old idea and it doesn't work". That's time wasted that we don't have, hence the comment. > > I know that Terry has a reading list, and I'm sure that others do as > > well. I think it'd be to our great advantage to have these lists > > distributed as well as a central repository of papers and references > > created so that we pull ourselves past the discussing of half-baked ideas > > and avoid several years worth of wheel reinvention. > > We've already published a list of threading related papers on this mailing > list but I am sure we can do it again. Just posting the list isn't enough; we need a central repository that we can post this stuff on. -- \\ 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 Sun Dec 12 20:27: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 A797014ED4 for ; Sun, 12 Dec 1999 20:27: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 FAA02695 for ; Mon, 13 Dec 1999 05:27:38 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA52229 for freebsd-arch@freebsd.org; Mon, 13 Dec 1999 05:27:37 +0100 (MET) Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 7DDEA14E87 for ; Sun, 12 Dec 1999 20:27:28 -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 XAA13769; Sun, 12 Dec 1999 23:25:49 -0500 (EST) (envelope-from chuckr@picnic.mat.net) Date: Sun, 12 Dec 1999 23:25:48 -0500 (EST) From: Chuck Robey To: "Russell L. Carter" Cc: Nate Williams , Arun Sharma , freebsd-arch@freebsd.org Subject: Re: Thread scheduling In-Reply-To: <19991211192742.4C7504A@pinyon.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, 11 Dec 1999, Russell L. Carter wrote: > > %> Not a guarantee, but would it be a good thing to have them > %> "co-scheduled" (or a bias towards that likelihood). > % > %But, I can't see any advantage to have them co-scheduled. > > In the realm of parallel numerical algorithms there are > quite a lot of practical algorithms that require cross > "task" communication and to the extent that the "tasks" > are not executed in roughly synchronous fashion so that > their intricate communication schedules may be carried > out more or less non-blocking then the algorithm > suffers from disastrous multicpu inefficiency. > Typically, these "tasks" share miniscule amounts of data, > but any "waiting" is fatal to scalable throughput. > Hence the development of the "gang scheduling" notion > that Arun referred to. This is most highly refined > and effectively implemented in Cray UNICOS systems. > > But I wouldn't worry about it. It's a small slice of > the whole customer pie, and causes indigestion for > my particular fetish, which is independently > schedulable (ala POSIX) threads capable of > meeting QOS guarantees. :-) OK, thanks, guys. That question's done. I have more, but I need to investigate code now, so as not to waste more time. ---------------------------------------------------------------------------- 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 Sun Dec 12 20:51: 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 AF9DA151A4 for ; Sun, 12 Dec 1999 20:50: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 FAA02828 for ; Mon, 13 Dec 1999 05:50:56 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA52342 for freebsd-arch@freebsd.org; Mon, 13 Dec 1999 05:50:56 +0100 (MET) Received: from mtiwmhc01.worldnet.att.net (mtiwmhc01.worldnet.att.net [204.127.131.36]) by hub.freebsd.org (Postfix) with ESMTP id EBDC414DB4; Sun, 12 Dec 1999 20:50:42 -0800 (PST) (envelope-from Thrumbar@Worldnet.att.net) Received: from 11.neworleans-01-02rs16rt.la.dial-access.att.net ([12.73.238.11]) by mtiwmhc01.worldnet.att.net (InterMail v03.02.07.07 118-134) with SMTP id <19991213045040.GYKN5516@11.neworleans-01-02rs16rt.la.dial-access.att.net>; Mon, 13 Dec 1999 04:50:40 +0000 From: Thrumbar Pathfinder To: freebsd-hackers@freebsd.org Cc: arch@freebsd.org Subject: Developer's Interface Guide for IA-64 Servers (DIG64) Adopter Date: Sun, 12 Dec 1999 22:47:37 -0600 Organization: OmniCorp Interstellar Message-ID: X-Mailer: Forte Agent 1.7/32.534 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Attention, all FreeBSD, OpenBSD and NetBSD developers.. This is a chance we cannot ignore.. Please form up a development team with a central tram leader and get signed up for this offer. The Documentation personnel should sign up for the Contributors link to add BSD's voice in setting the guidelines for future BSD development for all three forms... Please read below.. (also, team leaders, send me a e-mail when you sign-up to keep me informed as to the process and to get an idea on how many teams there is involved) About the DIG64 Leading hardware and software vendors have formed an industry group to develop the DIG64 guidelines. These guidelines establish basic system building blocks, interfaces, and programming conventions for upcoming IA-64 based servers and their system-level software in order to define hardware and software compatibility and interoperability.=20 DIG64 is...=20 an industry-driven set of technical guidelines that define hardware, firmware and operating system's compatibility for IA-64 servers providing IT with systems built on common, stabilized interfaces that improve reliability and interoperability, lower qualification and support costs developed and backed by the key IA-64 OEMs, OSVs, and BIOS vendors who are contributing to its development and are building compliant products allowing the industry to accelerate the pace of IA-64 technology adoption=20 By defining common building blocks and interfaces and proactively addressing legacy issues, the DIG64 provides an array of benefits for both developers and IT organizations.=20 =46or developers, the DIG64: =20 Increases the efficiency of the design process, freeing developers to focus design resources of features that add unique value and differentiate their products in the marketplace. =20 Gives firmware and OS vendors a known set of interfaces to build to, enabling them to confidentially develop their products concurrently with the hardware and shrink time to markets. =20 Provides a technology migration roadmap that extends the planning horizon for developers and allows them to create designs with increased longevity.=20 =46or business users and Information Technology (IT) departments: =20 Standard interfaces and interoperable layers enhance the reliability and robustness of the resulting servers as well as lowering qualification costs. Since developers find it easier to build components that work together, customers can enjoy a greater choice of robust, innovative server solutions. Because the DIG64 addresses the migration of support-intensive, obsolete technologies to newer, more robust choices, IT departments can control or reduce the cost of server support.=20 DIG64 Defined =20 The DIG64 specification defines basic system building blocks, interfaces and programming conventions between IA-64 based servers and system-level software such as the operating system and device drivers. The specification covers:=20 Core system components such as the processor, chipset, memory, I/O bus, and server management hardware.=20 =20 Interfaces to peripheral devices for networking, communications and storage.=20 =20 Low-level firmware interfaces to the operating system for system configuration, boot and runtime services.=20 The guide does not create new standards and interfaces, but selects components and interfaces from already existing technologies. To ensure interoperability, the DIG64 also specifies implementation requirements for each specification or standard.=20 The DIG64 spells out a roadmap for eliminating obsolete technologies. Release 1.0, which is currently available , pertains to servers=20 based on the Intel=AE Itanium=99 processor. Subsequent versions will address future processors as they are developed. A three-level hierarchy of required, recommended and optional features enables vendors to choose how quickly they want to remove older technologies.=20 The DIG64 is operating-system independent, promoting cross-platform interoperability among servers running Windows 2000*, Linux and other UNIX* operating systems.=20 Join Other Industry Leaders Already Building Compatible IA-64 Server Solutions! =20 =20 There is still time to get involved by becoming a DIG64 Adopter member. To find out more about the advantages of becoming a DIG64 Adopter, take look at the DIG64 www site.... http://www.dig64.org/ To sign up as a Developer's Interface Guide for IA-64 Servers (DIG64) Adopter, complete all of the information at the link listed below and hit the submit button. You will then be able to download a "DIG64 Adopters Agreement". http://www.dig64.org/signup.htm By becoming a DIG64 Contributor, you will be able to provide technical input into the development of the DIG64 guidelines in addition to gaining access to the latest published draft. All input will be reviewed by the DIG64 Working Group for possible inclusion in the guideline. http://www.dig64.org/contributor.htm When you have formed your group please e-mail me so that I will know how many groups there are.. Please include a list of the individuals on the team and their position on said team as well as any contact information you are willing to provide... Thrumbar@Worldnet.att.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 13 0:19: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 6250C14D22 for ; Mon, 13 Dec 1999 00:19: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 JAA04502 for ; Mon, 13 Dec 1999 09:19:45 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id JAA53043 for freebsd-arch@freebsd.org; Mon, 13 Dec 1999 09:19:43 +0100 (MET) Received: from knight.cons.org (knight.cons.org [194.233.237.195]) by hub.freebsd.org (Postfix) with ESMTP id 0E67914D22 for ; Mon, 13 Dec 1999 00:19:23 -0800 (PST) (envelope-from cracauer@knight.cons.org) Received: (from cracauer@localhost) by knight.cons.org (8.9.3/8.9.3) id JAA13708 for arch@FreeBSD.ORG; Mon, 13 Dec 1999 09:19:16 +0100 (CET) Date: Mon, 13 Dec 1999 09:19:16 +0100 From: Martin Cracauer To: arch@freebsd.org Subject: Re: Concrete plans for ucontext/mcontext changes around 4.0 Message-ID: <19991213091915.D13197@cons.org> References: <19991212172602.A10611@cons.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <19991212172602.A10611@cons.org>; from Martin Cracauer on Sun, Dec 12, 1999 at 05:26:02PM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG First correction: > - Add one int member to use as 32 bitwise booleans to indicate what > the SSE/additional space is used for in this signal invocation. FPU > state will unconditionally be there. Forgot about lazy FPU context switching (should have finished reading my mailbox). FPU context is not always there. The Linux people claim that lazy FPU switching is not worth the effort anymore on modern machines. I didn't see any proof or numbers. Anyone of you? Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 13 13:41: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 912CF15153 for ; Mon, 13 Dec 1999 13:41: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 WAA15979 for ; Mon, 13 Dec 1999 22:41:49 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA57413 for freebsd-arch@freebsd.org; Mon, 13 Dec 1999 22:41:49 +0100 (MET) Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 1214015153; Mon, 13 Dec 1999 13:41:25 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from tecra.nlsystems.com (tecra.nlsystems.com [10.0.0.5]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id VAA57925; Mon, 13 Dec 1999 21:50:34 GMT (envelope-from dfr@nlsystems.com) Date: Mon, 13 Dec 1999 21:50:34 +0000 (GMT) From: Doug Rabson To: Martin Cracauer Cc: arch@freebsd.org, marcel@freebsd.org, bde@freebsd.org Subject: Re: Concrete plans for ucontext/mcontext changes around 4.0 In-Reply-To: <19991212172602.A10611@cons.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 Sun, 12 Dec 1999, Martin Cracauer wrote: > Here's my summary what to do with signal handler arguments until 4.0: > > 1) Before feature freeze: get the size of ucontext/mcontext into what > we can live with for a longer time (i.e. until 5.0 or serious other > changes). > > - Correct the size of the FPU/FPU-emul reservation so that it is the > size of struct save87 (4 bytes too much at this time). > > - Add space for SSE registers. > > - Add some more space that allows more flexible use of the SSE > register space for other purposes (isn't this pretty equivalent to > the 3dnow registers on AMD, BTW?). This will not be enough space for > a whole new feature. I think that state for 3dnow is overlayed with FPU state in a similar way to MMX. The main problem with SSE is that it is *new* state which must be saved and restored appropriately otherwise applications cannot use the SSE instruction set. -- 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 Mon Dec 13 13:43: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 7C24B14BE9 for ; Mon, 13 Dec 1999 13:43: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 WAA16006 for ; Mon, 13 Dec 1999 22:43:16 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA57438 for freebsd-arch@freebsd.org; Mon, 13 Dec 1999 22:43:16 +0100 (MET) Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 46D0114E97 for ; Mon, 13 Dec 1999 13:43:05 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from tecra.nlsystems.com (tecra.nlsystems.com [10.0.0.5]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id VAA57995; Mon, 13 Dec 1999 21:52:23 GMT (envelope-from dfr@nlsystems.com) Date: Mon, 13 Dec 1999 21:52:23 +0000 (GMT) From: Doug Rabson To: Martin Cracauer Cc: arch@freebsd.org Subject: Re: Concrete plans for ucontext/mcontext changes around 4.0 In-Reply-To: <19991213091915.D13197@cons.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 Mon, 13 Dec 1999, Martin Cracauer wrote: > First correction: > > > - Add one int member to use as 32 bitwise booleans to indicate what > > the SSE/additional space is used for in this signal invocation. FPU > > state will unconditionally be there. > > Forgot about lazy FPU context switching (should have finished reading > my mailbox). FPU context is not always there. > > The Linux people claim that lazy FPU switching is not worth the effort > anymore on modern machines. I didn't see any proof or numbers. Anyone > of you? We currently do lazy fpu switching on alpha but since gcc likes to use FP registers for memory moves even in integer-only programs, I don't think we get much (if any) benefit from it. I haven't attempted to measure the cost/benefit though. -- 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 Mon Dec 13 14:28: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 61E0514F79 for ; Mon, 13 Dec 1999 14:28: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 XAA16481 for ; Mon, 13 Dec 1999 23:28:30 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA57659 for freebsd-arch@freebsd.org; Mon, 13 Dec 1999 23:28:30 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 9086F150BD; Mon, 13 Dec 1999 14:28:16 -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 OAA22842; Mon, 13 Dec 1999 14:28:15 -0800 (PST) Date: Mon, 13 Dec 1999 14:28:14 -0800 (PST) From: Julian Elischer To: Mike Smith Cc: arch@freebsd.org Subject: Threads references. In-Reply-To: <199912130138.RAA04644@mass.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 Here are some of the references that were dug up; CHORUS: ftp://ftp.chorus.fr/pub/chorus-reports/ In particular.. ftp://ftp.chorus.fr/pub/chorus-reports/CS-TR-91-7.ps.Z ftp://ftp.chorus.fr/pub/chorus-reports/CS-TR-89-37.ps.Z MACH: ftp://ftp.cs.cmu.edu/project/mach/doc/published/Rcs.ps ftp://ftp.cs.cmu.edu/project/mach/doc/unpublished/sched.concur.ps ftp://ftp.cs.cmu.edu/project/mach/doc/unpublished/threads.ps ftp://ftp.cs.cmu.edu/project/mach/doc/published/cont_threads.ps ftp://ftp.cs.cmu.edu/project/mach/doc/published/cmultithread.ps DEC: http://www.crl.research.digital.com/publications/techreports/techreports.html http://www.digital.com/info/DTJF03/DTJF03SC.TXT ftp://ftp.crl.research.digital.com/pub/dec/Alpha/alpha-osf1-call-std-v1_3.ps Solaris: http://www.sun.com/smcc/solaris-migration/docs/courses/threadsHTML/contents.html http://suncom.bilkent.edu.tr/workshop/sig/threads/ http://suncom.bilkent.edu.tr/workshop/sig/threads/usenix.html Various: http://www.freebsd.org/~deischen/p95-anderson.pdf http://www.freebsd.org/cgi/getmsg.cgi?fetch=25000+30231+/usr/local/www/db/text/1999/freebsd-current/19990321.freebsd-current http://lt.tar.com/ > > > > > During the proceedings, it became very clear that only a small number of > > > attendees have taken the time to perform any substantial research on the > > > topic. None of the ideas being discussed are new; they've all been > > > looked at many, many years ago. If we're going to maintain our ... > > > > We've already published a list of threading related papers on this mailing > > list but I am sure we can do it again. > I'm going to add a repository for these to my page on freefall. > Just posting the list isn't enough; we need a central repository that we > can post this stuff on. > Julian > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 13 14:51: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 25FEB14C16 for ; Mon, 13 Dec 1999 14:51: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 XAA16735 for ; Mon, 13 Dec 1999 23:51:05 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA57849 for freebsd-arch@freebsd.org; Mon, 13 Dec 1999 23:51:05 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 2D63614E72; Mon, 13 Dec 1999 14:45:42 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id RAA29705; Mon, 13 Dec 1999 17:45:37 -0500 (EST) Date: Mon, 13 Dec 1999 17:45:36 -0500 (EST) From: Daniel Eischen To: Julian Elischer Cc: Mike Smith , arch@freebsd.org Subject: Re: Threads references. 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, 13 Dec 1999, Julian Elischer wrote: > > Here are some of the references that were dug up; [ ... ] > Various: > > http://www.freebsd.org/~deischen/p95-anderson.pdf Moved into http://www.freebsd.org/~deischen/docs/p95-anderson.pdf I also placed a slightly different version of the same paper in: http://www.freebsd.org/~deischen/docs/Scheduler.pdf It has a diagram and example of what happens when threads block and unblock in the kernel, making it a little easier to understand. Dan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 13 15:36: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 DC11315500 for ; Mon, 13 Dec 1999 15:36:21 -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 AAA17377 for ; Tue, 14 Dec 1999 00:36:16 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA58236 for freebsd-arch@freebsd.org; Tue, 14 Dec 1999 00:36:16 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 3D5A4154C6 for ; Mon, 13 Dec 1999 15:09:59 -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 PAA24229 for ; Mon, 13 Dec 1999 15:09:58 -0800 (PST) Date: Mon, 13 Dec 1999 15:09:57 -0800 (PST) From: Julian Elischer To: arch@freebsd.org Subject: Threads links and references. In-Reply-To: <199912130138.RAA04644@mass.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 I have a threads link off http://www.freebsd.org/~julian/ ( http://www.freebsd.org/~julian/threads/ ) which has some of the references and stuff. If anyone wants to send me more links etc. I'll add them in. Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 13 16:17: 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 CCCB414DF6 for ; Mon, 13 Dec 1999 16:17: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 BAA17817 for ; Tue, 14 Dec 1999 01:17:02 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA58567 for freebsd-arch@freebsd.org; Tue, 14 Dec 1999 01:17:02 +0100 (MET) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 2452B14F79 for ; Mon, 13 Dec 1999 16:16:51 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id RAA07065; Mon, 13 Dec 1999 17:15:29 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpdAAAauaWyn; Mon Dec 13 17:15:21 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id RAA26390; Mon, 13 Dec 1999 17:16:12 -0700 (MST) From: Terry Lambert Message-Id: <199912140016.RAA26390@usr08.primenet.com> Subject: Re: Thread scheduling To: adsharma@sharmas.dhs.org (Arun Sharma) Date: Tue, 14 Dec 1999 00:16:12 +0000 (GMT) Cc: chuckr@picnic.mat.net, nate@mt.sri.com, freebsd-arch@freebsd.org In-Reply-To: <19991210201522.A4535@sharmas.dhs.org> from "Arun Sharma" at Dec 10, 99 08:15:22 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 wasn't suggesting a *single* thread across multiple processors (as I > > think Arun asked). Yes, that would be silly. Is what I asked also silly, > > as a scheduling bias, not a guarantee or a requirement? Or would it make > > no real difference? > > This is also called gang scheduling in OS literature. From what I remember, > there are two advantages to this - both of them mainly applicable to > timesharing systems > > - Minimize the average wait time > > This assumes that the related threads compete for some > resources and when thread A releases a resource, it makes > sense to schedule thread B, which was waiting on the > resource to resume immediately, without further delay This is a thread group affinity issue, having to do less with thread relations than it has to do with your scheduler. One of the primary reasons you want to use a user space threads scheduler as part of your architecture, even if you have "pure" kernel threads, like Linux does, is that it allows you to sidestep the affinity question and the starvation and deadly embrace deadlocks that come with trying to put thread group affinity into your kernel scheduler. Solving this in a kernel scheduler is NP-hard. It also allows you to gracefully resolve otherwise obstinate priority inversion issues by doing priority lending in user space, which is the natural place for it, given resource contention is most likely to be inter-thread and intra-process for a threaded application. In order to solve this in the kernel, you'd need signifcant information that wouldn't be available, unless you turned all of your mutex and semaphore operations into system calls (very expensive). > - When your memory cache is warm with the data from the swap > > If your system is swapping under load, it makes sense > to run the threads together to completion, rather than > swapping data in and out repeatedly. The value of doing this is significantly reduced by the L2 cache being shared and much (clock multiples) slower than the L1 cache. > However, such systems are not very common these days. Any performance > engineer will tell you that a system that swaps will not perform. And > no one cares about statistics like average wait time. You can buy a > fast CPU for < $100. Yes, swapping is your biggest cost. I have a friend who refers to swappable main memory as "L3 cache". As a general note on memory, check the specifcations for AltaVista, some time 8-). > So I don't see any particular advantage to doing this on a system which > will most probably be used as a database server or a web server. I don't see any advantage to it at all, unless you were to implement a deadlining scheduler for hard real time, and you knew beforehand that your threads didn't share any resource contention domains. A very tall order. 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 Mon Dec 13 16:33: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 0F06214BC2 for ; Mon, 13 Dec 1999 16:33:49 -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 BAA17956 for ; Tue, 14 Dec 1999 01:33:47 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA58648 for freebsd-arch@freebsd.org; Tue, 14 Dec 1999 01:33:46 +0100 (MET) Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 1EAC7151BE for ; Mon, 13 Dec 1999 16:33:34 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id RAA24422; Mon, 13 Dec 1999 17:33:04 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp05.primenet.com, id smtpdAAAN0ayEV; Mon Dec 13 17:32:52 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id RAA27290; Mon, 13 Dec 1999 17:33:12 -0700 (MST) From: Terry Lambert Message-Id: <199912140033.RAA27290@usr08.primenet.com> Subject: Re: Thread scheduling To: nate@mt.sri.com Date: Tue, 14 Dec 1999 00:33:12 +0000 (GMT) Cc: chuckr@picnic.mat.net, adsharma@sharmas.dhs.org, freebsd-arch@freebsd.org In-Reply-To: <199912110455.VAA24095@mt.sri.com> from "Nate Williams" at Dec 10, 99 09:55:29 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 > > OK, let me state it again. I wasn't asking if it was a good thing to > > share out threads among multiple processors, because the advantages of > > using a multiple CPU system *as* a multiple CPU seem obvious enough not to > > need asking. > > Except that it's possible that you may want to limit multiple-CPU's to > multiple processes for cache reasons. Once could argue that for certain > classes of threaded applications, you'd get a better hit rate by > sticking with a single CPU for *all* of the threads, although this > wouldn't be true for all threaded applications. The MESI cache coherency protocol solves most of this; the reload would only be from L2 to L1 cache (slow enough on most systems, I grant you). I don't really know what cache coherency protocol is used by the 4 CPU Alpha box Mike Smith has. I do know that the dual PPC-603 "BeBox" and several similar boxes didn't have anything like APIC support, and so they removed the L2 cache entirely, and used the cache signalling lines to implement MEI coherency. > It depends on the application. Right. I think, though, for most threaded applications, what you'd really want is negative affinity, where you want your quantum reservations for different threads to be most likely to be on a different CPU. This has two effects: o It allows multiple CPUs to be executing in user space in the same program, simultaneously o With a per CPU scheduler, you get rid of The Big Giant Lock(tm), in favor of a per CPU scheduler lock, that is only held by a different CPU when migrating processes for load balancing reasons. Even so, only the two CPUs involved in the migration get stalled, and, frankly, they most likely do not get stalled at all, so long as you stagger your quantum clock between the CPUs. This assumes that each thread is not pounding heavily on globally shared state with other threads (i.e. each thread has limited locality, and most locality is not in a contention domain). For the rare application that doesn't meet this (most likely, as a result of a bad design; very few problems would require this as part of their soloution), it might make sense to lockstep all, or more likely, just the badly behaved threads, onto the same processor. > > I was asking to see if it would be a good thing to add a > > strong bias to the system, in such a way as to make the co-scheduling of > > threads among the different processors so that all processors that are > > made available to the program's threads are executing in that address > > space as the same moment in time. > > I wouldn't think it would help for cache rate and/or CPU usage, but > that's just a gut feeling and not based on anything else. Each CPU in > an SMP system has it's own cache, so what happens on another CPU > shouldn't effect how the one CPU performs. > > Adding this bias wouldn't help, and may in fact make things worse (see > above). I would go further: I believe that it would make the scheduler significantly more complicated than it has to be, as well as setting The Big Giant Lock(tm) deeper into cement. It would also tend to result in starvation of other processes, unless you delayed scheduling, since accelerating it each time another thread in the process became ready to run would have the effect of double-booking quantum for the process. Finally, it would also tend to leave the processors partially idle (stalled) as a result of voluntary context switches not occurring at exactly the same place in all threads (i.e. a cache miss on a read from disk putting the caller to sleep). > > Not a guarantee, but would it be a good thing to have them > > "co-scheduled" (or a bias towards that likelihood). > > But, I can't see any advantage to have them co-scheduled. Gang scheduling is more appropriate to non-NUMA multiprocessors working on data flow problems. 8-). 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 Mon Dec 13 18:38: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 2559B152D9 for ; Mon, 13 Dec 1999 18:38: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 DAA20382 for ; Tue, 14 Dec 1999 03:38:46 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA59606 for freebsd-arch@freebsd.org; Tue, 14 Dec 1999 03:38:45 +0100 (MET) Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 12E68152D9 for ; Mon, 13 Dec 1999 18:38:24 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id TAA09051; Mon, 13 Dec 1999 19:37:54 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp05.primenet.com, id smtpdAAAZEaGyr; Mon Dec 13 19:37:42 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id TAA01908; Mon, 13 Dec 1999 19:37:47 -0700 (MST) From: Terry Lambert Message-Id: <199912140237.TAA01908@usr08.primenet.com> Subject: Re: Recent face to face threads talks. To: eischen@vigrid.com (Daniel M. Eischen) Date: Tue, 14 Dec 1999 02:37:47 +0000 (GMT) Cc: adsharma@sharmas.dhs.org, arch@freebsd.org In-Reply-To: <3853F3C0.EE96FB16@vigrid.com> from "Daniel M. Eischen" at Dec 12, 99 02:13:04 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 > > > Wouldn't this be akin to what other systems call a kernel thread or LWP? > > > > A kernel thread or a LWP has a 1-to-1 relationship with a kernel stack. > > In our discussion, a KSE has a 1-to-1 relationship with a kernel stack. The > > purpose of the Q structure was to enforce "scheduling classes" - to > > represent a set of threads having the same priority and to ensure > > fairness in the scheduler. > > > > Apart from this distinction, KSE is the closest to a kernel thread/LWP > > and could possibly be used to implement blocking interrupt threads. > > A KSE can't be placed in the run queue (or isn't in our implementation). > A LWP or kernel thread can be. A LWP can have it's own priority. > I'd argue that our Q much closer resembles a LWP than does a KSE. This is probably more detail than is appropriate, since we agreed to defer the seperation of the "Q" until later, but... "Q" is a structure that acts as a scheduler reservation. It's purpose is to create an association between KSE's, a process, and a quantum at a certain priority. It also provides the basis for getting multiple processors into user space at the same time. In a multithreaded process on an SMP machine, where all threads are at the same priority, you will normally have one "Q" per CPU per multithreaded process, unless you have more CPUs than threads, in which case youll have a number equal to the number of threads. A traditional UNIX process is the same as one "Q" and one KSE. The "Q" is the structure against which quantum is accounted, and is the container for the priority of the process. A "Q" is a close approximation of the Solaris "LWP", but it is not the same, and using the same terminology should probably be avoided, since it will be confusing. The difference is that an LWP is a kernel thread in the strictest formal sense, and it is an explicit backing object, and is mapped to one or more user space processes. Solaris as of 2.5 made this mapping less explicit, by allocating another LWP to run the UTS (userspace threads scheduler) when the kernel ran out of LWPs, but there wre more user space threads that were runnable. This extra LWP signalled the UTS, which would then call down to on-demand create more backing LWPs for the runnable user space threads. As an unfortunate historical note, SunOS 4.1.x supported something called "liblwp", which was effectively a wrapper for turning a blocking I/O call into a non-blocking I/O call plus a threads context switch. Sun added aio_read/aio_write/aio_wait/aio_cancel system calls, as well as a helper system call for dealing with the user stack, and which knew about SPARC register windows; the University of Washingtom technical report "User space threads and SPARC Register Windows" (1992) describes the implementation. In terms of the scheduler, "Q"s go onto run queues, while KSEs go onto sleep queues. KSEs have become what I would call an async system call blocking call context, or "blocking call context" -- BCC, for short. They are intended to be allocated out of a pool, or preferrably, out of a per CPU resource pool, so as to avoid requiring The Big Giant Lock(tm), except when draining or refilling the pool at the high water mark or low water mark on the pool, respectively (this is precisely what Dynix did to achive much higher granularity, at the cost of maintaining a two-layer malloc() system, with the possibility of some memory being "lost" to the non-empty pools; it is a brilliant design, IMO). KSEs are container objects for sleeping on their addresses and for the kernel stack per outstanding blocked system call. The stack _may_ be given back prior to the KSE itself becoming unreferenced. A KSE must also have queue pointers for putting it on the sleep queues, and for maintaining a linked list in the pools. Editorial note: A "Q" is what I would have called the KSE. A kernel schedulable entity implies an interaction with the scheduler, but we are probably going to get stuck with the current definitions. If so, I suggest the term SR for "Scheduler Reservation" is a better fit. In terms of the scheduler (also deferred work), the main idea is to have a per-CPU scheduler that grabs a per-CPU scheduler lock each time it wants to manipulate the data. When migrating "Q"s between CPUs, the CPU migrating will have to grab both its own scheduler lock ("migrate from") and the target CPUs scheduler lock ("migrate to"). Common use would be grabbing its own lock, not in the same contention domain as the other CPUs, so there would be no stalling, as there is with The Big Giant Lock(tm). Like the per processor KSE pools, this enables great concurrency: a migration of a "Q" from one CPU to another on an 8 CPU system will utilize 1 CPU, potentially stalling another CPU, and leaving 6 CPUs unimpacted. There are only three cases where a "Q" is created: o On fork(2) (obviously). o When asking to be scheduled on additional CPUs in an SMP system. It is likely that this particular case will not require priviledges, or that soft limits requring priviledges to violate will be implemented (e.g. an administrative limit of reservations on 4 CPUs in a 16 CPU system, controlled by the users login class). o When asking for an additional "Q" in order to effect sheduling priorities of PTHREAD_SCOPE_SYSTEM. It is likely that dropping priority will be unpriviledged, and merely result in a UTS designation change, since creating an additional "Q" would permit the process to compete as multiple processes against other processes for quantum (in other words, it would pretend to run the affected threads at a lower system priority, but in reality, would not). Raising priority is already a priviledged instruction; it is assumed that raising priority, by virtue of the fact that it requires priviledge, will in fact create another "Q". To be able to effectively manage multiple priority scheduler reservations, except in the face of priority lending to deal with inversion, there is a new requirement for an explicit yield(2) call to give unused higher priority quantum back to the system. Because CPU migration is an exceptional event for a process, and is a matter of kernel scheduler policy, there is natural CPU affinity for each "Q" in this approach. This is many times better than the current situation in both FreeBSD and Linux, as I think some experiments by Mike Smith would support. As a simple algorithm for achieving initial balancing, adding: u_int32_t p_cpumask; /* CPUs with scheduler reservations*/ u_int32_t p_Q_count; /* number of "Q"s in process*/ To the proc structure, and then setting a bit for each CPU that there is currently a "Q" outstanding on (and moving the bit if it gets migrated) will ensure that each new "Q" can be created on a different CPU. Counting the bits and keeping a running "Q" count is a cheap way of knowing if multiple "Q"s are on the same CPU as a result of migration; you would need to traverse the list in order to identify and move these around between CPUs, assuming a load balancing vs. concurrency algorithm in the kernel scheduler. > > It was also agreed that it doesn't make sense to do everything at once, > > but do it in some sensible order, without precluding elements of the > > design. Some of the tasks - break the proc structure into a proc and KSE, > > per CPU scheduling queues, implementing SA. My own take on this was that implementing the scheduler changes would be a heck of a lot easier than the other work. 8-). On the other hand, the general consensus was that it would be easier to do the other work than the scheduler changes, so the scheduler changes are going to need to wait. > > My personal opinion is that it might be easier to go in steps - > > rfork/clone based implementation (aka linuxthreads), then a > > Solaris like m x n implementation and then scheduler activations. > > Implementation wise, they're in the increasing order of difficulty. > > From what I heard from Terry, this is also the path that Solaris > > took. This also lets application writers pick the right model for > > their work. > > I dunno. It seems easier to me to implement SA from the start, > concentrating on eliminating much of the extraneous code in libc_r. > I'd start with making it only work for one process or Q. The > userland part of this seems really easy to me. Once that works, > I'd add the ability to have multiple Q's. This is what looked right to me, and I think that Jason Evans agreed. The intent was to not break out "Q" until later, as part of the scheduler work. For one thing, we already have the Linux threads implemented (it can be loaded as a kernel module). For another, kernel threads backing user space threads is a horrible implementation, and has all sorts of problems with thread group (process) affinity when deciding who to run next on a partially consumed quantum. Adding thread group affinity to a kernel scheduler is a sure way to shoot your leg off. I think that this is at least natural, if not the order I would choose. Much of the hardest work is allowing the process to be on a multiple run queues (or the same run queue, multiple times). This work could even be debugged on a UP machine, where you stuff the same process into a single scheduler several times (indeed, this is necessary for PTHREAD_SCOPE_SYSTEM thread priorities on a uniprocessor machine). This seems to me to most resemble the shared library issues, where it's better to do it right the first time than it is to take a bogus implementation (e.g. the System V shared library style implementation, which ate a chunk of address space for each version of a single library, and the same for each library, as they had to be non-PIC code mapped to the same location in all processes). Waiting on Jeffrey Hsu's patches for PIC in GCC (actually, released in support of LKMs, which needed PIC) was The Right Thing To Do(tm). > > If we stick to the POSIX threads interface strictly, we shouldn't be > > afraid of getting stuck with one of the implementations. > > > > Other concerns that were expressed - crossing protection boundaries too > > often to pass messages about blocking and rescheduling. Matt Dillon > > responded that these messages could be batched and made more efficient. > > I agree. It seemed like the SA paper went to extremes in notifying > the UTS of unblocked threads. I think we can do this at more opportune > times, like when a Q is resumed or on a user->kernel crossing. I don't > know that we want to be interrupting a Q while it is running a thread > just to notify the UTS that another thread has unblocked in the kernel. Julian had a nice discussion with Jason (and later Matt and me) on this topic. The basic idea was to run the threads up to the user/kernel boundary, but not farther. At that time, the call has effectively returned all but the CPU on which it is running to user space, and a nice optimization is that the kernel stack associated with the KSE can be released. This would allow hundreds of thousands of the things, a possibility on a heavily loaded system. Matt suggested a shared memory segment, rather than a message, where the status could be reflected to user space. This strikes me as perhaps premature optimization, but would give us a place to put information about the "Q" of a process returning to user space, which is something that the UTS needs in order to allow it to seperate quanta of different priority for assignment to a new user space thread (or an explicit yield(2), if the high priority threads are all blocked -- though a priority lend to the lower priority thread holding the resource would probably be a better idea, it will require additional work in user space to implement). 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 Mon Dec 13 19:45: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 9B88515247 for ; Mon, 13 Dec 1999 19:45: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 EAA20871 for ; Tue, 14 Dec 1999 04:45:23 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA59969 for freebsd-arch@freebsd.org; Tue, 14 Dec 1999 04:45:23 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 13276154AE for ; Mon, 13 Dec 1999 19:44:03 -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 TAA31386; Mon, 13 Dec 1999 19:43:51 -0800 (PST) Date: Mon, 13 Dec 1999 19:43:50 -0800 (PST) From: Julian Elischer To: Terry Lambert Cc: "Daniel M. Eischen" , adsharma@sharmas.dhs.org, arch@freebsd.org Subject: Re: Recent face to face threads talks. In-Reply-To: <199912140237.TAA01908@usr08.primenet.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 Today archie and I tried to "mentally implement" this system. The basic architecture remains the same but we ended up having to make one glaring change. (seen below). On Tue, 14 Dec 1999, Terry Lambert wrote: [stuff deleted] > > KSEs have become what I would call an async system call blocking > call context, or "blocking call context" -- BCC, for short. > They are intended to be allocated out of a pool, or preferrably, > out of a per CPU resource pool, so as to avoid requiring The Big > Giant Lock(tm), except when draining or refilling the pool at the > high water mark or low water mark on the pool, respectively (this > is precisely what Dynix did to achive much higher granularity, > at the cost of maintaining a two-layer malloc() system, with the > possibility of some memory being "lost" to the non-empty pools; > it is a brilliant design, IMO). > > KSEs are container objects for sleeping on their addresses and > for the kernel stack per outstanding blocked system call. The > stack _may_ be given back prior to the KSE itself becoming > unreferenced. A KSE must also have queue pointers for putting > it on the sleep queues, and for maintaining a linked list in > the pools. > > Editorial note: A "Q" is what I would have called the KSE. A > kernel schedulable entity implies an interaction > with the scheduler, but we are probably going to > get stuck with the current definitions. If so, > I suggest the term SR for "Scheduler Reservation" > is a better fit. > Yes, maybe we should rename KSE's to be "kernel Sleepable object" ;-) Archie and I have spent about 4 hours today arguing about some of this an dwe have come up with a proposal that we will put forward in the next day when we get it all written down. I hate to say it but we decided we may actually need an "R" stucture as well in some cases. Renemaing the KSE to "S" gives us a royal flush ("Proc", "Queue/Quantum", "Runnable" and "Sleepable", P,Q,R,S (ok I'm pushing it a bit) the structures are as follows: 1) Proc.. holds VM references and Credentials 2) Thread Class.. Holds the priority information for a group of kernel threads. 3) Thread CPU designator. This has a 1:1 mapping with an upcall handler. All KSE's attached to a particular one of these will come back to the same UTS stack. 4) Thread kernel context container (ex-KSE).. Terry's BCC. A new name is becoming needed. Both the middle structures may not be implemented immediatly. Now, "Why do I want yet another stucture?" I hear you ask! It allows us to handle some intersting concurrancy issues, while still allowing us to be sure that a particular upcall handler is inherrantly safe from being clobbered by upcalls from multiple CPUs at the same time. It also gives a natural target for gang scheduling (should it be required) and thread migration. We are writing a set of man pages for discussion purposes. with this particular structure layout the code almost writes itself which is always a pleasing feeling. Structure (3) is the one that goes on the run queues. Structure (4) is the one that goes on the sleep queues The UTS implicitly groups "type-3's" into a group described by a "type (2)". (runnable type 4's in the kernel may switch between any type (3) structs in the same group, in order to get the maximum concurrancy needed. A proces that cannot handle this would only ever place one type (3) in a type (2), in fact this would be the default behaviour, and for early implementations, the only possible model. > > In terms of the scheduler (also deferred work), the main idea > is to have a per-CPU scheduler that grabs a per-CPU scheduler > lock each time it wants to manipulate the data. > > When migrating "Q"s between CPUs, the CPU migrating will have > to grab both its own scheduler lock ("migrate from") and the > target CPUs scheduler lock ("migrate to"). > > Common use would be grabbing its own lock, not in the same > contention domain as the other CPUs, so there would be no > stalling, as there is with The Big Giant Lock(tm). The type (3) structs are Per-cpu and are on different cpu sched lists. the type(4) structs can migrate between any type (3)s that are in the same type (2) :-) > > Like the per processor KSE pools, this enables great concurrency: > a migration of a "Q" from one CPU to another on an 8 CPU system > will utilize 1 CPU, potentially stalling another CPU, and > leaving 6 CPUs unimpacted. > > > > There are only three cases where a "Q" is created: > > o On fork(2) (obviously). > > o When asking to be scheduled on additional CPUs in an > SMP system. It is likely that this particular case > will not require priviledges, or that soft limits > requring priviledges to violate will be implemented > (e.g. an administrative limit of reservations on 4 > CPUs in a 16 CPU system, controlled by the users > login class). In the system Archie and I have drawn up a "Q" is broken into two parts this is the 'type (3)'. The one below is a 'type (2)'. > > o When asking for an additional "Q" in order to effect > sheduling priorities of PTHREAD_SCOPE_SYSTEM. It is > likely that dropping priority will be unpriviledged, > and merely result in a UTS designation change, since > creating an additional "Q" would permit the process > to compete as multiple processes against other processes > for quantum (in other words, it would pretend to run the > affected threads at a lower system priority, but in > reality, would not). Raising priority is already a > priviledged instruction; it is assumed that raising > priority, by virtue of the fact that it requires > priviledge, will in fact create another "Q". To be > able to effectively manage multiple priority scheduler > reservations, except in the face of priority lending > to deal with inversion, there is a new requirement for > an explicit yield(2) call to give unused higher priority > quantum back to the system. yes we definity need a 'yield'.. A 'sleep' that just destroys the kse and doesn't return. (kinda). > > Because CPU migration is an exceptional event for a process, and > is a matter of kernel scheduler policy, there is natural CPU > affinity for each "Q" in this approach. This is many times > better than the current situation in both FreeBSD and Linux, > as I think some experiments by Mike Smith would support. > > As a simple algorithm for achieving initial balancing, adding: > > u_int32_t p_cpumask; /* CPUs with scheduler reservations*/ > u_int32_t p_Q_count; /* number of "Q"s in process*/ > > To the proc structure, and then setting a bit for each CPU that > there is currently a "Q" outstanding on (and moving the bit if > it gets migrated) will ensure that each new "Q" can be created > on a different CPU. Counting the bits and keeping a running "Q" > count is a cheap way of knowing if multiple "Q"s are on the same > CPU as a result of migration; you would need to traverse the list > in order to identify and move these around between CPUs, assuming > a load balancing vs. concurrency algorithm in the kernel scheduler. you can however find that your threads on one processor are trapped behind a constantly higher priority process, and need to get 'rescued' by being brought out to another processor in order to let them get out from under it. > > > > > It was also agreed that it doesn't make sense to do everything at once, > > > but do it in some sensible order, without precluding elements of the > > > design. Some of the tasks - break the proc structure into a proc and KSE, > > > per CPU scheduling queues, implementing SA. > > My own take on this was that implementing the scheduler changes > would be a heck of a lot easier than the other work. 8-). On > the other hand, the general consensus was that it would be easier > to do the other work than the scheduler changes, so the scheduler > changes are going to need to wait. > [whether to do a linuxthreads-type version first or not] > > This is what looked right to me, and I think that Jason Evans > agreed. The intent was to not break out "Q" until later, as > part of the scheduler work. > > For one thing, we already have the Linux threads implemented > (it can be loaded as a kernel module). For another, kernel > threads backing user space threads is a horrible implementation, > and has all sorts of problems with thread group (process) affinity > when deciding who to run next on a partially consumed quantum. > Adding thread group affinity to a kernel scheduler is a sure way > to shoot your leg off. Actually the linuxthreads PORT (as opposed the running a linux treads linux program under linux mode) requires NO kernel changes, as it's a Native freeBSD binary library. > > I think that this is at least natural, if not the order I would > choose. Much of the hardest work is allowing the process to be > on a multiple run queues (or the same run queue, multiple times). > This work could even be debugged on a UP machine, where you > stuff the same process into a single scheduler several times > (indeed, this is necessary for PTHREAD_SCOPE_SYSTEM thread > priorities on a uniprocessor machine). > > This seems to me to most resemble the shared library issues, > where it's better to do it right the first time than it is to > take a bogus implementation (e.g. the System V shared library > style implementation, which ate a chunk of address space for > each version of a single library, and the same for each library, > as they had to be non-PIC code mapped to the same location in > all processes). Waiting on Jeffrey Hsu's patches for PIC in > GCC (actually, released in support of LKMs, which needed PIC) > was The Right Thing To Do(tm). > > > > > If we stick to the POSIX threads interface strictly, we shouldn't be > > > afraid of getting stuck with one of the implementations. > > > > > > Other concerns that were expressed - crossing protection boundaries too > > > often to pass messages about blocking and rescheduling. Matt Dillon > > > responded that these messages could be batched and made more efficient. > > > > I agree. It seemed like the SA paper went to extremes in notifying > > the UTS of unblocked threads. I think we can do this at more opportune > > times, like when a Q is resumed or on a user->kernel crossing. I don't > > know that we want to be interrupting a Q while it is running a thread > > just to notify the UTS that another thread has unblocked in the kernel. > > Julian had a nice discussion with Jason (and later Matt and me) on > this topic. The basic idea was to run the threads up to the user/kernel > boundary, but not farther. At that time, the call has effectively > returned all but the CPU on which it is running to user space, and > a nice optimization is that the kernel stack associated with the KSE > can be released. This would allow hundreds of thousands of the > things, a possibility on a heavily loaded system. > > Matt suggested a shared memory segment, rather than a message, > where the status could be reflected to user space. This strikes > me as perhaps premature optimization, but would give us a place > to put information about the "Q" of a process returning to user > space, which is something that the UTS needs in order to allow > it to seperate quanta of different priority for assignment to a > new user space thread (or an explicit yield(2), if the high priority > threads are all blocked -- though a priority lend to the lower > priority thread holding the resource would probably be a better > idea, it will require additional work in user space to implement). Archie and I have in our mental implementation, made the call that greates a new 'Q' (actually a type(3)) supply as arguments, the place where the kernel can find a pointer to the register storage for the thread being run, and a place to find a pointer for where to find a cookie for the thread. Given these two bits of information (permanently stored in the 'type(3)') the kernel and the UTS can communicate in an unambiguous manner. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 13 20: 0: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 7F11B14E43 for ; Mon, 13 Dec 1999 20:00:03 -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 EAA21356 for ; Tue, 14 Dec 1999 04:59:59 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA60189 for freebsd-arch@freebsd.org; Tue, 14 Dec 1999 04:59:59 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id C10D11553A for ; Mon, 13 Dec 1999 19:59:41 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt1.pcnet.net [206.105.29.75]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id WAA07889; Mon, 13 Dec 1999 22:59:35 -0500 (EST) Message-ID: <3855C05C.A59F6B47@vigrid.com> Date: Mon, 13 Dec 1999 22:58:20 -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: Terry Lambert Cc: adsharma@sharmas.dhs.org, arch@freebsd.org Subject: Re: Recent face to face threads talks. References: <199912140237.TAA01908@usr08.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > As an unfortunate historical note, SunOS 4.1.x supported something > called "liblwp", which was effectively a wrapper for turning a > blocking I/O call into a non-blocking I/O call plus a threads > context switch. Sun added aio_read/aio_write/aio_wait/aio_cancel > system calls, as well as a helper system call for dealing with > the user stack, and which knew about SPARC register windows; the > University of Washingtom technical report "User space threads and > SPARC Register Windows" (1992) describes the implementation. Since you mentioned aio_read/aio_write... Should these targets for a rewrite once our P's and Q's are in place ;-) I guess it'd even be possible to pull them out of the kernel and place them in libc, though I don't know that we'd want to. > > I dunno. It seems easier to me to implement SA from the start, > > concentrating on eliminating much of the extraneous code in libc_r. > > I'd start with making it only work for one process or Q. The > > userland part of this seems really easy to me. Once that works, > > I'd add the ability to have multiple Q's. > > This is what looked right to me, and I think that Jason Evans > agreed. The intent was to not break out "Q" until later, as > part of the scheduler work. Terry, I'm surprised. We actually agree :-) > For one thing, we already have the Linux threads implemented > (it can be loaded as a kernel module). For another, kernel > threads backing user space threads is a horrible implementation, > and has all sorts of problems with thread group (process) affinity > when deciding who to run next on a partially consumed quantum. > Adding thread group affinity to a kernel scheduler is a sure way > to shoot your leg off. > > I think that this is at least natural, if not the order I would > choose. Much of the hardest work is allowing the process to be > on a multiple run queues (or the same run queue, multiple times). > This work could even be debugged on a UP machine, where you > stuff the same process into a single scheduler several times > (indeed, this is necessary for PTHREAD_SCOPE_SYSTEM thread > priorities on a uniprocessor machine). > > This seems to me to most resemble the shared library issues, > where it's better to do it right the first time than it is to > take a bogus implementation (e.g. the System V shared library > style implementation, which ate a chunk of address space for > each version of a single library, and the same for each library, > as they had to be non-PIC code mapped to the same location in > all processes). Waiting on Jeffrey Hsu's patches for PIC in > GCC (actually, released in support of LKMs, which needed PIC) > was The Right Thing To Do(tm). > > > > If we stick to the POSIX threads interface strictly, we shouldn't be > > > afraid of getting stuck with one of the implementations. > > > > > > Other concerns that were expressed - crossing protection boundaries too > > > often to pass messages about blocking and rescheduling. Matt Dillon > > > responded that these messages could be batched and made more efficient. > > > > I agree. It seemed like the SA paper went to extremes in notifying > > the UTS of unblocked threads. I think we can do this at more opportune > > times, like when a Q is resumed or on a user->kernel crossing. I don't > > know that we want to be interrupting a Q while it is running a thread > > just to notify the UTS that another thread has unblocked in the kernel. > > Julian had a nice discussion with Jason (and later Matt and me) on > this topic. The basic idea was to run the threads up to the user/kernel > boundary, but not farther. At that time, the call has effectively > returned all but the CPU on which it is running to user space, and > a nice optimization is that the kernel stack associated with the KSE > can be released. This would allow hundreds of thousands of the > things, a possibility on a heavily loaded system. Actually, after re-reading the SA paper, this is what it suggests. Unblocked threads are temporarily resumed to the point that they either block again in the kernel or reach the point where they would leave the kernel. 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 Mon Dec 13 21: 3: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 BFDA914BCF for ; Mon, 13 Dec 1999 21:03: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 GAA22454 for ; Tue, 14 Dec 1999 06:03:38 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA60696 for freebsd-arch@freebsd.org; Tue, 14 Dec 1999 06:03:37 +0100 (MET) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id DA51B14BD2 for ; Mon, 13 Dec 1999 21:03:29 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id WAA70522 for ; Mon, 13 Dec 1999 22:03:28 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id WAA49761 for ; Mon, 13 Dec 1999 22:03:28 -0700 (MST) Message-Id: <199912140503.WAA49761@harmony.village.org> To: freebsd-arch@freebsd.org Subject: The if_detach problem Date: Mon, 13 Dec 1999 22:03:28 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG if_detach doesn't, at least not completely. That's a problem when you want to remove interfaces. One problem is that the routing system caches ifaddr and other things. There is a mechanism in place that could be used to clean things up. In the protosw there is a ctlinput routine which accepts various commands. One way to deal with this is to send a new command when ifa goes away. Right now when we do if_down we send a PRC_IFDOWN. Maybe we need to invent a new PRC_, say PRC_IFDETACH. Then we wouldn't need the kludges in if_detach. The ctlinput routines could then, in the appropriate places, scrub the references to the interface that just went away. I'd like to go down this path, any comments? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 13 23:15: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 5899C151EF for ; Mon, 13 Dec 1999 23:15: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 IAA23562 for ; Tue, 14 Dec 1999 08:15:09 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA61268 for freebsd-arch@freebsd.org; Tue, 14 Dec 1999 08:15:08 +0100 (MET) Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 5E781157E6 for ; Mon, 13 Dec 1999 23:14:14 -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 #3) id 11xmA0-0003ef-00; Tue, 14 Dec 1999 00:14:13 -0700 Message-ID: <3855EE83.5F0823F9@softweyr.com> Date: Tue, 14 Dec 1999 00:15:15 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Warner Losh Cc: freebsd-arch@freebsd.org Subject: Re: The if_detach problem References: <199912140503.WAA49761@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > > if_detach doesn't, at least not completely. > > That's a problem when you want to remove interfaces. One problem is > that the routing system caches ifaddr and other things. There is a > mechanism in place that could be used to clean things up. > > In the protosw there is a ctlinput routine which accepts various > commands. One way to deal with this is to send a new command when ifa > goes away. Right now when we do if_down we send a PRC_IFDOWN. Maybe > we need to invent a new PRC_, say PRC_IFDETACH. Then we wouldn't need > the kludges in if_detach. The ctlinput routines could then, in the > appropriate places, scrub the references to the interface that just > went away. > > I'd like to go down this path, any comments? Been there, done that in the VxWorks stack. You're heading in the right direction. Be sure to grep for dangling ifnet pointers and such while you're at it; you find those in some of the oddest places. It's nice to see that the ip_slowtimo() bug got fixed somewhere along the way. The 4.2 routine did not splnet() so you could crash the system by deleting an interface just as the system was walking the list of interfaces. You'd think the chances of this happening would be miniscule, but we were getting 2 or 3 crashes per year (across our entire customer base) from this stupid problem. -- "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 Tue Dec 14 4: 3: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 403EE14EC0 for ; Tue, 14 Dec 1999 04:03: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 NAA28626 for ; Tue, 14 Dec 1999 13:03:22 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA62236 for freebsd-arch@freebsd.org; Tue, 14 Dec 1999 13:03:17 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 5A1F214CDE for ; Tue, 14 Dec 1999 04:02:05 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt14.pcnet.net [206.105.29.88]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id HAA28671; Tue, 14 Dec 1999 07:01:06 -0500 (EST) Message-ID: <38563121.C6F15E5D@vigrid.com> Date: Tue, 14 Dec 1999 06:59: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: Terry Lambert Cc: adsharma@sharmas.dhs.org, arch@freebsd.org Subject: Re: Recent face to face threads talks. References: <199912140237.TAA01908@usr08.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > Editorial note: A "Q" is what I would have called the KSE. A > kernel schedulable entity implies an interaction > with the scheduler, but we are probably going to > get stuck with the current definitions. If so, > I suggest the term SR for "Scheduler Reservation" > is a better fit. I agree also. I thought what we call a KSE should be called a kernel context. > There are only three cases where a "Q" is created: > > o On fork(2) (obviously). > > o When asking to be scheduled on additional CPUs in an > SMP system. It is likely that this particular case > will not require priviledges, or that soft limits > requring priviledges to violate will be implemented > (e.g. an administrative limit of reservations on 4 > CPUs in a 16 CPU system, controlled by the users > login class). > > o When asking for an additional "Q" in order to effect > sheduling priorities of PTHREAD_SCOPE_SYSTEM. It is > likely that dropping priority will be unpriviledged, > and merely result in a UTS designation change, since > creating an additional "Q" would permit the process > to compete as multiple processes against other processes > for quantum (in other words, it would pretend to run the > affected threads at a lower system priority, but in > reality, would not). I agree with everything except I don't think that: > Raising priority is already a > priviledged instruction; it is assumed that raising > priority, by virtue of the fact that it requires > priviledge, will in fact create another "Q". we want to create another Q when the process (Q) priority is changed (raised). An application will create a PTHREAD_SCOPE_SYSTEM thread in an attempt to get another Q, but later (in the created thread) raise the process priority (which will then raise the Q priority). Another Q shouldn't be created when the priority is raised. 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 Dec 14 13:48: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 11E9814E6C for ; Tue, 14 Dec 1999 13:48: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 WAA08894 for ; Tue, 14 Dec 1999 22:48:10 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA66184 for freebsd-arch@freebsd.org; Tue, 14 Dec 1999 22:48:09 +0100 (MET) Received: from awfulhak.org (dynamic-27.max4-du-ws.dialnetwork.pavilion.co.uk [212.74.9.155]) by hub.freebsd.org (Postfix) with ESMTP id 1BBA614CB9 for ; Tue, 14 Dec 1999 13:47:17 -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 VAA30939; Tue, 14 Dec 1999 21:44:06 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 VAA34161; Tue, 14 Dec 1999 21:45:36 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <199912142145.VAA34161@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.0 09/18/1999 To: Warner Losh Cc: freebsd-arch@freebsd.org, brian@hak.lan.Awfulhak.org Subject: Re: The if_detach problem In-Reply-To: Message from Warner Losh of "Mon, 13 Dec 1999 22:03:28 MST." <199912140503.WAA49761@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Dec 1999 21:45:36 +0000 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > if_detach doesn't, at least not completely. > > That's a problem when you want to remove interfaces. One problem is > that the routing system caches ifaddr and other things. There is a > mechanism in place that could be used to clean things up. > > In the protosw there is a ctlinput routine which accepts various > commands. One way to deal with this is to send a new command when ifa > goes away. Right now when we do if_down we send a PRC_IFDOWN. Maybe > we need to invent a new PRC_, say PRC_IFDETACH. Then we wouldn't need > the kludges in if_detach. The ctlinput routines could then, in the > appropriate places, scrub the references to the interface that just > went away. > > I'd like to go down this path, any comments? Not comments, but my thoughts.... Is there a lot to be gained by removing interfaces ? I would think that losing an interface would mean the existence of an interface number with no interface (this may break code that caches interface number-to-name information (ppp(8)... I thought about this when I wrote the code, but I've never tested it)). I would also think that adding another interface would get the deallocated interface number again.... this'll kill any program that thinks it can cache this sort of info (ppp(8)). I guess ppp could be changed to not cache this sort of stuff.... > Warner -- 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 Tue Dec 14 14: 6: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 ADA7E14A03 for ; Tue, 14 Dec 1999 14:06: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 XAA09103 for ; Tue, 14 Dec 1999 23:06:46 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA66270 for freebsd-arch@freebsd.org; Tue, 14 Dec 1999 23:06:46 +0100 (MET) Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id 9BA6215409 for ; Tue, 14 Dec 1999 14:05:00 -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 QAA22839; Tue, 14 Dec 1999 16:04:55 -0600 (CST) Received: (from jlemon@localhost) by right.PCS (8.8.5/8.6.4) id QAA25190; Tue, 14 Dec 1999 16:04:54 -0600 (CST) Message-ID: <19991214160454.26093@right.PCS> Date: Tue, 14 Dec 1999 16:04:54 -0600 From: Jonathan Lemon To: Brian Somers Cc: Warner Losh , freebsd-arch@freebsd.org, brian@hak.lan.Awfulhak.org Subject: Re: The if_detach problem References: <199912142145.VAA34161@hak.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: <199912142145.VAA34161@hak.lan.Awfulhak.org>; from Brian Somers on Dec 12, 1999 at 09:45:36PM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Dec 12, 1999 at 09:45:36PM +0000, Brian Somers wrote: > > > > if_detach doesn't, at least not completely. > > > > That's a problem when you want to remove interfaces. One problem is > > that the routing system caches ifaddr and other things. There is a > > mechanism in place that could be used to clean things up. > > > > In the protosw there is a ctlinput routine which accepts various > > commands. One way to deal with this is to send a new command when ifa > > goes away. Right now when we do if_down we send a PRC_IFDOWN. Maybe > > we need to invent a new PRC_, say PRC_IFDETACH. Then we wouldn't need > > the kludges in if_detach. The ctlinput routines could then, in the > > appropriate places, scrub the references to the interface that just > > went away. > > > > I'd like to go down this path, any comments? > > Not comments, but my thoughts.... > > Is there a lot to be gained by removing interfaces ? Loadable device drivers. I ran into this last week or so when unloading a driver I'm developing; if I don't do an 'ifconfig xxx delete' before the kldunoad, I get a panic. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 14 14:10: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 872A91512B for ; Tue, 14 Dec 1999 14:10: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 XAA09184 for ; Tue, 14 Dec 1999 23:10:41 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA66334 for freebsd-arch@freebsd.org; Tue, 14 Dec 1999 23:10:41 +0100 (MET) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 13174150B9 for ; Tue, 14 Dec 1999 14:10:21 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id PAA73357; Tue, 14 Dec 1999 15:10:14 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id PAA55577; Tue, 14 Dec 1999 15:10:13 -0700 (MST) Message-Id: <199912142210.PAA55577@harmony.village.org> To: Jonathan Lemon Subject: Re: The if_detach problem Cc: Brian Somers , freebsd-arch@freebsd.org, brian@hak.lan.Awfulhak.org In-reply-to: Your message of "Tue, 14 Dec 1999 16:04:54 CST." <19991214160454.26093@right.PCS> References: <19991214160454.26093@right.PCS> <199912142145.VAA34161@hak.lan.Awfulhak.org> Date: Tue, 14 Dec 1999 15:10:13 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19991214160454.26093@right.PCS> Jonathan Lemon writes: : Loadable device drivers. I ran into this last week or so when : unloading a driver I'm developing; if I don't do an 'ifconfig xxx delete' : before the kldunoad, I get a panic. That's basically what I want to do in the kernel when a driver calls if_detach(). Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 14 14:32: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 5213915327 for ; Tue, 14 Dec 1999 14:32: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 XAA09326 for ; Tue, 14 Dec 1999 23:32:21 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA66420 for freebsd-arch@freebsd.org; Tue, 14 Dec 1999 23:32:21 +0100 (MET) Received: from marcos.networkcs.com (marcos.networkcs.com [137.66.16.1]) by hub.freebsd.org (Postfix) with ESMTP id 4F37A152E5 for ; Tue, 14 Dec 1999 14:32:12 -0800 (PST) (envelope-from mks@us.networkcs.com) Received: from us.networkcs.com (us.networkcs.com [137.66.11.15]) by marcos.networkcs.com (8.9.3/8.9.3) with ESMTP id QAA87928; Tue, 14 Dec 1999 16:32:05 -0600 (CST) (envelope-from mks@us.networkcs.com) Received: (from mks@localhost) by us.networkcs.com (8.9.2/8.8.7) id QAA19128; Tue, 14 Dec 1999 16:32:04 -0600 (CST) From: Mike Spengler Message-Id: <199912142232.QAA19128@us.networkcs.com> Subject: Re: The if_detach problem In-Reply-To: <199912142210.PAA55577@harmony.village.org> from Warner Losh at "Dec 14, 99 03:10:13 pm" To: imp@village.org (Warner Losh) Date: Tue, 14 Dec 1999 16:32:04 -0600 (CST) Cc: jlemon@americantv.com, brian@Awfulhak.org, freebsd-arch@freebsd.org, brian@hak.lan.Awfulhak.org X-Mailer: ELM [version 2.4ME+ PL32 (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 Warner Losh said: > In message <19991214160454.26093@right.PCS> Jonathan Lemon writes: > : Loadable device drivers. I ran into this last week or so when > : unloading a driver I'm developing; if I don't do an 'ifconfig xxx delete' > : before the kldunoad, I get a panic. > > That's basically what I want to do in the kernel when a driver calls > if_detach(). > The ATM code has support for detaching ATM network interfaces - it was originally written for SunOS 4.x LKMs. It is able to dynamically attach and detach interfaces via user configuration command. The code, ported to FreeBSD before if_detach() was added, is at sys/netatm/atm_if.c:atm_nif_detach(). -- Mike Spengler Network Computing Services, Inc. Email: mks@networkcs.com 1200 Washington Ave. So. Phone: +1 612 337 3557 Minneapolis MN 55415 FAX: +1 612 337 3400 (aka Minnesota Supercomputer Center) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 14 15:28: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 2643515347 for ; Tue, 14 Dec 1999 15:28: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 AAA09866 for ; Wed, 15 Dec 1999 00:28:20 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA66757 for freebsd-arch@freebsd.org; Wed, 15 Dec 1999 00:28:19 +0100 (MET) Received: from awfulhak.org (dynamic-24.max4-du-ws.dialnetwork.pavilion.co.uk [212.74.9.152]) by hub.freebsd.org (Postfix) with ESMTP id 7A8C214E8C for ; Tue, 14 Dec 1999 15:26:12 -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 XAA32039; Tue, 14 Dec 1999 23:20:41 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 XAA36949; Tue, 14 Dec 1999 23:22:15 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <199912142322.XAA36949@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.0 09/18/1999 To: Jonathan Lemon Cc: Brian Somers , Warner Losh , freebsd-arch@freebsd.org, brian@hak.lan.Awfulhak.org, brian@hak.lan.Awfulhak.org Subject: Re: The if_detach problem In-Reply-To: Message from Jonathan Lemon of "Tue, 14 Dec 1999 16:04:54 CST." <19991214160454.26093@right.PCS> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Dec 1999 23:22:15 +0000 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Dec 12, 1999 at 09:45:36PM +0000, Brian Somers wrote: > > > > > > if_detach doesn't, at least not completely. > > > > > > That's a problem when you want to remove interfaces. One problem is > > > that the routing system caches ifaddr and other things. There is a > > > mechanism in place that could be used to clean things up. > > > > > > In the protosw there is a ctlinput routine which accepts various > > > commands. One way to deal with this is to send a new command when ifa > > > goes away. Right now when we do if_down we send a PRC_IFDOWN. Maybe > > > we need to invent a new PRC_, say PRC_IFDETACH. Then we wouldn't need > > > the kludges in if_detach. The ctlinput routines could then, in the > > > appropriate places, scrub the references to the interface that just > > > went away. > > > > > > I'd like to go down this path, any comments? > > > > Not comments, but my thoughts.... > > > > Is there a lot to be gained by removing interfaces ? > > Loadable device drivers. I ran into this last week or so when > unloading a driver I'm developing; if I don't do an 'ifconfig xxx delete' > before the kldunoad, I get a panic. Right, but how about a ``notthere'' flag instead ? My concern is that there are some APIs that use interface ids (sysctl(PF_ROUTE) springs to mind) and some APIs that use interface names (the struct ifaliasreq ioctls etc) and reassigning the association between the two on the fly seems a tad dangerous - lots of races. Another (more real?) argument for keeping the interface but making it unusable 'till the driver wants it again is that there may be security concerns.... at the moment, ``netstat -i'' reports what's been going on very nicely. Removing the interface entirely will allow people to hide what should not be hidden.... > -- > Jonathan -- 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 Tue Dec 14 15:32: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 7A5631533F for ; Tue, 14 Dec 1999 15:32: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 AAA09926 for ; Wed, 15 Dec 1999 00:32:46 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA66791 for freebsd-arch@freebsd.org; Wed, 15 Dec 1999 00:32:46 +0100 (MET) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 07083152EA for ; Tue, 14 Dec 1999 15:32:32 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA73700; Tue, 14 Dec 1999 16:32:27 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA56248; Tue, 14 Dec 1999 16:32:26 -0700 (MST) Message-Id: <199912142332.QAA56248@harmony.village.org> To: Brian Somers Subject: Re: The if_detach problem Cc: Jonathan Lemon , freebsd-arch@freebsd.org, brian@hak.lan.Awfulhak.org In-reply-to: Your message of "Tue, 14 Dec 1999 23:22:15 GMT." <199912142322.XAA36949@hak.lan.Awfulhak.org> References: <199912142322.XAA36949@hak.lan.Awfulhak.org> Date: Tue, 14 Dec 1999 16:32:26 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199912142322.XAA36949@hak.lan.Awfulhak.org> Brian Somers writes: : Right, but how about a ``notthere'' flag instead ? My concern is that the notthere flag won't be used all the time. Also, with if_detach deletes the memory, which is what fubars the routing tables and the like. There's not a place to hang a not there flag. : My concern is that there are some APIs that use interface ids : (sysctl(PF_ROUTE) springs to mind) and some APIs that use : interface names (the struct ifaliasreq ioctls etc) and reassigning : the association between the two on the fly seems a tad dangerous - : lots of races. There are already lots of races :-) : Another (more real?) argument for keeping the interface but making it : unusable 'till the driver wants it again is that there may be : security concerns.... at the moment, ``netstat -i'' reports what's : been going on very nicely. Removing the interface entirely will : allow people to hide what should not be hidden.... We're talking about a driver which can call if_detach() when it goes away. I'm not sure how to tie that to the netstat -i... When the interface is gone, it is gone, never to return. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 14 15:40: 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 91F29154F4 for ; Tue, 14 Dec 1999 15:39:58 -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 AAA10017 for ; Wed, 15 Dec 1999 00:39:48 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA66848 for freebsd-arch@freebsd.org; Wed, 15 Dec 1999 00:39:47 +0100 (MET) Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id E9A38151F9 for ; Tue, 14 Dec 1999 15:39:38 -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 RAA23303; Tue, 14 Dec 1999 17:39:38 -0600 (CST) Received: (from jlemon@localhost) by right.PCS (8.8.5/8.6.4) id RAA17334; Tue, 14 Dec 1999 17:39:36 -0600 (CST) Message-ID: <19991214173936.37821@right.PCS> Date: Tue, 14 Dec 1999 17:39:36 -0600 From: Jonathan Lemon To: Brian Somers Cc: arch@freebsd.org Subject: Re: The if_detach problem References: <199912142322.XAA36949@hak.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: <199912142322.XAA36949@hak.lan.Awfulhak.org>; from Brian Somers on Dec 12, 1999 at 11:22:15PM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Dec 12, 1999 at 11:22:15PM +0000, Brian Somers wrote: > > On Dec 12, 1999 at 09:45:36PM +0000, Brian Somers wrote: > > > > > > > > if_detach doesn't, at least not completely. > > > > > > > > That's a problem when you want to remove interfaces. One problem is > > > > that the routing system caches ifaddr and other things. There is a > > > > mechanism in place that could be used to clean things up. > > > > > > > > In the protosw there is a ctlinput routine which accepts various > > > > commands. One way to deal with this is to send a new command when ifa > > > > goes away. Right now when we do if_down we send a PRC_IFDOWN. Maybe > > > > we need to invent a new PRC_, say PRC_IFDETACH. Then we wouldn't need > > > > the kludges in if_detach. The ctlinput routines could then, in the > > > > appropriate places, scrub the references to the interface that just > > > > went away. > > > > > > > > I'd like to go down this path, any comments? > > > > > > Not comments, but my thoughts.... > > > > > > Is there a lot to be gained by removing interfaces ? > > > > Loadable device drivers. I ran into this last week or so when > > unloading a driver I'm developing; if I don't do an 'ifconfig xxx delete' > > before the kldunoad, I get a panic. > > Right, but how about a ``notthere'' flag instead ? > > My concern is that there are some APIs that use interface ids > (sysctl(PF_ROUTE) springs to mind) and some APIs that use > interface names (the struct ifaliasreq ioctls etc) and reassigning > the association between the two on the fly seems a tad dangerous - > lots of races. I'd think that trying to maintain a 'notthere' pseudo-state would lead to more problems in the kernel that just doing splhigh() for a short time to remove/rewrite the associations. > Another (more real?) argument for keeping the interface but making it > unusable 'till the driver wants it again is that there may be > security concerns.... at the moment, ``netstat -i'' reports what's > been going on very nicely. Removing the interface entirely will > allow people to hide what should not be hidden.... I'm not sure this applies. At the moment, `netstat -i' does not show interfaces which have no driver in the system. So if I load and then _unload_ a driver, what should 'netstat -i' report? The name of the (nonexistent) driver? Similarly, if the hardware happens to be a PCCARD, and it's popped out, its gone, and there isn't any point in keeping the iface around forever. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 14 17: 8:56 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 B1CF514C37 for ; Tue, 14 Dec 1999 17:08: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 CAA10904 for ; Wed, 15 Dec 1999 02:08:46 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA67266 for freebsd-arch@freebsd.org; Wed, 15 Dec 1999 02:08:45 +0100 (MET) Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 1E9EE14C37 for ; Tue, 14 Dec 1999 17:08:35 -0800 (PST) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id RAA87058 for freebsd-arch@FreeBSD.ORG; Tue, 14 Dec 1999 17:08:34 -0800 (PST) From: Archie Cobbs Message-Id: <199912150108.RAA87058@bubba.whistle.com> Subject: Re: The if_detach problem In-Reply-To: <199912142145.VAA34161@hak.lan.Awfulhak.org> from Brian Somers at "Dec 14, 1999 09:45:36 pm" To: freebsd-arch@freebsd.org Date: Tue, 14 Dec 1999 17:08:34 -0800 (PST) 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 Brian Somers writes: > > I'd like to go down this path, any comments? > > Not comments, but my thoughts.... > > Is there a lot to be gained by removing interfaces ? Another example is netgraph. See the SHUTDOWN section of ng_iface(8). It would be more natural that the interface go away when you kill the node. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 14 17:40: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 194B215104 for ; Tue, 14 Dec 1999 17:40: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 CAA14845 for ; Wed, 15 Dec 1999 02:40:25 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA67422 for freebsd-arch@freebsd.org; Wed, 15 Dec 1999 02:40:25 +0100 (MET) Received: from awfulhak.org (dynamic-12.max4-du-ws.dialnetwork.pavilion.co.uk [212.74.9.140]) by hub.freebsd.org (Postfix) with ESMTP id B81C014FAF for ; Tue, 14 Dec 1999 17:40:14 -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 BAA47374; Wed, 15 Dec 1999 01:34:58 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 BAA01143; Wed, 15 Dec 1999 01:36:43 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <199912150136.BAA01143@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.0 09/18/1999 To: Jonathan Lemon Cc: Brian Somers , arch@freebsd.org, brian@hak.lan.Awfulhak.org Subject: Re: The if_detach problem In-Reply-To: Message from Jonathan Lemon of "Tue, 14 Dec 1999 17:39:36 CST." <19991214173936.37821@right.PCS> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Dec 1999 01:36:43 +0000 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [.....] > > Another (more real?) argument for keeping the interface but making it > > unusable 'till the driver wants it again is that there may be > > security concerns.... at the moment, ``netstat -i'' reports what's > > been going on very nicely. Removing the interface entirely will > > allow people to hide what should not be hidden.... > > I'm not sure this applies. At the moment, `netstat -i' does not > show interfaces which have no driver in the system. So if I load > and then _unload_ a driver, what should 'netstat -i' report? The > name of the (nonexistent) driver? Similarly, if the hardware > happens to be a PCCARD, and it's popped out, its gone, and there > isn't any point in keeping the iface around forever. Yes, maybe a if_detach() based netstat -i style line would be more appropriate ? Hmm, it'd be nice to have netstat -i report per-IP stats too rather than reporting each alias address as having the same (per-interface) statistics. I'll stick it in my mental-todo-list :-I Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll de0 1500 00.00.c0.ff.e9.ce 859160 0 541128 0 507 de0 1500 172.16/24 172.16.0.1 859160 0 541128 0 507 lp0* 1500 0 0 0 0 0 sl0* 552 0 0 0 0 0 sl1* 552 0 0 0 0 0 ppp0* 1500 0 0 0 0 0 ppp1* 1500 0 0 0 0 0 lo0 16384 957056 0 957056 0 0 lo0 16384 127 127.0.0.1 957056 0 957056 0 0 lo0 16384 195.166.136.6 195.166.136.63 957056 0 957056 0 0 tun0 1500 11556 0 17744 0 0 tun0 1500 172.16 172.16.0.1 11556 0 17744 0 0 tun0 1500 212.74.9.182/ 212.74.9.182 11556 0 17744 0 0 tun0 1500 212.74.9.153/ 212.74.9.153 11556 0 17744 0 0 tun0 1500 212.74.9.214/ 212.74.9.214 11556 0 17744 0 0 tun0 1500 212.74.9.244/ 212.74.9.244 11556 0 17744 0 0 tun0 1500 212.74.9.132/ 212.74.9.132 11556 0 17744 0 0 tun0 1500 212.74.9.163/ 212.74.9.163 11556 0 17744 0 0 tun0 1500 212.74.9.155/ 212.74.9.155 11556 0 17744 0 0 tun0 1500 212.74.9.235/ 212.74.9.235 11556 0 17744 0 0 tun0 1500 212.74.9.152/ 212.74.9.152 11556 0 17744 0 0 tun0 1500 212.74.9 212.74.9.221 11556 0 17744 0 0 > -- > Jonathan -- 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 Tue Dec 14 17:56: 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 7E4AB14BB7 for ; Tue, 14 Dec 1999 17:56:05 -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 CAA14977 for ; Wed, 15 Dec 1999 02:56:04 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA67520 for freebsd-arch@freebsd.org; Wed, 15 Dec 1999 02:56:03 +0100 (MET) Received: from awfulhak.org (dynamic-28.max4-du-ws.dialnetwork.pavilion.co.uk [212.74.9.156]) by hub.freebsd.org (Postfix) with ESMTP id 427FF14CF4 for ; Tue, 14 Dec 1999 17:55:54 -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 BAA47587; Wed, 15 Dec 1999 01:55:52 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 BAA01645; Wed, 15 Dec 1999 01:57:37 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <199912150157.BAA01645@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.0 09/18/1999 To: Brian Somers Cc: Jonathan Lemon , arch@freebsd.org, brian@hak.lan.Awfulhak.org, brian@hak.lan.Awfulhak.org Subject: Re: The if_detach problem In-Reply-To: Message from Brian Somers of "Wed, 15 Dec 1999 01:36:43 GMT." <199912150136.BAA01143@hak.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Dec 1999 01:57:37 +0000 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Yes, maybe a if_detach() based netstat -i style line would be more > appropriate ? via a kernel printf() I mean.... -- 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 Tue Dec 14 18:12: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 D239D15282 for ; Tue, 14 Dec 1999 18:12: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 DAA15194 for ; Wed, 15 Dec 1999 03:12:38 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA67618 for freebsd-arch@freebsd.org; Wed, 15 Dec 1999 03:12:37 +0100 (MET) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 3DC30153C4 for ; Tue, 14 Dec 1999 18:12:17 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id TAA23927; Tue, 14 Dec 1999 19:11:58 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp01.primenet.com, id smtpdAAA7aa4uU; Tue Dec 14 19:11:37 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id TAA17174; Tue, 14 Dec 1999 19:11:29 -0700 (MST) From: Terry Lambert Message-Id: <199912150211.TAA17174@usr08.primenet.com> Subject: Re: The if_detach problem To: brian@Awfulhak.org (Brian Somers) Date: Wed, 15 Dec 1999 02:11:29 +0000 (GMT) Cc: imp@village.org, freebsd-arch@freebsd.org, brian@hak.lan.Awfulhak.org In-Reply-To: <199912142145.VAA34161@hak.lan.Awfulhak.org> from "Brian Somers" at Dec 14, 99 09:45:36 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 > Is there a lot to be gained by removing interfaces ? Yes. You can then unplug the hardware that they represent. > I would think that losing an interface would mean the existence of an > interface number with no interface (this may break code that caches > interface number-to-name information (ppp(8)... I thought about this > when I wrote the code, but I've never tested it)). "Caching considered harmful". 8-). > I would also think that adding another interface would get the > deallocated interface number again.... this'll kill any program that > thinks it can cache this sort of info (ppp(8)). > > I guess ppp could be changed to not cache this sort of stuff.... Yes. 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 Dec 14 18:17: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 6738115370 for ; Tue, 14 Dec 1999 18:17: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 DAA15228 for ; Wed, 15 Dec 1999 03:17:13 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA67644 for freebsd-arch@freebsd.org; Wed, 15 Dec 1999 03:17:12 +0100 (MET) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id B5FAF15282 for ; Tue, 14 Dec 1999 18:16:48 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id TAA08379; Tue, 14 Dec 1999 19:16:27 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpdAAA5laWuq; Tue Dec 14 19:16:20 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id TAA17370; Tue, 14 Dec 1999 19:16:31 -0700 (MST) From: Terry Lambert Message-Id: <199912150216.TAA17370@usr08.primenet.com> Subject: Re: The if_detach problem To: brian@Awfulhak.org (Brian Somers) Date: Wed, 15 Dec 1999 02:16:31 +0000 (GMT) Cc: jlemon@americantv.com, brian@Awfulhak.org, imp@village.org, freebsd-arch@freebsd.org, brian@hak.lan.Awfulhak.org In-Reply-To: <199912142322.XAA36949@hak.lan.Awfulhak.org> from "Brian Somers" at Dec 14, 99 11:22:15 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 > Right, but how about a ``notthere'' flag instead ? A "virtual interface"? This plays havoc with default routes. > My concern is that there are some APIs that use interface ids > (sysctl(PF_ROUTE) springs to mind) and some APIs that use > interface names (the struct ifaliasreq ioctls etc) and reassigning > the association between the two on the fly seems a tad dangerous - > lots of races. I think the answer is as obvious as "ps" and "libkvm": data interfaces suck, and procedureal interfaces don't. > Another (more real?) argument for keeping the interface but making it > unusable 'till the driver wants it again is that there may be > security concerns.... at the moment, ``netstat -i'' reports what's > been going on very nicely. Removing the interface entirely will > allow people to hide what should not be hidden.... ??? Doug Ambrisko is running wireless in the office right now with a PCMCIA card. It's unreasonable to not allow him to switch between a wireless adapter and a docking bay or other PCMCIA card as his default route as it becomes available. I think that the routing table and other information needs to be correct, more than it needs to be historically accurate. For netstat -i, if you destroy the object on which you are keeping statistics, it's right to destroy the statistics information as well. Consider that packets sent, collisions, and similar counts are not presistant across a reboot (in which interfaces are "deinstanced" and subsequently "reinstanced"). I know there's a lot of cached state issues, but like "ps", this isn't a very good reason to _not_ fix them. 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 Dec 14 19:51: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 F147115375 for ; Tue, 14 Dec 1999 19:51:09 -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 EAA15868 for ; Wed, 15 Dec 1999 04:51:07 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA67975 for freebsd-arch@freebsd.org; Wed, 15 Dec 1999 04:51:06 +0100 (MET) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 2826C14BE1 for ; Tue, 14 Dec 1999 19:50:44 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id WAA13897; Tue, 14 Dec 1999 22:50:42 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id WAA14947; Tue, 14 Dec 1999 22:50:11 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 14 Dec 1999 22:50:11 -0500 (EST) To: Jonathan Lemon Cc: freebsd-arch@freebsd.org Subject: Re: The if_detach problem In-Reply-To: <19991214160454.26093@right.PCS> References: <199912142145.VAA34161@hak.lan.Awfulhak.org> <19991214160454.26093@right.PCS> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14423.3759.258444.555708@grasshopper.cs.duke.edu> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jonathan Lemon writes: > > Is there a lot to be gained by removing interfaces ? > > Loadable device drivers. I ran into this last week or so when > unloading a driver I'm developing; if I don't do an 'ifconfig xxx delete' > before the kldunoad, I get a panic. I have the following code in a loadable (IP-only, not ethernet) driver of mine. It doesn't crash on unload anymore. However, I think something like this should be standard & available for (un)loadable drivers to call at unload time: s = splnet(); /* * Close down routes etc. * This needs to be at splnet */ TAILQ_FOREACH(ifp, &ifnet, if_link){ if(ifp == &sc->myri_if){ ifp_valid = 1; break; } } if(ifp_valid){ struct ifaddr *ia = 0; struct in_ifaddr *in_ia = 0; ifp = &sc->myri_if; TAILQ_FOREACH(ia, &ifp->if_addrhead, ifa_link){ if (ia->ifa_addr->sa_family != AF_INET) continue; in_ia = (struct in_ifaddr *)ia; in_ifscrub(ifp, in_ia); TAILQ_REMOVE(&in_ifaddrhead, in_ia, ia_link); } if_detach(&sc->myri_if); } splx(s); Cheers, Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 14 22:32: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 1B714152AA for ; Tue, 14 Dec 1999 22:32: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 HAA16881 for ; Wed, 15 Dec 1999 07:32:40 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id HAA68774 for freebsd-arch@freebsd.org; Wed, 15 Dec 1999 07:32:39 +0100 (MET) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id A76A4152AA for ; Tue, 14 Dec 1999 22:32:32 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id XAA75073; Tue, 14 Dec 1999 23:32:28 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id XAA58638; Tue, 14 Dec 1999 23:32:28 -0700 (MST) Message-Id: <199912150632.XAA58638@harmony.village.org> To: Andrew Gallatin Subject: Re: The if_detach problem Cc: freebsd-arch@freebsd.org In-reply-to: Your message of "Tue, 14 Dec 1999 22:50:11 EST." <14423.3759.258444.555708@grasshopper.cs.duke.edu> References: <14423.3759.258444.555708@grasshopper.cs.duke.edu> <199912142145.VAA34161@hak.lan.Awfulhak.org> <19991214160454.26093@right.PCS> Date: Tue, 14 Dec 1999 23:32:28 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <14423.3759.258444.555708@grasshopper.cs.duke.edu> Andrew Gallatin writes: : s = splnet(); : /* : * Close down routes etc. : * This needs to be at splnet : */ : TAILQ_FOREACH(ifp, &ifnet, if_link){ : if(ifp == &sc->myri_if){ : ifp_valid = 1; : break; : } : } : if(ifp_valid){ : struct ifaddr *ia = 0; : struct in_ifaddr *in_ia = 0; : ifp = &sc->myri_if; : : TAILQ_FOREACH(ia, &ifp->if_addrhead, ifa_link){ : if (ia->ifa_addr->sa_family != AF_INET) : continue; : in_ia = (struct in_ifaddr *)ia; : in_ifscrub(ifp, in_ia); : TAILQ_REMOVE(&in_ifaddrhead, in_ia, ia_link); : } : if_detach(&sc->myri_if); : } : splx(s); Any reason not to fold this into if_detach until something more generic could be developed? I like it better than the current solution chceked in recently... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 15 5:13: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 7D2E3155F8 for ; Wed, 15 Dec 1999 05:13: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 OAA22685 for ; Wed, 15 Dec 1999 14:13:06 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA69962 for freebsd-arch@freebsd.org; Wed, 15 Dec 1999 14:13:01 +0100 (MET) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 55F4B14C24 for ; Wed, 15 Dec 1999 05:12:26 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id IAA22692; Wed, 15 Dec 1999 08:12:21 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id IAA15693; Wed, 15 Dec 1999 08:10:33 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 15 Dec 1999 08:10:33 -0500 (EST) To: Warner Losh Cc: freebsd-arch@freebsd.org, anderson@cs.duke.edu Subject: Re: The if_detach problem In-Reply-To: <199912150632.XAA58638@harmony.village.org> References: <14423.3759.258444.555708@grasshopper.cs.duke.edu> <199912142145.VAA34161@hak.lan.Awfulhak.org> <19991214160454.26093@right.PCS> <199912150632.XAA58638@harmony.village.org> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14423.37474.771869.241460@grasshopper.cs.duke.edu> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh writes: > In message <14423.3759.258444.555708@grasshopper.cs.duke.edu> Andrew Gallatin writes: > : s = splnet(); > : /* > : * Close down routes etc. > : * This needs to be at splnet > : */ <...> > > Any reason not to fold this into if_detach until something more > generic could be developed? I like it better than the current > solution chceked in recently... I'm certainly in favor of it. If you do commit it, please give credit in the commit message to the original author who I obtained it from -- Darrell Anderson Cheers, Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 15 9: 3: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 78608150E4 for ; Wed, 15 Dec 1999 09:03: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 SAA27099 for ; Wed, 15 Dec 1999 18:03:15 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA71534 for freebsd-arch@freebsd.org; Wed, 15 Dec 1999 18:03:13 +0100 (MET) Received: from pau-amma.whistle.com (pau-amma.whistle.com [207.76.205.64]) by hub.freebsd.org (Postfix) with ESMTP id 64B6414FDF for ; Wed, 15 Dec 1999 09:03:02 -0800 (PST) (envelope-from dhw@whistle.com) Received: (from dhw@localhost) by pau-amma.whistle.com (8.9.2/8.9.2) id JAA04023 for freebsd-arch@FreeBSD.ORG; Wed, 15 Dec 1999 09:03:01 -0800 (PST) Date: Wed, 15 Dec 1999 09:03:01 -0800 (PST) From: David Wolfskill Message-Id: <199912151703.JAA04023@pau-amma.whistle.com> To: freebsd-arch@freebsd.org Subject: Re: The if_detach problem In-Reply-To: <199912150216.TAA17370@usr08.primenet.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >From: Terry Lambert >Date: Wed, 15 Dec 1999 02:16:31 +0000 (GMT) >For netstat -i, if you destroy the object on which you are keeping >statistics, it's right to destroy the statistics information as >well. Though it would be Nice (tm) to have the option to record the statistical information somewhere just before destroying it, so that various forms of analysis have some hope of functioning. >Consider that packets sent, collisions, and similar counts are not >presistant across a reboot (in which interfaces are "deinstanced" >and subsequently "reinstanced"). Granted.... :-} 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 Dec 15 9: 9: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 23F1615338 for ; Wed, 15 Dec 1999 09:09: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 SAA27195 for ; Wed, 15 Dec 1999 18:09:03 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA71594 for freebsd-arch@freebsd.org; Wed, 15 Dec 1999 18:09:02 +0100 (MET) Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id E8D081551D for ; Wed, 15 Dec 1999 09:08:38 -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 JAA17185; Wed, 15 Dec 1999 09:07:39 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id JAA16229; Wed, 15 Dec 1999 09:07:39 -0800 Received: from softweyr.com ([204.68.178.39]) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA06383; Wed, 15 Dec 99 09:07:25 PST Message-Id: <3857CB17.116DAF99@softweyr.com> Date: Wed, 15 Dec 1999 10:08:39 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Brian Somers Cc: Warner Losh , freebsd-arch@freebsd.org, brian@hak.lan.Awfulhak.org Subject: Re: The if_detach problem References: <199912142145.VAA34161@hak.lan.Awfulhak.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brian Somers wrote: > > > > > if_detach doesn't, at least not completely. > > > > That's a problem when you want to remove interfaces. One problem is > > that the routing system caches ifaddr and other things. There is a > > mechanism in place that could be used to clean things up. > > > > In the protosw there is a ctlinput routine which accepts various > > commands. One way to deal with this is to send a new command when ifa > > goes away. Right now when we do if_down we send a PRC_IFDOWN. Maybe > > we need to invent a new PRC_, say PRC_IFDETACH. Then we wouldn't need > > the kludges in if_detach. The ctlinput routines could then, in the > > appropriate places, scrub the references to the interface that just > > went away. > > > > I'd like to go down this path, any comments? > > Not comments, but my thoughts.... > > Is there a lot to be gained by removing interfaces ? Think PC Card/CardBus here, Brian. The interface truly is gone. -- "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 Dec 15 9:50: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 BE7CE154DE for ; Wed, 15 Dec 1999 09:50: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 SAA27603 for ; Wed, 15 Dec 1999 18:50:35 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA71921 for freebsd-arch@freebsd.org; Wed, 15 Dec 1999 18:50:35 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 302C914FDF for ; Wed, 15 Dec 1999 09:45:30 -0800 (PST) (envelope-from ambrisko@whistle.com) Received: from whistle.com (ibmpc.whistle.com [207.76.205.196]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id JAA83238; Wed, 15 Dec 1999 09:45:26 -0800 (PST) Received: (from ambrisko@localhost) by whistle.com (8.9.3/8.9.1) id JAA22360; Wed, 15 Dec 1999 09:17:14 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <199912151717.JAA22360@whistle.com> Subject: Re: The if_detach problem In-Reply-To: <199912150216.TAA17370@usr08.primenet.com> from Terry Lambert at "Dec 15, 1999 02:16:31 am" To: Terry Lambert Date: Wed, 15 Dec 1999 09:17:14 -0800 (PST) Cc: freebsd-arch@freebsd.org X-Mailer: ELM [version 2.4ME+ PL61 (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 Terry Lambert writes: | Doug Ambrisko is running wireless in the office right now with a | PCMCIA card. It's unreasonable to not allow him to switch between | a wireless adapter and a docking bay or other PCMCIA card as his | default route as it becomes available. Well since I've been named I'll add my comments here. At work we have this nifty wireless network at home I just have an ethernet cable. Also I have a USB widget that can be a network device. Typically I have 2 network devices in my laptop so I have to swap the wireless for the ethernet between work & home. All these things can come an go during a "booted" session on my laptop. Current I halt my laptop take it home and plug it into the network there and boot it. I should be able to just suspend it and never turn it off since it will sleep for a long time (except for OS upgrade) and swap cards at will (okay maybe I may have to run a slot down command). Similar swaping between USB thingys should also work and with USB it easy to add lots of network widgets at the same time. Netgraph is also is an example. I don't want to end up with device ng4938758 after having a machine up for a year and doing various things with kld's. It would be nice to re-use the name space. However, there are times when we need somthing somewhat static (actually Nick solved the problem in USB land). The issue is that when a pccard is inserted you usually have to run something to configure it's IP address etc. However, you need to know what device it is. "usbd" has a psuedo various "DEVICE" that gives you the name of the device. So in the config file you can pass the device name. This was critical in USB for knowing what device to download firmware to so you don't blow away the wrong device. Currently what I have to do with pccard is to statically define my Ethernet cards as ed0 & ed1 in the config file but why should I? pccardd should just run the correct command on the device it just configured. Note the only way this works and I know which device is which, is that I use 2 ne2000 cards from different vendors. Same vendor is another tricky issue when there is no way to tell the difference (this happens in SCSI, ATA, USB etc). So the prior paradigms are changing and we need to look at solutions that get us closer to what we will need. Doug A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 16 10: 5: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 C094714D99 for ; Thu, 16 Dec 1999 10:05:38 -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 TAA17819 for ; Thu, 16 Dec 1999 19:05:36 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA79228 for freebsd-arch@freebsd.org; Thu, 16 Dec 1999 19:05:36 +0100 (MET) Received: from orange.kame.net (orange.kame.net [203.178.141.194]) by hub.freebsd.org (Postfix) with ESMTP id 4C8E7151F2; Thu, 16 Dec 1999 10:05:10 -0800 (PST) (envelope-from shin@nd.net.fujitsu.co.jp) Received: from localhost (kame209.kame.net [203.178.141.209]) by orange.kame.net (8.9.1+3.1W/3.7W) with ESMTP id DAA16433; Fri, 17 Dec 1999 03:05:03 +0900 (JST) To: freebsd-arch@freebsd.org, cvs-committers@freebsd.org Subject: Re: [Solicite review for KAME 5th patch] In-Reply-To: <19991212223550M.shin@nd.net.fujitsu.co.jp> References: <19991212040532I.shin@nd.net.fujitsu.co.jp> <19991212094142.F32274@daemon.ninth-circle.org> <19991212223550M.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: <19991217030527N.shin@nd.net.fujitsu.co.jp> Date: Fri, 17 Dec 1999 03:05:27 +0900 From: Yoshinobu Inoue X-Dispatcher: imput version 990905(IM130) Lines: 60 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, 5th KAME patch is updated, as below. http://paradise.kame.net/v6proxy/diana2/shin/work/freebsd/kernel-ipsec.19991217 Changes from previous version: -IPSEC patch is completed, and small changes are added to dummynet. dummynet seems to be working after this patch, as far as I tried the sample configuration written in 'man dummynet'. -IPV6 FW is temporary removed Important points are (which I noticed), (Sorry for long explanations) -netinet *_input routines prototype is changed, and ipprotosw.h is added for the purpose. This is necessary for chained protocol header support in IPSEC and IPV6. An alternative is to change sys/net/protosw.h, but it affects other protocol stacks. -KAME IPSEC use sending mbuf's m_pkthdr.rcvif to keep a pointer to the socket, and it conflicts with IPFW etc in ip_output(). This is necessary to support IPSEC over socket communications, because their IPSEC related informations are attached to their sockets, and IP layer would like to see it. So I added new flag IP_SOCKINMRCVIF which is passed to ip_output() as one of 'flags' arg's bit. Only when this is set in ip_output()'s 'flags' arg, the sending mbuf's m_pkthdr.rcvif is a pointer to the socket. It is saved into 'so' at the top of ip_output(), and then m_pkthdr.rcvif is NULL cleared. This should be safe, because sending packet doesn't have received interface. An alternative is increasing ip_output() arguments, but ip_output() is called from many place, so it affects much. IP_SOCKINMRCVIF is only need to be specified by transport layer who wants to use IPSEC. Also as this change, now 'flags' info need to be kept over dummynet queue. So I added 'flags' info to the dn_pkt structure. And it is specified as 'flags' arg in ip_output() from dn_move(). Now dn_dst (which was specified via 'flags' arg from dn_move()) is not passed as an argument, but as a member of dn_pkt in 1st mbuf. These changes seems to be working in my enviroment, but please review it if it is best way or not. -sys/netkey is completely replaced to PF_KEY Version 2 based one. So the patches are not human readable. As this change, usr.sbin/keyadmin will become not buildable. Instead, PF_KEY Version 2 based 'setkey' command will be added. And also, please let me commit KAME 4th patches.(IPv6 specific functions in libc/net) Which only affect comming IPv6 related apps, and I think it is most effectively confirmed with those apps. Yoshinobu Inoue To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 16 23: 4: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 F1FFA15075 for ; Thu, 16 Dec 1999 23:04: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 IAA03466 for ; Fri, 17 Dec 1999 08:04:37 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA82836 for freebsd-arch@freebsd.org; Fri, 17 Dec 1999 08:04:05 +0100 (MET) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 6362D14F8D; Thu, 16 Dec 1999 23:03:57 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id AAA94524; Fri, 17 Dec 1999 00:03:55 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id AAA78001; Fri, 17 Dec 1999 00:03:55 -0700 (MST) Message-Id: <199912170703.AAA78001@harmony.village.org> To: mobile@freebsd.org Cc: arch@freebsd.org Subject: Card eject and if_detach. Date: Fri, 17 Dec 1999 00:03:55 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've taken the advice to look at netatm atm_nif_detach routine. It appears that all that is needed from the initial hack is to add the route table walking. In testing the fix I found that I could remove the card and then ping or telnet another machine. This always used to crash the machine, and now I get a hostname lookup failure (properly since there is no interface to send to the packets out). The patches that Andrew Gallatin fixed were already in the previous kludge that I committed earlier. I did add a splnet/splx to if_detach which should help some race conditions. Please let me know what you think about sys/net/if.c version 1.81. I added the route deletion code from atm_nif_detach and atm_netif_rtdel. Longer term there needs to be some cleanup in this area, since the inet4 specific code in if_detach. I'm moving on to other pccard things, but will try to revisit this in the fullness of time. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 17 8:32: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 33063150CB for ; Fri, 17 Dec 1999 08:32: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 RAA13439 for ; Fri, 17 Dec 1999 17:32:19 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA01080 for freebsd-arch@freebsd.org; Fri, 17 Dec 1999 17:32:19 +0100 (MET) Received: from fgwmail7.fujitsu.co.jp (fgwmail7.fujitsu.co.jp [192.51.44.37]) by hub.freebsd.org (Postfix) with ESMTP id C1D3714F49; Fri, 17 Dec 1999 08:30:37 -0800 (PST) (envelope-from shin@nd.net.fujitsu.co.jp) Received: from m3.gw.fujitsu.co.jp by fgwmail7.fujitsu.co.jp (8.9.3/3.7W-MX9912-Fujitsu Gateway) id BAA25487; Sat, 18 Dec 1999 01:30:32 +0900 (JST) Received: from incapgw.fujitsu.co.jp by m3.gw.fujitsu.co.jp (8.9.3/3.7W-9912-Fujitsu Domain Master) id BAA00205; Sat, 18 Dec 1999 01:30:31 +0900 (JST) Received: from localhost ([192.168.245.120]) by incapgw.fujitsu.co.jp (8.9.3/3.7W-9912) id BAA14310; Sat, 18 Dec 1999 01:30:29 +0900 (JST) To: freebsd-arch@freebsd.org, cvs-committers@freebsd.org Subject: Re: [Solicite review for KAME 5th patch] In-Reply-To: <19991217030527N.shin@nd.net.fujitsu.co.jp> References: <19991212094142.F32274@daemon.ninth-circle.org> <19991212223550M.shin@nd.net.fujitsu.co.jp> <19991217030527N.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: <19991218013056S.shin@nd.net.fujitsu.co.jp> Date: Sat, 18 Dec 1999 01:30:56 +0900 From: Yoshinobu Inoue X-Dispatcher: imput version 990905(IM130) Lines: 57 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hi, 5th KAME patch is updated, as below. > > http://paradise.kame.net/v6proxy/diana2/shin/work/freebsd/kernel-ipsec.19991217 Sorry, this patches lacks of an IPSEC related initialization at tcp_attach(), and it might cause kernel panic. If someone actually try applying it, please use updated patches below, http://paradise.kame.net/v6proxy/diana2/shin/work/freebsd/kernel-ipsec.19991218 or, apply this patch additionally to the previous patches. Thanks, Yoshinobu Inoue Index: tcp_usrreq.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_usrreq.c,v retrieving revision 1.49 diff -u -r1.49 tcp_usrreq.c --- tcp_usrreq.c 1999/12/13 00:39:20 1.49 +++ tcp_usrreq.c 1999/12/17 16:24:53 @@ -34,6 +34,7 @@ * $FreeBSD: src/sys/netinet/tcp_usrreq.c,v 1.49 1999/12/13 00:39:20 shin Exp $ */ +#include "opt_ipsec.h" #include "opt_tcpdebug.h" #include @@ -63,6 +64,10 @@ #include #endif +#ifdef IPSEC +#include +#endif /*IPSEC*/ + /* * TCP protocol interface to socket abstraction. */ @@ -731,6 +736,13 @@ if (error) return (error); inp = sotoinpcb(so); +#ifdef IPSEC + error = ipsec_init_policy(so, &inp->inp_sp); + if (error) { + in_pcbdetach(inp); + return (error); + } +#endif /*IPSEC*/ inp->inp_vflag |= INP_IPV4; tp = tcp_newtcpcb(inp); if (tp == 0) { To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 19 9:49: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 9E02F14E1D for ; Sun, 19 Dec 1999 09:49: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 SAA09146 for ; Sun, 19 Dec 1999 18:49:23 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA13893 for freebsd-arch@freebsd.org; Sun, 19 Dec 1999 18:49:15 +0100 (MET) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id CED6414D97 for ; Sun, 19 Dec 1999 09:49:02 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (beefcake.zeta.org.au [203.26.10.12]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id EAA11420; Mon, 20 Dec 1999 04:48:47 +1100 Date: Mon, 20 Dec 1999 04:48:29 +1100 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Martin Cracauer Cc: arch@freebsd.org Subject: Re: Concrete plans for ucontext/mcontext changes around 4.0 In-Reply-To: <19991213091915.D13197@cons.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 Mon, 13 Dec 1999, Martin Cracauer wrote: > First correction: > > > - Add one int member to use as 32 bitwise booleans to indicate what > > the SSE/additional space is used for in this signal invocation. FPU > > state will unconditionally be there. I think I prefer several u_int members giving the offset and size of each extension. > Forgot about lazy FPU context switching (should have finished reading > my mailbox). FPU context is not always there. > > The Linux people claim that lazy FPU switching is not worth the effort > anymore on modern machines. I didn't see any proof or numbers. Anyone > of you? fnsave+frstor takes about 213 cycles on a Celeron. Doing it unconditionally for every context switch would thus cost 250-500 nsec on a modern machine. This is probably still worth avoiding. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 19 12:34: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 6764314E6E for ; Sun, 19 Dec 1999 12:34: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 VAA10179 for ; Sun, 19 Dec 1999 21:34:38 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA14605 for freebsd-arch@freebsd.org; Sun, 19 Dec 1999 21:34:37 +0100 (MET) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 659A014A1E for ; Sun, 19 Dec 1999 12:34:24 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40328>; Mon, 20 Dec 1999 07:25:29 +1100 Content-return: prohibited Date: Mon, 20 Dec 1999 07:34:06 +1100 From: Peter Jeremy Subject: Re: Concrete plans for ucontext/mcontext changes around 4.0 In-reply-to: <19991213091915.D13197@cons.org>; from cracauer@cons.org on Mon, Dec 13, 1999 at 07:19:16PM +1100 To: Martin Cracauer Cc: arch@freebsd.org Message-Id: <99Dec20.072529est.40328@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=us-ascii References: <19991212172602.A10611@cons.org> <19991213091915.D13197@cons.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Dec-13 19:19:16 +1100, Martin Cracauer wrote: >Forgot about lazy FPU context switching (should have finished reading >my mailbox). FPU context is not always there. > >The Linux people claim that lazy FPU switching is not worth the effort >anymore on modern machines. I didn't see any proof or numbers. Anyone >of you? Currently, the i386 half implements lazy FPU switching[1]. Based on some experimenting over the weekend, I don't believe it is worthwhile implementing full lazy FPU switching, but our semi-lazy switching is a definite win. I patched npx.c (patches at end) and extracted the following statistics: ctxt DNA FP swtch traps swtch 1754982 281557 59753 build world and a few CVS operations [2] 79044 18811 10341 gnuplot and xv in parallel [3] 800 138 130 parallel FP-intensive progs [4]. In the above, `ctxt swtch' is the number of context switches counted via vm.stats.sys.v_swtch. `DNA traps' is the number of device not available traps registered and `FP swtch' is the number of DNA traps where the FP context loaded is different to that saved on the preceeding context switch. Moving to full lazy FPU switching would save (DNA traps - FP swtch) fsave/frestor pairs and the same number of traps[5]. Whilst the real savings incurred can't be directly derived from the above figures, external knowledge of the real time taken for the above, together with the estimated cost of a DNA trap + fsave, suggests a saving of much less than 0.1% - which is getting towards the unmeasurable level. The best case would be a single, low priority FP-intensive process combined with lots of I/O bound integer-only processes (eg setiathome as an idle task) - which I don't have figures for, but expect the overheads (for the FP process only) would be <1%. The above figures do suggest that moving from the semi-lazy approach to one where the FPU context was saved/restored on each context switch would be wasteful - FP is not used about 80% of the time and fsave/ frestor are expensive instructions. Notes: [1] Currently, on the i386, the FP (NPX) registers are saved when a context switch occurs and the FPU had been used. The NPX is then flagged as `not equipped', causing a Device Not Available (DNA) trap when the next FP instruction is executed. At that point the appropriate FPU context is restored. Full lazy switching would postpone the register save until an FP instruction was executed by a different process. [2] Boot to single user, run 'make buildworld' inside script(1). The buildworld had a few hiccups along the way which I patched around and then re-ran 'make everything'. [3] I ran the gnuplot demos and the xv visual schnauzer updating a large directory of pictures in parallel. (Multi-user X11). [4] This was four parallel copies of a circuit analysis program I wrote. It spent most of its time solving a complex 26x26 matrix using Gaussian elimination. (Multi-user console). [5] The trap saving would occur if the FPU enabled bit was set according to the contents of the FPU (ie the FPU is left as `enabled' when a context switch occurred into the process that last used the FPU, and `not enabled' otherwise). Index: npx.c =================================================================== RCS file: /home/peter/cvs/src/sys/i386/isa/npx.c,v retrieving revision 1.78 diff -u -r1.78 npx.c --- npx.c 1999/09/21 10:51:47 1.78 +++ npx.c 1999/12/17 09:53:02 @@ -779,6 +779,15 @@ } } +static int fp_dna; /* number of DNA traps */ +static int fp_swtch; /* Number of real FP context switches */ +static struct proc *fpuproc; /* Last proc to use FPU */ + +SYSCTL_INT(_hw, OID_AUTO, fp_dna, CTLFLAG_RW, &fp_dna, 0, + "Number of NPX DNA traps"); +SYSCTL_INT(_hw, OID_AUTO, fp_swtch, CTLFLAG_RW, &fp_swtch, 0, + "Number of NPX context switches"); + /* * Implement device not available (DNA) exception * @@ -797,6 +806,11 @@ panic("npxdna"); } stop_emulating(); + fp_dna++; + if (curproc != fpuproc) { + fpuproc = curproc; + fp_swtch++; + } /* * Record new context early in case frstor causes an IRQ13. */ Peter -- Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 19 19: 3: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 1331615250 for ; Sun, 19 Dec 1999 19:03: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 EAA18545 for ; Mon, 20 Dec 1999 04:03:38 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA17100 for freebsd-arch@freebsd.org; Mon, 20 Dec 1999 04:03:37 +0100 (MET) Received: from fgwmail5.fujitsu.co.jp (fgwmail5.fujitsu.co.jp [192.51.44.35]) by hub.freebsd.org (Postfix) with ESMTP id A3E0714A0A; Sun, 19 Dec 1999 19:03:28 -0800 (PST) (envelope-from shin@nd.net.fujitsu.co.jp) Received: from m5.gw.fujitsu.co.jp by fgwmail5.fujitsu.co.jp (8.9.3/3.7W-MX9912-Fujitsu Gateway) id MAA12209; Mon, 20 Dec 1999 12:03:26 +0900 (JST) Received: from chisato.nd.net.fujitsu.co.jp by m5.gw.fujitsu.co.jp (8.9.3/3.7W-9912-Fujitsu Domain Master) id MAA00954; Mon, 20 Dec 1999 12:03:26 +0900 (JST) Received: from localhost (dhcp7194.nd.net.fujitsu.co.jp [10.18.7.194]) by chisato.nd.net.fujitsu.co.jp (8.8.5+2.7Wbeta5/3.3W8chisato-970826) with ESMTP id MAA06825; Mon, 20 Dec 1999 12:03:25 +0900 (JST) To: freebsd-arch@freebsd.org, cvs-committers@freebsd.org Subject: [Solicite review for KAME 6th patch] 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: <19991220120351Z.shin@nd.net.fujitsu.co.jp> Date: Mon, 20 Dec 1999 12:03:51 +0900 From: Yoshinobu Inoue X-Dispatcher: imput version 990905(IM130) Lines: 86 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The 6th KAME patches is prepared. http://paradise.kame.net/v6proxy/diana2/shin/work/freebsd/udp-raw-apps.19991220 This time, it includes, -gethostbyaddr(), gethostbyname(), etc support in libc/net (but DNS query over IPv6 transport is not yet) -several udp and raw socket apps ping6 rtsol(host address autoconfiguration tool. Actually the source code is shared with 'rtsold'. Though it needs 'rtadvd' daemon on a router, 'rtadvd' for current is not yet.) rtsold(host address autoconfiguration daemon for Note PC, which frequently change its subnet) gifconfig(v6/v4, v6/v4, v4/v4, v6/v6 tunneling configuration) ifmcstat(print out v6 multicast addr configuration info) prefix(assigne address prefix, e.g. subnet addr, just like ifconfig for full addr. it also support host internal prefix renumbering) route6d rip6query As far as I roughly checked those apps, they seems to work fine over 5th KAME patched machines. Also, confirming those apps, I found some bugs and cause of warnings in the patched kernel. I fixed them and updated 5th KAME patches as below. http://paradise.kame.net/v6proxy/diana2/shin/work/freebsd/kernel-ipsec.19991220 I'll also attach the changes from previous version at the end of this mail. Please give me comments, thanks, Yoshinobu Inoue --- sys/netinet/in_proto.c Thu Dec 16 13:11:15 1999 +++ sys.tmp/netinet/in_proto.c Mon Dec 20 05:43:06 1999 @@ -37,6 +37,7 @@ #include "opt_ipdivert.h" #include "opt_ipx.h" #include "opt_ipsec.h" +#include "opt_inet6.h" #include #include --- sys/netinet6/ip6_input.c Thu Dec 16 14:02:41 1999 +++ sys.tmp/netinet6/ip6_input.c Sun Dec 19 09:02:57 1999 @@ -211,7 +211,8 @@ } /* cheat */ -SYSINIT(netinet6init2, SI_SUB_PROTO_DOMAIN, SI_ORDER_THIRD, ip6_init2, NULL); +/* This must be after route_init(), which is now SI_ORDER_THIRD */ +SYSINIT(netinet6init2, SI_SUB_PROTO_DOMAIN, SI_ORDER_MIDDLE, ip6_init2, NULL); /* * IP6 input interrupt handling. Just pass the packet to ip6_input. --- sys/net/route.c Fri Dec 10 11:53:43 1999 +++ sys.tmp/net/route.c Mon Dec 20 05:42:45 1999 @@ -1077,4 +1077,5 @@ return (error); } -SYSINIT(route, SI_SUB_PROTO_DOMAIN, SI_ORDER_ANY, route_init, 0); +/* This must be before ip6_init2(), which is now SI_ORDER_MIDDLE */ +SYSINIT(route, SI_SUB_PROTO_DOMAIN, SI_ORDER_THIRD, route_init, 0); --- sys/sys/socket.h Fri Jan 1 14:11:25 1999 +++ sys.tmp/sys/socket.h Sun Dec 19 06:20:06 1999 @@ -363,7 +363,7 @@ /* given pointer to struct cmsghdr, return pointer to next cmsghdr */ #define CMSG_NXTHDR(mhdr, cmsg) \ (((caddr_t)(cmsg) + (cmsg)->cmsg_len + sizeof(struct cmsghdr) > \ - (mhdr)->msg_control + (mhdr)->msg_controllen) ? \ + (caddr_t)(mhdr)->msg_control + (mhdr)->msg_controllen) ? \ (struct cmsghdr *)NULL : \ (struct cmsghdr *)((caddr_t)(cmsg) + CMSG_ALIGN((cmsg)->cmsg_len))) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 20 13:54: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 4A83415345 for ; Mon, 20 Dec 1999 13:54:13 -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 WAA02960 for ; Mon, 20 Dec 1999 22:54:11 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA22244 for freebsd-arch@freebsd.org; Mon, 20 Dec 1999 22:54:10 +0100 (MET) Received: by hub.freebsd.org (Postfix, from userid 664) id F324415340; Mon, 20 Dec 1999 13:53:51 -0800 (PST) Date: Mon, 20 Dec 1999 13:53:51 -0800 From: "David O'Brien" To: Yoshinobu Inoue Cc: John Hay , freebsd-arch@freebsd.org, cvs-committers@freebsd.org Subject: Re: [Solicite review for KAME 3rd patch] Message-ID: <19991220135351.A10996@hub.freebsd.org> Reply-To: obrien@freebsd.org References: <19991206195341.B11220@daemon.ninth-circle.org> <199912090651.IAA95501@zibbi.mikom.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199912090651.IAA95501@zibbi.mikom.csir.co.za>; from John Hay on Thu, Dec 09, 1999 at 08:51:38AM +0200 X-Operating-System: FreeBSD 3.3-RC 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 Thu, Dec 09, 1999 at 08:51:38AM +0200, John Hay wrote: > > Well, a make world shouldn't be dying from lack of specifying INET6. I > > wonder how to best tackle this problem. I mean, we want IPv6 support to > > be there when we want it, and not there when we don't. Ideas of how to > > solve this small kludge are welcome. > > > > My suggestion would be to always enable IPv6 support in the userlevel > programs. No! ``netstat -rn'' is now useless on a console terminal. The whole -DINET6 stuff needs to be moved to /etc/make.conf. At the moment there is now way for me to turn the IPV6 userland stuff off easily. Alternately, the output formatting could be changed, but ``ifconfig -rn'' needs to be neatly readble on an 80 column display. We cater to the server market, where a large number of machines run headless on console servers. > The same is done with IPX. Ifconfig, netstat and those programs are > always compiled with IPX support even if you don't have IPX in the > kernel. Including IPX support didn't fsck up the output of ``netstat -rn''. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 20 23: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 E4D2E153C8 for ; Mon, 20 Dec 1999 23:49: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 IAA07257 for ; Tue, 21 Dec 1999 08:49:41 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA24335 for freebsd-arch@freebsd.org; Tue, 21 Dec 1999 08:49:40 +0100 (MET) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 9685814E6B for ; Mon, 20 Dec 1999 23:49:29 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id XAA14707; Mon, 20 Dec 1999 23:51:18 -0800 Date: Mon, 20 Dec 1999 23:51:18 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: "Rodney W. Grimes" Cc: freebsd-arch@freebsd.org, Stephen McKay , Greg Lehey , Bob Bishop , Thomas David Rivers , Joerg Wunsch , Hauke Fath Subject: Re: filemarks? In-Reply-To: <199912210729.XAA45172@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 [ this is a thread moved from scsi to -arch at the request of a couple of people. I proposed (revisited) some tape EOM handling changes. The latest proposal I had worked out to: Write Behaviour near End of Media A user application detects EARLY WARNING during writing by getting a return from the write(2) system call of zero (zero bytes were written). If the device open is the non-rewinding tape device, the application may close and reopen it and continue writing until physical end of medium (EOT) is reached, whereupon a value of -1 is returned from the write(2) system call and the system error is set to ENOSPC. A filemark will be written in the usual manner if EARLY WARNING is detected and the application closes the tape device at that point. It is unlikely that filemark(s) can be written after physical EOT is detected. If the user applications does not close the device and continues to attempt to write after EARLY WARNING notification, a value of -1 will be returned with the system error set to ENOSPC. Some tape devices may be configured such that they do not report EARLY WARNING, in which case the physical EOT notification as described above will occur first. If a user application writes to EARLY WARNING, closes and rewinds the tape device, and later reopens it and seeks to the end of recorded media and starts writing again, EARLY WARNING detection may or may not be defeated, in which case physical EOT notification will occur as described above. If the tape device is set in fixed block mode, EARLY WARNING may or may not be able to be successfully detected and signified to the user application as described above. John Polstra is proposing using signals to signify EARLY WARNING. Rodney has responded with the mail below. This is all archived in mailling lists... ] > The API has a perfectly acceptable and working mechanism to deal with > this. > > RETURN VALUES > Upon successful completion the number of bytes which were written is re- > turned. Otherwise a -1 is returned and the global variable errno is set > to indicate the error. > > We seem to have 3 cases when Early Warning is detected: > > a) The write(2) completed, all data has been written to the tape. Here > by definition we should simply return nbytes, after all, nothing is > wrong at this point, all the data did make it onto the tape. The > driver layer should set a flag at this point noting that Early Warning > has been seen but not delivered to the consumer. This flag will be > delivered by c) below, since the driver layer knows not to try and > put any more data on the tape. > > b) The write(2) was not completed, some bytes did make it to the tape. > If _some_ bytes made it we should return how many did and set the > Early Warning flag as in a). If no bytes made it we return 0, which > is a degenerative case, no quite covered by the definition of > RETURN VALUE but in wide usage. > > c) The write(2) was not able to put any data on the tape. Return -1, NOSPC. > > > Whats wrong with this model? The user application cannot distinguish EARLY WARNING from hard EOT directly. You can put more data on tape after EARLY WARNING and before hard EOT. But the model I'm proposing continues to doesn't use -1, and allows the application to continue to write past EARLY WARNING should it choose to do so. That's my primary concern for writes. If it's that important for everyone, it could all be a -1 indication, but something has to signify the difference between EARLY WARNING and hard EOT. John wants signals- that seems a bit much- particularly if it overlaps usage in and/or kills off the unaware user application. Read behaviour wrt double filemarks I've also stated (and I'll restate for the -arch audience) (yes, I was shot down about this a while ago, but there are a bunch of us folks who actually use modern tape devices who don't much like the way things are) [ From previous mail: ] ---------- A user application detects a filemark by getting a return from a read(2) of less than the nbytes argument to the read(2) system call.* A user application detects EOD by getting at least two read(2) system calls in a row returing a value of zero (indicating no data transferred).* A user application detects an error by getting a value of -1 returned from the read(2) system call. The system error will contain EIO indicating an I/O error or some other value indicating why the operation could not occur. If EIO is returned, tape position has been lost and the application must either close the device (for an automatic rewind if the rewinding device was opened), specifically rewind or offline the device, or issue an MTEOM MTIOCTOP ioctl, or leave these actions for another application to perform. The '*' points above may require some condition synthesis by the driver, but not to as complex a level as some systems. For example, BLANK CHECKs during read would not return -1 (just indicate a zero length read return). --- -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 21 0: 0: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 97709153C8 for ; Tue, 21 Dec 1999 00:00: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 JAA07410 for ; Tue, 21 Dec 1999 09:00:13 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id JAA24385 for freebsd-arch@freebsd.org; Tue, 21 Dec 1999 09:00:12 +0100 (MET) Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 32AC914D0B for ; Tue, 21 Dec 1999 00:00:02 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id XAA45289; Mon, 20 Dec 1999 23:59:56 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199912210759.XAA45289@gndrsh.dnsmgr.net> Subject: Re: filemarks? In-Reply-To: from Matthew Jacob at "Dec 20, 1999 11:51:18 pm" To: mjacob@feral.com Date: Mon, 20 Dec 1999 23:59:56 -0800 (PST) Cc: freebsd-arch@freebsd.org, syssgm@detir.qld.gov.au (Stephen McKay), grog@lemis.com (Greg Lehey), rb@gid.co.uk (Bob Bishop), rivers@dignus.com (Thomas David Rivers), joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), hf@Melog.DE (Hauke Fath) 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 ... > Write Behaviour near End of Media > > A user application detects EARLY WARNING during writing by > getting a return from the write(2) system call of zero ... [My model deleted along with lots of other stuff] > > > > Whats wrong with this model? > > The user application cannot distinguish EARLY WARNING from hard EOT directly. > You can put more data on tape after EARLY WARNING and before hard EOT. Trying to put any more data on tape after EARLY WARNING will make your tapes _extreamly_ non-portable. Infact doing anthing more than either writting filemarks, or bsr and filemarks will make your tape(s) unreadable on most systems out there. I think this is covered in one of the ANSI specs, but can't find a reference handy :-(. I do know from first hand work with things like VMS Backup that the SOP on early warning is, bsr, weof, weof, rewind. And in every tape application I have ever worked on that handled multivolumes on just about any tape drive accross any system this was what _had_ to happen to make it work, independent of tape drive type (9-track, mega-tape, QIC, 8mm, dat). Only applications intimately familiar with the tape drive they are working with should ever try to count on data being correct past Early Warning, independent of if you are reading or writing. -- 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 Tue Dec 21 0: 3: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 2043E14FA1 for ; Tue, 21 Dec 1999 00:03: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 JAA07469 for ; Tue, 21 Dec 1999 09:03:14 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id JAA24419 for freebsd-arch@freebsd.org; Tue, 21 Dec 1999 09:03:14 +0100 (MET) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 0B047153E5 for ; Tue, 21 Dec 1999 00:03:07 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id AAA14752; Tue, 21 Dec 1999 00:04:56 -0800 Date: Tue, 21 Dec 1999 00:04:56 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: "Rodney W. Grimes" Cc: freebsd-arch@freebsd.org, Stephen McKay , Greg Lehey , Bob Bishop , Thomas David Rivers , Joerg Wunsch , Hauke Fath Subject: Re: filemarks? In-Reply-To: <199912210759.XAA45289@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 > Trying to put any more data on tape after EARLY WARNING will make your > tapes _extreamly_ non-portable. Infact doing anthing more than either > writting filemarks, or bsr and filemarks will make your tape(s) unreadable > on most systems out there. > > I think this is covered in one of the ANSI specs, but can't find a reference > handy :-(. > > I do know from first hand work with things like VMS Backup that the SOP > on early warning is, bsr, weof, weof, rewind. And in every tape application > I have ever worked on that handled multivolumes on just about any tape > drive accross any system this was what _had_ to happen to make it work, > independent of tape drive type (9-track, mega-tape, QIC, 8mm, dat). > > Only applications intimately familiar with the tape drive they are working > with should ever try to count on data being correct past Early Warning, > independent of if you are reading or writing. Okay. How about commenting on the 'read' side again? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 21 0:24: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 4864B14EC5 for ; Tue, 21 Dec 1999 00:24: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 JAA07771 for ; Tue, 21 Dec 1999 09:24:17 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id JAA24521 for freebsd-arch@freebsd.org; Tue, 21 Dec 1999 09:24:17 +0100 (MET) Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by hub.freebsd.org (Postfix) with ESMTP id 59EDE1554A for ; Tue, 21 Dec 1999 00:22:29 -0800 (PST) (envelope-from rb@gid.co.uk) Received: from gid.co.uk (uucp@localhost) by isbalham.ist.co.uk (8.9.2/8.8.7) with UUCP id IAA72968; Tue, 21 Dec 1999 08:20:29 GMT (envelope-from rb@gid.co.uk) Received: from [194.32.164.2] by seagoon.gid.co.uk; Tue, 21 Dec 1999 08:18:42 GMT X-Sender: rb@194.32.164.1 Message-Id: In-Reply-To: References: <199912210729.XAA45172@gndrsh.dnsmgr.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 21 Dec 1999 08:18:40 +0000 To: mjacob@feral.com From: Bob Bishop Subject: Re: filemarks? Cc: "Rodney W. Grimes" , freebsd-arch@freebsd.org, Stephen McKay , Greg Lehey , Thomas David Rivers , Joerg Wunsch , Hauke Fath Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 11:51 pm -0800 20/12/99, Matthew Jacob wrote: >[...] Rodney >has responded with the mail below. This is all archived in mailling >lists... ] > > >> The API has a perfectly acceptable and working mechanism to deal with >> this. >> [Rod's proposal] >> >> Whats wrong with this model? > >The user application cannot distinguish EARLY WARNING from hard EOT directly. >You can put more data on tape after EARLY WARNING and before hard EOT. I'm not sure you can, in general [because not all drives will give you sufficient warning]. The best you can guarantee is that closing the device at this point will leave the tape in a state where a subsequent reader won't get confused. -- Bob Bishop (0118) 977 4017 international code +44 118 rb@gid.co.uk fax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 21 0:26: 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 40A6D14D9D for ; Tue, 21 Dec 1999 00:25: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 JAA07805 for ; Tue, 21 Dec 1999 09:25:50 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id JAA24551 for freebsd-arch@freebsd.org; Tue, 21 Dec 1999 09:25:49 +0100 (MET) Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (Postfix) with ESMTP id 4D46E14F7D; Tue, 21 Dec 1999 00:25:36 -0800 (PST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.10.0.Beta6/8.10.0.Beta6) with ESMTP id dBL8PR304494; Tue, 21 Dec 1999 10:25:27 +0200 (SAST) Message-Id: <199912210825.dBL8PR304494@gratis.grondar.za> To: obrien@freebsd.org Cc: Yoshinobu Inoue , John Hay , freebsd-arch@freebsd.org, cvs-committers@freebsd.org Subject: Re: [Solicite review for KAME 3rd patch] Date: Tue, 21 Dec 1999 10:25:26 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Alternately, the output formatting could be changed, but ``ifconfig -rn'' > needs to be neatly readble on an 80 column display. We cater to the > server market, where a large number of machines run headless on console > servers. Is there a way of finding out if the kernel in use is using IPv6? If so, then the output should be conditional upon that, defaulting to "old" behaviour. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 21 0:34: 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 6362014F31 for ; Tue, 21 Dec 1999 00:33:58 -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 JAA07963 for ; Tue, 21 Dec 1999 09:33:56 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id JAA24632 for freebsd-arch@freebsd.org; Tue, 21 Dec 1999 09:33:56 +0100 (MET) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 218B914F31 for ; Tue, 21 Dec 1999 00:33:50 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id AAA14972; Tue, 21 Dec 1999 00:35:31 -0800 Date: Tue, 21 Dec 1999 00:35:31 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Bob Bishop Cc: "Rodney W. Grimes" , freebsd-arch@freebsd.org, Stephen McKay , Greg Lehey , Thomas David Rivers , Joerg Wunsch , Hauke Fath Subject: Re: filemarks? 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 > >> Whats wrong with this model? > > > >The user application cannot distinguish EARLY WARNING from hard EOT directly. > >You can put more data on tape after EARLY WARNING and before hard EOT. > > I'm not sure you can, in general [because not all drives will give you > sufficient warning]. The best you can guarantee is that closing the device > at this point will leave the tape in a state where a subsequent reader > won't get confused. EARLY WARNING is actually configurable for most SCSI drives. If you don't get EARLY WARNING (which is the EOM bit in sense data) associated with a plain old UNIT ATTENCTION sense key, you'll get a VOLUME OVERFLOW sense key (hard EOT). As far as I know you usually don't get EARLY WARNING detection on reads for these drives- this only happens on writes- I don't have my specs handy or I'd go back and make sure of this. The way I was specifying this is that subsequent reads aren't confused by this at all. If you miss EARLY WARNING (say the drive isn't strapped for it), you get VOLUME OVERFLOW (hard EOT) anyway on writes. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 21 0:38: 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 9C1A514F7D for ; Tue, 21 Dec 1999 00:38: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 JAA08046 for ; Tue, 21 Dec 1999 09:38:05 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id JAA24692 for freebsd-arch@freebsd.org; Tue, 21 Dec 1999 09:38:05 +0100 (MET) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id D018A15392 for ; Tue, 21 Dec 1999 00:37:57 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id AAA14996; Tue, 21 Dec 1999 00:39:41 -0800 Date: Tue, 21 Dec 1999 00:39:41 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Bob Bishop Cc: "Rodney W. Grimes" , freebsd-arch@freebsd.org, Stephen McKay , Greg Lehey , Thomas David Rivers , Joerg Wunsch , Hauke Fath Subject: Re: filemarks? 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, I'm tired- let me restate this ]: > > EARLY WARNING is actually configurable for most SCSI drives. If you don't > get EARLY WARNING (which is the EOM bit in sense data) associated with a > plain old UNIT ATTENCTION sense key, you'll get a VOLUME OVERFLOW sense > key (hard EOT). As far as I know you usually don't get EARLY WARNING > detection on reads for these drives- this only happens on writes- I don't > have my specs handy or I'd go back and make sure of this. This should read: EARLY WARNING is actually configurable for most SCSI drives. If you don't get EARLY WARNING (which is the EOM bit in sense data) associated with a plain old UNIT ATTENCTION sense key, you'll *still* get a VOLUME OVERFLOW sense key when you hit hard EOT. As far as I know you usually don't get EARLY WARNINGdetection on reads for these drives- this only happens on writes- I don't have my specs handy or I'd go back and make sure of this. > > The way I was specifying this is that subsequent reads aren't confused by > this at all. If you miss EARLY WARNING (say the drive isn't strapped for > it), you get VOLUME OVERFLOW (hard EOT) anyway on writes. > > -matt > > > > > > > > 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 Tue Dec 21 0:50: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 4A5E0153E3 for ; Tue, 21 Dec 1999 00:50: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 JAA08381 for ; Tue, 21 Dec 1999 09:50:35 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id JAA24820 for freebsd-arch@freebsd.org; Tue, 21 Dec 1999 09:50:34 +0100 (MET) Received: from orange.kame.net (orange.kame.net [203.178.141.194]) by hub.freebsd.org (Postfix) with ESMTP id A9B9D153FE; Tue, 21 Dec 1999 00:50:11 -0800 (PST) (envelope-from shin@nd.net.fujitsu.co.jp) Received: from localhost (kame209.kame.net [203.178.141.209]) by orange.kame.net (8.9.1+3.1W/3.7W/smtpfeed 0.89) with ESMTP id RAA25547; Tue, 21 Dec 1999 17:49:41 +0900 (JST) To: mark@grondar.za Cc: obrien@freebsd.org, jhay@mikom.csir.co.za, freebsd-arch@freebsd.org, cvs-committers@freebsd.org Subject: Re: [Solicite review for KAME 3rd patch] In-Reply-To: <199912210825.dBL8PR304494@gratis.grondar.za> References: <199912210825.dBL8PR304494@gratis.grondar.za> 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: <19991221175036F.shin@nd.net.fujitsu.co.jp> Date: Tue, 21 Dec 1999 17:50:36 +0900 From: Yoshinobu Inoue X-Dispatcher: imput version 990905(IM130) Lines: 106 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Alternately, the output formatting could be changed, but ``ifconfig -rn'' > > needs to be neatly readble on an 80 column display. We cater to the > > server market, where a large number of machines run headless on console > > servers. > > Is there a way of finding out if the kernel in use is using IPv6? > If so, then the output should be conditional upon that, defaulting to > "old" behaviour. I think it can be checked by, socket(PF_INET6, SOCK_DGRAM, 0) etc, but in this case I think following diff to netstat/route.c will resolve the issue. Please give me comments and if it seems to be OK, I'll commit it. Yoshinobu Inoue Index: route.c =================================================================== RCS file: /home/ncvs/src/usr.bin/netstat/route.c,v retrieving revision 1.37 diff -u -r1.37 route.c --- route.c 1999/12/07 17:38:57 1.37 +++ route.c 1999/12/21 08:48:57 @@ -166,7 +166,7 @@ } else if (af == AF_UNSPEC || af == i) { pr_family(i); do_rtent = 1; - pr_rthdr(); + pr_rthdr(i); p_tree(head.rnh_treetop); } } @@ -222,31 +222,43 @@ } /* column widths; each followed by one space */ -#ifndef INET6 #define WID_DST 18 /* width of destination column */ #define WID_GW 18 /* width of gateway column */ -#else -#define WID_DST (lflag ? 39 : (nflag ? 33: 18)) /* width of dest column */ -#define WID_GW (lflag ? 31 : (nflag ? 29 : 18)) /* width of gateway column */ +#ifdef INET6 +#define WID_DST6 (lflag ? 39 : (nflag ? 33: 18)) /* width of dest column */ +#define WID_GW6 (lflag ? 31 : (nflag ? 29 : 18)) /* width of gateway column */ #endif /*INET6*/ /* * Print header for routing table columns. */ void -pr_rthdr() +pr_rthdr(af) { + int wid_dst, wid_gw; + + wid_dst = +#ifdef INET6 + af == AF_INET6 ? WID_DST6 : +#endif + WID_DST; + wid_gw = +#ifdef INET6 + af == AF_INET6 ? WID_GW6 : +#endif + WID_GW; + if (Aflag) printf("%-8.8s ","Address"); if (lflag) printf("%-*.*s %-*.*s %-6.6s %6.6s%8.8s %8.8s %6s\n", - WID_DST, WID_DST, "Destination", - WID_GW, WID_GW, "Gateway", + wid_dst, wid_dst, "Destination", + wid_gw, wid_gw, "Gateway", "Flags", "Refs", "Use", "Netif", "Expire"); else printf("%-*.*s %-*.*s %-6.6s %8.8s %6s\n", - WID_DST, WID_DST, "Destination", - WID_GW, WID_GW, "Gateway", + wid_dst, wid_dst, "Destination", + wid_gw, wid_gw, "Gateway", "Flags", "Netif", "Expire"); } @@ -585,8 +597,16 @@ bzero(&mask, sizeof(mask)); if (rt_mask(rt) && (sa = kgetsa(rt_mask(rt)))) bcopy(sa, &mask, sa->sa_len); - p_sockaddr(&addr.u_sa, &mask.u_sa, rt->rt_flags, WID_DST); - p_sockaddr(kgetsa(rt->rt_gateway), NULL, RTF_HOST, WID_GW); + p_sockaddr(&addr.u_sa, &mask.u_sa, rt->rt_flags, +#ifdef INET6 + addr.u_sa.sa_family == AF_INET6 ? WID_DST6 : +#endif + WID_DST); + p_sockaddr(kgetsa(rt->rt_gateway), NULL, RTF_HOST, +#ifdef INET6 + kgetsa(rt->rt_gateway)->sa_family == AF_INET6 ? WID_GW6 : +#endif + WID_GW); p_flags(rt->rt_flags, "%-6.6s "); if (lflag) printf("%6ld %8ld ", rt->rt_refcnt, rt->rt_use); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 21 1:11: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 55D7114EA5 for ; Tue, 21 Dec 1999 01:11: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 KAA08811 for ; Tue, 21 Dec 1999 10:11:51 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id KAA24925 for freebsd-arch@freebsd.org; Tue, 21 Dec 1999 10:11:50 +0100 (MET) Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (Postfix) with ESMTP id DF92015423; Tue, 21 Dec 1999 01:11:04 -0800 (PST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.10.0.Beta6/8.10.0.Beta6) with ESMTP id dBL9Ap304789; Tue, 21 Dec 1999 11:10:51 +0200 (SAST) Message-Id: <199912210910.dBL9Ap304789@gratis.grondar.za> To: Yoshinobu Inoue Cc: obrien@freebsd.org, jhay@mikom.csir.co.za, freebsd-arch@freebsd.org, cvs-committers@freebsd.org Subject: Re: [Solicite review for KAME 3rd patch] Date: Tue, 21 Dec 1999 11:10:51 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I think it can be checked by, socket(PF_INET6, SOCK_DGRAM, 0) etc, > but in this case I think following diff to netstat/route.c > will resolve the issue. Please give me comments and if it > seems to be OK, I'll commit it. > > Yoshinobu Inoue > > Index: route.c Well, it didn't break anything :-). I am running an IPv6 enabled kernel but I have nowhere to route to, so testing properly is a bit difficult. Seems OK otherwise... M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 21 1: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 0DA561502D for ; Tue, 21 Dec 1999 01: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 KAA09202 for ; Tue, 21 Dec 1999 10:35:27 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id KAA25041 for freebsd-arch@freebsd.org; Tue, 21 Dec 1999 10:35:27 +0100 (MET) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 6B64B15063 for ; Tue, 21 Dec 1999 01:35:17 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (beefcake.zeta.org.au [203.26.10.12]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id UAA32248; Tue, 21 Dec 1999 20:34:50 +1100 Date: Tue, 21 Dec 1999 20:34:32 +1100 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Matthew Jacob Cc: "Rodney W. Grimes" , freebsd-arch@freebsd.org, Stephen McKay , Greg Lehey , Bob Bishop , Thomas David Rivers , Joerg Wunsch , Hauke Fath Subject: Re: filemarks? 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, 20 Dec 1999, Matthew Jacob wrote: > Write Behaviour near End of Media > > A user application detects EARLY WARNING during writing by > getting a return from the write(2) system call of zero > (zero bytes were written). If the device open is the I think this stretches the POSIX API too far. [write() shall attempt to write the amount given, and return -1/ENOSPC if there is no space.] Only a very feeble attempt would successfully write 0 bytes when there is some space. > non-rewinding tape device, the application may close and > reopen it and continue writing until physical end of medium > (EOT) is reached, whereupon a value of -1 is returned from > the write(2) system call and the system error is set to > ENOSPC. A filemark will be written in the usual manner if > EARLY WARNING is detected and the application closes the > tape device at that point. It is unlikely that filemark(s) > can be written after physical EOT is detected. If the user > applications does not close the device and continues to > attempt to write after EARLY WARNING notification, a value > of -1 will be returned with the system error set to ENOSPC. This amounts to pretending that the device is smaller than it is. Reverting to POSIX behaviour (returning a short count, then -1/ENOSPC) would be just as good for programs that don't understand EARLY_WARNING. > Some tape devices may be configured such that they do not > report EARLY WARNING, in which case the physical EOT > notification as described above will occur first. > > If a user application writes to EARLY WARNING, closes and > rewinds the tape device, and later reopens it and seeks to > the end of recorded media and starts writing again, EARLY > WARNING detection may or may not be defeated, in which case > physical EOT notification will occur as described above. > > If the tape device is set in fixed block mode, EARLY WARNING > may or may not be able to be successfully detected and > signified to the user application as described above. > > John Polstra is proposing using signals to signify EARLY WARNING. Rodney I don't think signals are appropriate here. > has responded with the mail below. This is all archived in mailling > lists... ] > > > The API has a perfectly acceptable and working mechanism to deal with > > this. > > > > RETURN VALUES > > Upon successful completion the number of bytes which were written is re- > > turned. Otherwise a -1 is returned and the global variable errno is set > > to indicate the error. Before trying anything new, you should try fixing the longstanding Free(?)BSD bug of not actually implementing this API. Short counts are rarely returned for writes to devices. Instead, an error is returned and the (short) amount written is forgotten :-(. This is because most drivers return short writes as an error, with the amount written in (original auio.uio_resid) - (auio.uio_resid), and the sys_generic.c level only converts the error to a non-error if the amount written is nonzero when the error is ERESTART, EINTR or EWOULDBLOCK. There are similar problems with error handling for reads. There are related but different problems for writes to full filesystems. > > We seem to have 3 cases when Early Warning is detected: > > ... > > b) The write(2) was not completed, some bytes did make it to the tape. > > If _some_ bytes made it we should return how many did and set the > > Early Warning flag as in a). If no bytes made it we return 0, which > > is a degenerative case, no quite covered by the definition of > > RETURN VALUE but in wide usage. This is in narrow or nonexistent usage. POSIX requires returning -1/ENOSPC if "there is no space on the device". The only reasonable interpretation of a return value of 0 is that there is some space, but not this time. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 21 2:17: 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 28E5B153A3 for ; Tue, 21 Dec 1999 02:16: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 LAA11444 for ; Tue, 21 Dec 1999 11:16:54 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id LAA25195 for freebsd-arch@freebsd.org; Tue, 21 Dec 1999 11:16:54 +0100 (MET) Received: from ren.detir.qld.gov.au (ns.detir.qld.gov.au [203.46.81.66]) by hub.freebsd.org (Postfix) with ESMTP id 21EDA153B7 for ; Tue, 21 Dec 1999 02:16:19 -0800 (PST) (envelope-from syssgm@detir.qld.gov.au) Received: by ren.detir.qld.gov.au; id UAA07540; Tue, 21 Dec 1999 20:14:33 +1000 (EST) Received: from ogre.detir.qld.gov.au(167.123.8.3) via SMTP by ren.detir.qld.gov.au, id smtpd007538; Tue Dec 21 20:14:25 1999 Received: from atlas.detir.qld.gov.au (atlas.detir.qld.gov.au [167.123.8.9]) by ogre.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id UAA00353; Tue, 21 Dec 1999 20:14:25 +1000 (EST) Received: from nymph.detir.qld.gov.au (nymph.detir.qld.gov.au [167.123.10.10]) by atlas.detir.qld.gov.au (8.8.5/8.8.5) with ESMTP id UAA26883; Tue, 21 Dec 1999 20:14:24 +1000 (EST) Received: from nymph.detir.qld.gov.au (localhost [127.0.0.1]) by nymph.detir.qld.gov.au (8.9.3/8.8.7) with ESMTP id UAA21880; Tue, 21 Dec 1999 20:14:23 +1000 (EST) (envelope-from syssgm@nymph.detir.qld.gov.au) Message-Id: <199912211014.UAA21880@nymph.detir.qld.gov.au> To: Bruce Evans Cc: Matthew Jacob , "Rodney W. Grimes" , freebsd-arch@freebsd.org, Greg Lehey , Bob Bishop , Thomas David Rivers , Joerg Wunsch , Hauke Fath , syssgm@detir.qld.gov.au Subject: Re: filemarks? References: In-Reply-To: from Bruce Evans at "Tue, 21 Dec 1999 20:34:32 +1100" Date: Tue, 21 Dec 1999 20:14:22 +1000 From: Stephen McKay Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, 21st December 1999, Bruce Evans wrote: >> > b) The write(2) was not completed, some bytes did make it to the tape. >> > If _some_ bytes made it we should return how many did and set the >> > Early Warning flag as in a). If no bytes made it we return 0, which >> > is a degenerative case, no quite covered by the definition of >> > RETURN VALUE but in wide usage. > >This is in narrow or nonexistent usage. POSIX requires returning -1/ENOSPC >if "there is no space on the device". The only reasonable interpretation >of a return value of 0 is that there is some space, but not this time. That looks fine to me, though I don't consider slavish POSIX adherence necessary. The model I'm proposing is slightly different to everyone else's (of course), and alternates "return 0" and "normal write" after the early warning mark until physical end of media is hit, then "return -1" with errno = ENOSPC (even though I think a few Unices get by with EIO). Thus, 0 means "there is some space, but not this time". :-) We should consider the nature of programs that will write to tape. How should "cat" work when writing a tape? I expect it would write until physical end of media with this model and run the 1/2" tape right off the reel. That would be fine by me since "cat" is not a normal tape writing program. For modern tapes even "cat" will stop at the physical end of tape. Does anyone have evidence that writing like this would corrupt the last block, or be otherwise unreadable, even on different OSes? So far, Rod has suggested that problems could exist here. I'd like firm details. I can only test on FreeBSD and Solaris/Sparc. Normal tape programs probably already recognise the end of media detection methods we are considering, and probably work with all of them. In particular my reading of dump and tar suggests that they will work with my formula, with Matt's, and with Rod's, as they accept -1/ENOSPC, partial write, and zero length write as signals to stop. Looks like dd already supports this stuff too. I expect that the only proposed model with no current support in the tree is John's. I don't like the idea of signals in this context. Are there any more models, to confuse the situation further? :-) By the way, I don't recall any disagreement about reading filemarks. (Physically write 2 filemarks only on 1/2" tape, but simulate 2 on everything else.) Is this part now settled? Stephen. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 21 4:10: 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 462311534E for ; Tue, 21 Dec 1999 04:09:58 -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 NAA16996 for ; Tue, 21 Dec 1999 13:09:56 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA25608 for freebsd-arch@freebsd.org; Tue, 21 Dec 1999 13:09:54 +0100 (MET) Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id D9B7B1528B for ; Tue, 21 Dec 1999 04:09:43 -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 EAA29537 for ; Tue, 21 Dec 1999 04:41:33 -0800 (PST) Date: Tue, 21 Dec 1999 04:41:33 -0800 (PST) From: Alfred Perlstein To: arch@freebsd.org Subject: interface ideas for async locks? 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 gotten started on making async fcntl locks possible, the trick is giving preference to async locks and having lock reservations put up by the process that 'unblocks' the async lock. Anyhow, the reason for this mail is to get an idea of what type of interface people would like for this feature. Right now the way I have envisioned it is: process makes a lock request 'F_GETLKA', if the lock is aquired immediatly then success is returned, if not it errors out and sets errno to EINPROGRESS. later when the lock becomes available SIGIO will be posted to the process that put the lock up, the process can then call a syscall that will attempt to give them the actual lock. getasynclocks(int n, struct flock *fl), The program would pass in a number indicating the size of the flock array, then the system would loop attempting to grant those locks and copy in the data for each lock into the flock array. the syscall would return the number of locks granted. Can anyone think of a nicer interface? thanks, -Alfred Perlstein - [bright@rush.net|alfred@freebsd.org] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [bright@wintelcom.net] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 21 9: 3:59 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 5DA8E14F28 for ; Tue, 21 Dec 1999 09:03: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 SAA22443 for ; Tue, 21 Dec 1999 18:03:51 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA27375 for freebsd-arch@freebsd.org; Tue, 21 Dec 1999 18:03:51 +0100 (MET) Received: from gidgate.gid.co.uk (gidgate.gid.co.uk [193.123.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 18D7C14F28 for ; Tue, 21 Dec 1999 09:03:35 -0800 (PST) (envelope-from rb@gid.co.uk) Received: (from rb@localhost) by gidgate.gid.co.uk (8.8.8/8.8.7) id QAA21135; Tue, 21 Dec 1999 16:57:48 GMT (envelope-from rb) Message-Id: <3.0.6.32.19991221165541.007b7480@192.168.255.1> X-Sender: rbmail@192.168.255.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 21 Dec 1999 16:55:41 +0000 To: Stephen McKay , Bruce Evans From: Bob Bishop Subject: Re: filemarks? Cc: Matthew Jacob , "Rodney W. Grimes" , freebsd-arch@freebsd.org, Greg Lehey , Thomas David Rivers , Joerg Wunsch , Hauke Fath , syssgm@detir.qld.gov.au In-Reply-To: <199912211014.UAA21880@nymph.detir.qld.gov.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 08:14 PM 12/21/99 +1000, Stephen McKay wrote: >[...] >We should consider the nature of programs that will write to tape. How >should "cat" work when writing a tape? I expect it would write until >physical end of media with this model and run the 1/2" tape right off the >reel. That would be fine by me since "cat" is not a normal tape writing >program. On 1/2" tape, EOT was a reflective marker on the back of the tape. You were supposed to have something like 30ft of tape after the marker, at least 10ft of which had to be writeable. So the drive could complete the block being written at EOT, and still write two tape marks thereafter (but data writes would fail IIRC). Only a broken drive (not unknown) would let you run the tape off the reel. ISTR (and you will appreciate this is a while ago) that drivers would return the block size for the block written over EOT and zero for any subsequent data write attempt. Closing the file wrote two tape marks. -- Bob Bishop +44 118 977 4017 rb@gid.co.uk fax +44 118 989 4254 (0800-1800 UK) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 21 10:30: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 AE2751501E for ; Tue, 21 Dec 1999 10:30:09 -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 TAA23385 for ; Tue, 21 Dec 1999 19:30:05 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA28003 for freebsd-arch@freebsd.org; Tue, 21 Dec 1999 19:30:04 +0100 (MET) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id 6F18114C45 for ; Tue, 21 Dec 1999 10:28:57 -0800 (PST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.9.3/8.9.3) id MAA72040; Tue, 21 Dec 1999 12:27:57 -0600 (CST) (envelope-from dan) Date: Tue, 21 Dec 1999 12:27:57 -0600 From: Dan Nelson To: Bob Bishop Cc: Stephen McKay , Bruce Evans , Matthew Jacob , "Rodney W. Grimes" , freebsd-arch@freebsd.org, Greg Lehey , Thomas David Rivers , Joerg Wunsch , Hauke Fath Subject: Re: filemarks? Message-ID: <19991221122757.A71773@dan.emsphone.com> References: <199912211014.UAA21880@nymph.detir.qld.gov.au> <3.0.6.32.19991221165541.007b7480@192.168.255.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3.0.6.32.19991221165541.007b7480@192.168.255.1>; from "Bob Bishop" on Tue Dec 21 16:55:41 GMT 1999 X-OS: FreeBSD 4.0-CURRENT Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Dec 21), Bob Bishop said: > On 1/2" tape, EOT was a reflective marker on the back of the tape. Still is :) We still process a couple dozen 9-track tapes a day here at work (3490s are getting more common), and have a lot of those sticky silver tabs lying around. > You were supposed to have something like 30ft of tape after the > marker, at least 10ft of which had to be writeable. So the drive > could complete the block being written at EOT, and still write two > tape marks thereafter (but data writes would fail IIRC). Only a > broken drive (not unknown) would let you run the tape off the reel. > ISTR (and you will appreciate this is a while ago) that drivers would > return the block size for the block written over EOT and zero for any > subsequent data write attempt. Closing the file wrote two tape marks. The documentation I have seen for my 6250 9-track drives implied that the warning marker meant you had room for the trailer on a standard-label tape, but you should really back up a few blocks before writing filemark + trailer + filemark anyway. I know when I wrote my tape program I could reliably write three or four 32k blocks after soft EOT before unspooling the reel :) -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 21 10:35: 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 A657914EA5 for ; Tue, 21 Dec 1999 10:35: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 TAA23439 for ; Tue, 21 Dec 1999 19:35:05 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA28037 for freebsd-arch@freebsd.org; Tue, 21 Dec 1999 19:35:05 +0100 (MET) Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 6859E14E58 for ; Tue, 21 Dec 1999 10:34:58 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id KAA46534; Tue, 21 Dec 1999 10:34:48 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199912211834.KAA46534@gndrsh.dnsmgr.net> Subject: Re: filemarks? In-Reply-To: from Bruce Evans at "Dec 21, 1999 08:34:32 pm" To: bde@zeta.org.au (Bruce Evans) Date: Tue, 21 Dec 1999 10:34:48 -0800 (PST) Cc: mjacob@feral.com (Matthew Jacob), freebsd-arch@freebsd.org, syssgm@detir.qld.gov.au (Stephen McKay), grog@lemis.com (Greg Lehey), rb@gid.co.uk (Bob Bishop), rivers@dignus.com (Thomas David Rivers), joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), hf@Melog.DE (Hauke Fath) 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 ... > > > We seem to have 3 cases when Early Warning is detected: > > > ... > > > > b) The write(2) was not completed, some bytes did make it to the tape. > > > If _some_ bytes made it we should return how many did and set the > > > Early Warning flag as in a). If no bytes made it we return 0, which > > > is a degenerative case, no quite covered by the definition of > > > RETURN VALUE but in wide usage. > > This is in narrow or nonexistent usage. POSIX requires returning -1/ENOSPC > if "there is no space on the device". The only reasonable interpretation > of a return value of 0 is that there is some space, but not this time. AHhh... BSD dump is probably the #1 consumer of the write(2) call with respect to tape drives and: if (wrote == 0) eot_count++; And if I recall my read of the amanda tape driver code it does the exact same thing. I would say that is not ``narrow or nonexistent''. -- 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 Dec 22 0:16: 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 4BB1714D66 for ; Wed, 22 Dec 1999 00:16: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 JAA00447 for ; Wed, 22 Dec 1999 09:15:46 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id JAA31293 for freebsd-arch@freebsd.org; Wed, 22 Dec 1999 09:15:45 +0100 (MET) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by hub.freebsd.org (Postfix) with ESMTP id EEF111544C for ; Wed, 22 Dec 1999 00:09:37 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id SAA01430; Wed, 22 Dec 1999 18:39:14 +1030 (CST) Date: Wed, 22 Dec 1999 18:39:14 +1030 From: Greg Lehey To: Bruce Evans Cc: Matthew Jacob , "Rodney W. Grimes" , freebsd-arch@freebsd.org, Stephen McKay , Bob Bishop , Thomas David Rivers , Joerg Wunsch , Hauke Fath Subject: Re: filemarks? Message-ID: <19991222183914.A1316@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0pre2i WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG So much has been said about this subject that I can't work out which statements to quote, so I'll start again. What are we trying to achieve? 1. Get as much data as possible onto a tape. 2. Find a good transition point to subsequent tapes in a tape set. 3. Get it on a tape in such a way that we can reliably read it at a later date, even on a different operating system. 4. Preferably, do it in a way which requires as little special treatment as possible. This means, for example, that we should be able to write one tape full with tools such as dd and cat. What has been proposed? Early warning: If I understand this correctly, early warning can be supplied as a hardware feature. I haven't quite understood what it is good for, but two possibilities are that the software can then decide either not to write the block, to write a short block, or to write one or more tape marks. If we use this feature at all, I think the driver should catch it, not the application program. There are a number of possibilities: 1. Abort the write on early warning and write an EOF mark instead. Return an EOF indication (write count 0). This sounds like the most reliable way: it means we don't have to worry about partial blocks. Any program writing tapes should be prepared to deal with EOF. 2. Write a partial block and return the write count. As bde has pointed out, there are problems in this area. 3. Write the complete block, assuming it's possible, then write an EOF mark. Return success, but note that the tape is at EOF and return EOF next time. Of these three, I like (3) the best and (2) the least. The only problem with (3) is knowing whether we can really write a complete block after getting an early warning. Even if we can at the moment, future devices or increases in the maximum block size may make it impractical. Maybe the best alternative is: 4. Write the complete block, assuming it's possible, then write an EOF mark. Return success, but note that the tape is at EOF and return EOF next time (Case 3). If it's not possible to write the complete block, backspace to the beginning of the block (assuming we found out the hard way that it wasn't possible), then write an EOF mark. Return an EOF indication (write count 0) (Case 1). If the drive doesn't support this function (backspace and write EOT), write an EOT mark there and return the write count (case 2). This sounds complicated, but I suspect that case 3 will almost always apply. Signals: As I said above, I don't think that the user program should be handling the EOF conditions. As a result, signals are superfluous. Single EOF marks: It's been a while since I handled ½" tapes, but my recollection was that a single tape mark at the end of the reel meant "there are more reels to come", and two tape marks meant "there are no more reels to come". I'm prepared to be wrong on this, but if I'm not, we obviously shouldn't be forgetting the second tape mark. Reading: I don't see that this is an issue. We attempt to read as much data as requested. We return an indication of how much we actually read. About the only issue I can think of is whether we should handle the difference between one and two tape marks. Comments? Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 22 0:57: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 294D614F8D for ; Wed, 22 Dec 1999 00:57: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 JAA01042 for ; Wed, 22 Dec 1999 09:57:45 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id JAA31494 for freebsd-arch@freebsd.org; Wed, 22 Dec 1999 09:57:45 +0100 (MET) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 4ACEE150CF for ; Wed, 22 Dec 1999 00:57:36 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id AAA19058; Wed, 22 Dec 1999 00:59:08 -0800 Date: Wed, 22 Dec 1999 00:59:08 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Greg Lehey Cc: Bruce Evans , "Rodney W. Grimes" , freebsd-arch@freebsd.org, Stephen McKay , Bob Bishop , Thomas David Rivers , Joerg Wunsch , Hauke Fath Subject: Re: filemarks? In-Reply-To: <19991222183914.A1316@freebie.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Good summary, Greg, but let me respond... On Wed, 22 Dec 1999, Greg Lehey wrote: > So much has been said about this subject that I can't work out which > statements to quote, so I'll start again. >=20 > What are we trying to achieve? >=20 > 1. Get as much data as possible onto a tape. > 2. Find a good transition point to subsequent tapes in a tape set. > 3. Get it on a tape in such a way that we can reliably read it at a > later date, even on a different operating system. > 4. Preferably, do it in a way which requires as little special > treatment as possible. This means, for example, that we should be > able to write one tape full with tools such as dd and cat. This is a pretty good summary, except I'd add: 5. Minimize the current h/w spasm each time somebody adds a new QIC or TRAVAN-like drive which can't cope with double-filemarks which always has to have them special cased. >=20 > What has been proposed? >=20 > Early warning: >=20 > If I understand this correctly, early warning can be supplied as a > hardware feature. I haven't quite understood what it is good for, > but two possibilities are that the software can then decide either > not to write the block, to write a short block, or to write one or > more tape marks. >=20 > If we use this feature at all, I think the driver should catch it, > not the application program. There are a number of possibilities: >=20 > 1. Abort the write on early warning and write an EOF mark instead. > Return an EOF indication (write count 0). This sounds like the > most reliable way: it means we don't have to worry about partial > blocks. Any program writing tapes should be prepared to deal > with EOF. >=20 > 2. Write a partial block and return the write count. As bde has > pointed out, there are problems in this area. >=20 > 3. Write the complete block, assuming it's possible, then write an > EOF mark. Return success, but note that the tape is at EOF and > return EOF next time. >=20 > Of these three, I like (3) the best and (2) the least. The only > problem with (3) is knowing whether we can really write a complete > block after getting an early warning. Even if we can at the moment, > future devices or increases in the maximum block size may make it > impractical. Maybe the best alternative is: >=20 > 4. Write the complete block, assuming it's possible, then write an > EOF mark. Return success, but note that the tape is at EOF and > return EOF next time (Case 3). =20 >=20 > If it's not possible to write the complete block, backspace to > the beginning of the block (assuming we found out the hard way > that it wasn't possible), then write an EOF mark. Return an EOF > indication (write count 0) (Case 1). >=20 > If the drive doesn't support this function (backspace and write > EOT), write an EOT mark there and return the write count (case > 2). >=20 > This sounds complicated, but I suspect that case 3 will almost > always apply. I'm afraid that none of these are quite right. First of all, EARLY WARNING is what you get when you're writing a tape and a write completes with a CHECK CONDITION and the associated Sense Data says that EOM has been detected (but the Sense Key is not VOLUME OVERFLOW). The residual count you get back with this is independent of the EOM condition. Typically (read this is "Always, except I'm sure there's *some* lameass tape drive out there that doesn't do this") the residual is zero, i.e., the request completed successfully, but at the same time EARLY WARNING is being signified. This truly should be taken to mean that "Yes, the write succeeded, and, oh yes, btw, you might consider doing whatever it is you'd like to do in preparation for switching volumes". This whole furball of a discussion has been about trying to figure out how best to pass the signification of EARLY WARNING back to the user application. In my opinion, any residual count indicating that less than the amount requested was written should be considered either an error or a signification condition by the user application. If the return value to the write system call is -1, that indicates an error. If the return value is zero, it's a signification. Now, in several of the scenarios above you have the driver write a FILEMARK automatically. I don't believe that this is a good idea. The application should drive what should be done here wrt filemarks- this is driven by the application closing the tape device or issuing an ioctl to write filemark(s). If you believe that the driver should solely handle EOF conditions, then the actual current behaviour is close to this. The current behaviour is: =09write has check condition: =09=09If the error an EOM indication =09=09=09if (fixed block mode) =09=09=09=09mark EOM pending =09=09=09else =09=09=09=09mark current transfer failed with ENOSPC (the difference between fixed block and variable block mode is a whole discussion unto itself- suffice to say that the ENOSPC marking is done at the top end in this case). (there's a whole line of issues that have to do with failing a transfer when it actually *succeeded*) My proposed change was (some details left out): =09write has check condition: =09=09If the error an EOM indication =09=09=09mark EOM pending, current transfer biodone as 'OK'. =09Next write is returned indicating zero bytes moved (but no errno =09set- yes there may be some issues in physio, but let's not go down =09that path for now), POST_EARLY_WARNING flagged. =09writes are allowed to continue at the discretion of the user =09application, or the user application may decide to close the =09device (whereupon {a filemark is}/{two filemarks are} written as =09per spec and the selected EOT model for this device and either =09the tape is rewound, or if the no rewind device, it just stays =09there (except for the 2FM model, in which case the 2nd FM is =09backed over- this is all normal stuff)). =09If the application keeps writing, the application is deemed to =09know what it wants to do. This may mean writing up until hard EOT =09is hit and VOLUME OVERFLOW is seen (in which case -1/ENOSPC get =09sent back). With respect to your comment about using dd to write to the end of tape, under this proposal, dd will write to the EARLY WARNING case and will errx with an "end of device" diagnostic. Under the existing model, dd will err with "no space on device" diagnostic, so this is no effective change. > As I said above, I don't think that the user program should be > handling the EOF conditions. As a result, signals are superfluous. I don't see the application as handling EOF conditions- just being warned that they are pending. > Single EOF marks: >=20 > It's been a while since I handled =BD" tapes, but my recollection was > that a single tape mark at the end of the reel meant "there are more > reels to come", and two tape marks meant "there are no more reels to > come". I'm prepared to be wrong on this, but if I'm not, we > obviously shouldn't be forgetting the second tape mark. Sigh.... This is a whole large issue in and of itself. >=20 > Reading: >=20 > I don't see that this is an issue. We attempt to read as much data > as requested. We return an indication of how much we actually read. > About the only issue I can think of is whether we should handle the > difference between one and two tape marks. =20 Well, I say one should keep reading until the drive reports hitting unrecorded media (and a terrible misfeature of SCSI tape devices is their almost universal inability to skip past erase-ahead gaps- so, if you write a filemark on the front of a tape, you really can't get past the dead area past the filemark to get at the N Gigabytes of valid data left. This does not apply to 1/2" Reel tapes, but there sure aren't too many of those in use that I can find ....). -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 22 6:38: 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 1779B14DB9 for ; Wed, 22 Dec 1999 06:38:05 -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 PAA07007 for ; Wed, 22 Dec 1999 15:38:02 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA32956 for freebsd-arch@freebsd.org; Wed, 22 Dec 1999 15:38:02 +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 083D814DB9 for ; Wed, 22 Dec 1999 06:37:47 -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 120mtd-0003Z3-00 for arch@FreeBSD.org; Wed, 22 Dec 1999 14:37:45 +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 PAA20454 for ; Wed, 22 Dec 1999 15:37:43 +0100 (CET) (envelope-from marcel@scc.nl) Message-ID: <3860E236.811FE085@scc.nl> Date: Wed, 22 Dec 1999 15:37:42 +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: arch@freebsd.org Subject: [Fwd: Rq for approval: new command: genassym] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I sort of automaticly posted this to -committers... -------- Original Message -------- Subject: Rq for approval: new command: genassym Date: Wed, 22 Dec 1999 14:39:31 +0100 From: Marcel Moolenaar Organization: SCC vof To: committers@freebsd.org Hi, Cross-building a kernel and modules (linux and svr4 in this case) is still not possible because the way assembler symbols are generated. The problem is basicly that we need to run a program built with the cross-compiler, which is not always possible. To solve this I made a genassym tool. It works as follows: A C source file (genassym.c for example) contains a number of data declarations of the form: int assym_MY_SYMBOL_NAME = SOME_VALUE; This file is compiled. The genassym tool reads the ELF object file and extracts the data declarations and creates the appropriate assembler declarations of the form: #define MY_SYMBOL_NAME SOME_VALUE A genassym tool is needed to be able to cross-build an i386 world on Alpha (for example) because the linux and svr4 modules won't build otherwise. Of course we also need this when we want to cross-build a kernel... The tool (incl. manpage) can be downloaded: http://www.freebsd.org/~marcel/genassyms.tar.gz Rewritten xxx_genassym.c source files for i386, alpha, linux module and svr4 module can be downloaded: http://www.freebsd.org/~marcel/assyms.tar.gz Q: Can I add the tool to src/usr.bin and eventually change the source files and Makefiles? Thanks, -- 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 Wed Dec 22 6:42: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 67E0114BEC for ; Wed, 22 Dec 1999 06:42:09 -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 PAA07056 for ; Wed, 22 Dec 1999 15:42:07 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA33000 for freebsd-arch@freebsd.org; Wed, 22 Dec 1999 15:42:07 +0100 (MET) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 422B814BEC for ; Wed, 22 Dec 1999 06:41:53 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id PAA20139; Wed, 22 Dec 1999 15:41:46 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Marcel Moolenaar Cc: arch@freebsd.org Subject: Re: [Fwd: Rq for approval: new command: genassym] In-reply-to: Your message of "Wed, 22 Dec 1999 15:37:42 +0100." <3860E236.811FE085@scc.nl> Date: Wed, 22 Dec 1999 15:41:45 +0100 Message-ID: <20137.945873705@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3860E236.811FE085@scc.nl>, Marcel Moolenaar writes: >Cross-building a kernel and modules (linux and svr4 in this case) is >still not possible because the way assembler symbols are generated. The >problem is basicly that we need to run a program built with the >cross-compiler, which is not always possible. To solve this I made a >genassym tool. It works as follows: > >[...] > >Q: Can I add the tool to src/usr.bin and eventually change the source >files and Makefiles? If you test it (GENERIC, LINT, GENERIC98, make release and the works...) and it works I don't a reason not to. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 22 7:13: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 7404114A31 for ; Wed, 22 Dec 1999 07:13:13 -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 QAA07524 for ; Wed, 22 Dec 1999 16:13:11 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA33247 for freebsd-arch@freebsd.org; Wed, 22 Dec 1999 16:13:10 +0100 (MET) Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 216F114D70 for ; Wed, 22 Dec 1999 07:12:44 -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 HAA00336; Wed, 22 Dec 1999 07:09:18 -0800 (PST) Message-Id: <199912221509.HAA00336@implode.root.com> To: Marcel Moolenaar Cc: arch@freebsd.org Subject: Re: [Fwd: Rq for approval: new command: genassym] In-reply-to: Your message of "Wed, 22 Dec 1999 15:37:42 +0100." <3860E236.811FE085@scc.nl> From: David Greenman Reply-To: dg@root.com Date: Wed, 22 Dec 1999 07:09:18 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sounds good to me... -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. >I sort of automaticly posted this to -committers... > >-------- Original Message -------- >Subject: Rq for approval: new command: genassym >Date: Wed, 22 Dec 1999 14:39:31 +0100 >From: Marcel Moolenaar >Organization: SCC vof >To: committers@freebsd.org > >Hi, > >Cross-building a kernel and modules (linux and svr4 in this case) is >still not possible because the way assembler symbols are generated. The >problem is basicly that we need to run a program built with the >cross-compiler, which is not always possible. To solve this I made a >genassym tool. It works as follows: > >A C source file (genassym.c for example) contains a number of data >declarations of the form: > int assym_MY_SYMBOL_NAME = SOME_VALUE; > >This file is compiled. The genassym tool reads the ELF object file and >extracts the data declarations and creates the appropriate assembler >declarations of the form: > #define MY_SYMBOL_NAME SOME_VALUE > >A genassym tool is needed to be able to cross-build an i386 world on >Alpha (for example) because the linux and svr4 modules won't build >otherwise. Of course we also need this when we want to cross-build a >kernel... > >The tool (incl. manpage) can be downloaded: > http://www.freebsd.org/~marcel/genassyms.tar.gz > >Rewritten xxx_genassym.c source files for i386, alpha, linux module and >svr4 module can be downloaded: > http://www.freebsd.org/~marcel/assyms.tar.gz > >Q: Can I add the tool to src/usr.bin and eventually change the source >files and Makefiles? > >Thanks, > >-- >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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 22 8:49: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 223B815042 for ; Wed, 22 Dec 1999 08:49: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 RAA08648 for ; Wed, 22 Dec 1999 17:49:37 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA33782 for freebsd-arch@freebsd.org; Wed, 22 Dec 1999 17:49:36 +0100 (MET) Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36]) by hub.freebsd.org (Postfix) with ESMTP id 8569614FA6; Wed, 22 Dec 1999 08:49:11 -0800 (PST) (envelope-from shin@nd.net.fujitsu.co.jp) Received: from m2.gw.fujitsu.co.jp by fgwmail6.fujitsu.co.jp (8.9.3/3.7W-MX9912-Fujitsu Gateway) id BAA29973; Thu, 23 Dec 1999 01:49:06 +0900 (JST) Received: from incapgw.fujitsu.co.jp by m2.gw.fujitsu.co.jp (8.9.3/3.7W-9912-Fujitsu Domain Master) id BAA15047; Thu, 23 Dec 1999 01:49:05 +0900 (JST) Received: from localhost ([192.168.245.35]) by incapgw.fujitsu.co.jp (8.9.3/3.7W-9912) id BAA00634; Thu, 23 Dec 1999 01:49:04 +0900 (JST) To: freebsd-arch@freebsd.org, cvs-committers@freebsd.org Subject: Re: [Solicite review for KAME 5th patch] In-Reply-To: <19991218013056S.shin@nd.net.fujitsu.co.jp> References: <19991212223550M.shin@nd.net.fujitsu.co.jp> <19991217030527N.shin@nd.net.fujitsu.co.jp> <19991218013056S.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: <19991223014928J.shin@nd.net.fujitsu.co.jp> Date: Thu, 23 Dec 1999 01:49:28 +0900 From: Yoshinobu Inoue X-Dispatcher: imput version 990905(IM130) Lines: 11 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > http://paradise.kame.net/v6proxy/diana2/shin/work/freebsd/kernel-ipsec.19991218 I locally prepared IPSEC library and tried encrypted ping on the machine with the above patches, and it worked fine. So I would like to commit it, after one more confirmation. If someone still has any big comments on it, please let me know. Thanks, Yoshinobu Inoue To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 23 5:22: 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 1B6C414F1B for ; Thu, 23 Dec 1999 05:22:05 -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 OAA22366 for ; Thu, 23 Dec 1999 14:22:01 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA38640 for freebsd-arch@freebsd.org; Thu, 23 Dec 1999 14:22:00 +0100 (MET) Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 8B5FB14E65 for ; Thu, 23 Dec 1999 05:21:50 -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 71BF11CCE; Thu, 23 Dec 1999 21:21:46 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: dg@root.com Cc: Marcel Moolenaar , arch@freebsd.org Subject: Re: [Fwd: Rq for approval: new command: genassym] In-Reply-To: Message from David Greenman of "Wed, 22 Dec 1999 07:09:18 PST." <199912221509.HAA00336@implode.root.com> Date: Thu, 23 Dec 1999 21:21:46 +0800 From: Peter Wemm Message-Id: <19991223132146.71BF11CCE@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Greenman wrote: > Sounds good to me... > > -DG My concern is chicken/egg problems.. eg: how do you build a 4.0 kernel on a 3.x system in order to complete the 'installworld' which requires a kernel to be already built? It's no big deal but it's one more "special" thing. config(8) and company are in the same boat, I'd rather we did less of this than more. > >I sort of automaticly posted this to -committers... > > > >-------- Original Message -------- > >Subject: Rq for approval: new command: genassym > >Date: Wed, 22 Dec 1999 14:39:31 +0100 > >From: Marcel Moolenaar > >Organization: SCC vof > >To: committers@freebsd.org > > > >Hi, > > > >Cross-building a kernel and modules (linux and svr4 in this case) is > >still not possible because the way assembler symbols are generated. The > >problem is basicly that we need to run a program built with the > >cross-compiler, which is not always possible. To solve this I made a > >genassym tool. It works as follows: > > > >A C source file (genassym.c for example) contains a number of data > >declarations of the form: > > int assym_MY_SYMBOL_NAME = SOME_VALUE; > > > >This file is compiled. The genassym tool reads the ELF object file and > >extracts the data declarations and creates the appropriate assembler > >declarations of the form: > > #define MY_SYMBOL_NAME SOME_VALUE > > > >A genassym tool is needed to be able to cross-build an i386 world on > >Alpha (for example) because the linux and svr4 modules won't build > >otherwise. Of course we also need this when we want to cross-build a > >kernel... > > > >The tool (incl. manpage) can be downloaded: > > http://www.freebsd.org/~marcel/genassyms.tar.gz > > > >Rewritten xxx_genassym.c source files for i386, alpha, linux module and > >svr4 module can be downloaded: > > http://www.freebsd.org/~marcel/assyms.tar.gz > > > >Q: Can I add the tool to src/usr.bin and eventually change the source > >files and Makefiles? 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 Thu Dec 23 5:28: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 2BCDF14DC6 for ; Thu, 23 Dec 1999 05:28: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 OAA22494 for ; Thu, 23 Dec 1999 14:28:52 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA38690 for freebsd-arch@freebsd.org; Thu, 23 Dec 1999 14:28:52 +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 E694B14E25 for ; Thu, 23 Dec 1999 05:28: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 1218IO-000IoC-00; Thu, 23 Dec 1999 13:28:44 +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 OAA42118; Thu, 23 Dec 1999 14:28:41 +0100 (CET) (envelope-from marcel@scc.nl) Message-ID: <38622389.EE43E6A7@scc.nl> Date: Thu, 23 Dec 1999 14:28:41 +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: arch@freebsd.org Subject: Re: cvs commit: src/usr.bin/genassym... References: <19991223120509.45E701CCE@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 [cc'd to -arch] Peter Wemm wrote: > > > Added files: > > usr.bin/genassym Makefile genassym.8 genassym.c > > Log: > > New command for creating assembler symbols from C. > > Actually, now that I'm awake properly, the thought just occurred to me. > This should be shipped with the kernel (along with config(8) and it's > replacement) as the modules are not going to be built with the world > for much longer. Possibly... Currently only the kernel and 2 modules need to use genassym, but I don't want to qualify it as a kernel-only tool per se. What about gensetdefs? gensetdefs is also needed by the Alpha boot loader, BTW. And what about elf2exe? Anyway, what it the status of building modules with the kernel and how does it complicate a cross-build in which we want to build a kernel as well (needed to properly upgrade)? -- 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 Thu Dec 23 5:53: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 7265614D4A for ; Thu, 23 Dec 1999 05:53: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 OAA23495 for ; Thu, 23 Dec 1999 14:53:40 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA38760 for freebsd-arch@freebsd.org; Thu, 23 Dec 1999 14:53:36 +0100 (MET) Received: from mail.scc.nl (node1374.a2000.nl [62.108.19.116]) by hub.freebsd.org (Postfix) with ESMTP id 615B614F59 for ; Thu, 23 Dec 1999 05:53:27 -0800 (PST) (envelope-from freebsd-arch@scc.nl) Received: (from daemon@localhost) by mail.scc.nl (8.9.3/8.9.3) id OAA84548 for arch@FreeBSD.org; Thu, 23 Dec 1999 14:36:25 +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: Thu, 23 Dec 1999 14:36:18 +0100 From: Marcel Moolenaar Message-ID: <38622552.8AB44C45@scc.nl> Organization: SCC vof Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: , <19991223132146.71BF11CCE@overcee.netplex.com.au> Subject: Re: [Fwd: Rq for approval: new command: genassym] Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Wemm wrote: > > My concern is chicken/egg problems.. eg: how do you build a 4.0 kernel on a > 3.x system in order to complete the 'installworld' which requires a kernel > to be already built? It's no big deal but it's one more "special" thing. > config(8) and company are in the same boat, I'd rather we did less of this > than more. There's no chicken and egg problem. genassym builds independently of a kernel and is done so by the cross-tools target. Any kernel built as part of an upgrade process uses the freshly built genassym. The installworld problem is solved by not using any binaries that can be overwritten by the install process. I already have this locally. An installworld will not depend on a new kernel itself. An upgrade process can therefore build and install world *and* a kernel and only needs a working reboot to finish it off. Optionally it could install new bootblocks as well. -- 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 Thu Dec 23 12: 7:59 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 C0EA714D26 for ; Thu, 23 Dec 1999 12:07: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 VAA27538 for ; Thu, 23 Dec 1999 21:07:47 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA41382 for freebsd-arch@freebsd.org; Thu, 23 Dec 1999 21:07:46 +0100 (MET) Received: from pau-amma.whistle.com (pau-amma.whistle.com [207.76.205.64]) by hub.freebsd.org (Postfix) with ESMTP id 21A53156DF for ; Thu, 23 Dec 1999 12:07:31 -0800 (PST) (envelope-from dhw@whistle.com) Received: (from dhw@localhost) by pau-amma.whistle.com (8.9.2/8.9.2) id MAA65565; Thu, 23 Dec 1999 12:07:16 -0800 (PST) Date: Thu, 23 Dec 1999 12:07:16 -0800 (PST) From: David Wolfskill Message-Id: <199912232007.MAA65565@pau-amma.whistle.com> To: bde@zeta.org.au, rb@gid.co.uk, syssgm@detir.qld.gov.au Subject: Re: filemarks? Cc: freebsd-arch@freebsd.org, freebsd@gndrsh.dnsmgr.net, grog@lemis.com, hf@Melog.DE, joerg_wunsch@uriah.heep.sax.de, mjacob@feral.com, rivers@dignus.com In-Reply-To: <3.0.6.32.19991221165541.007b7480@192.168.255.1> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Date: Tue, 21 Dec 1999 16:55:41 +0000 >From: Bob Bishop [Sorry about the delay; had a backlog.... dhw] >On 1/2" tape, EOT was a reflective marker on the back of the tape. You were >supposed to have something like 30ft of tape after the marker, at least >10ft of which had to be writeable. So the drive could complete the block >being written at EOT, and still write two tape marks thereafter (but data >writes would fail IIRC). Only a broken drive (not unknown) would let you >run the tape off the reel. ISTR (and you will appreciate this is a while >ago) that drivers would return the block size for the block written over >EOT and zero for any subsequent data write attempt. Closing the file wrote >two tape marks. Please also note that it was hardly unknown for those reflective Mylar strips to become detached from the tape; I recall at least one 3820 (or was it a 3810? It *was* a while ago!) where that happened, with the (unsurprising) result that the tape came off the supply reel. (And yes, I recall the little boxes of adhesive-backed reflective Mylar strips that were kept near the 38xx drives, along with a pair of scissors for trimming the end of the tape when it became too frayed. Later, there was a special semi-circular punch to make a nice, round leader to thread....) 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 Thu Dec 23 22:29: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 8DF7C15112 for ; Thu, 23 Dec 1999 22:29: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 HAA06506 for ; Fri, 24 Dec 1999 07:29:34 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id HAA44053 for freebsd-arch@freebsd.org; Fri, 24 Dec 1999 07:29:33 +0100 (MET) Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 2E25D15112 for ; Thu, 23 Dec 1999 22:29:24 -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 3B9A81CCE; Fri, 24 Dec 1999 14:29:20 +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: cvs commit: src/usr.bin/genassym... In-Reply-To: Message from Marcel Moolenaar of "Thu, 23 Dec 1999 14:28:41 +0100." <38622389.EE43E6A7@scc.nl> Date: Fri, 24 Dec 1999 14:29:20 +0800 From: Peter Wemm Message-Id: <19991224062920.3B9A81CCE@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Marcel Moolenaar wrote: > [cc'd to -arch] > > Peter Wemm wrote: > > > > > Added files: > > > usr.bin/genassym Makefile genassym.8 genassym.c > > > Log: > > > New command for creating assembler symbols from C. > > > > Actually, now that I'm awake properly, the thought just occurred to me. > > This should be shipped with the kernel (along with config(8) and it's > > replacement) as the modules are not going to be built with the world > > for much longer. > > Possibly... Currently only the kernel and 2 modules need to use > genassym, but I don't want to qualify it as a kernel-only tool per se. > What about gensetdefs? > gensetdefs is also needed by the Alpha boot loader, BTW. > And what about elf2exe? > > Anyway, what it the status of building modules with the kernel and how > does it complicate a cross-build in which we want to build a kernel as > well (needed to properly upgrade)? The direction I'm working towards is building the kernel and modules at the same time under a common configuration and not part of 'world' at all. ie: the modules will be build under "GENERIC" along with the generic kernel. If you build a highly tuned kernel, your modules are tuned as well. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 24 1:23: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 52C0B15189 for ; Fri, 24 Dec 1999 01:23: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 KAA07766 for ; Fri, 24 Dec 1999 10:23:38 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id KAA44582 for freebsd-arch@freebsd.org; Fri, 24 Dec 1999 10:23:38 +0100 (MET) Received: from mail.scc.nl (node1374.a2000.nl [62.108.19.116]) by hub.freebsd.org (Postfix) with ESMTP id 1AECA15189 for ; Fri, 24 Dec 1999 01:23:31 -0800 (PST) (envelope-from freebsd-arch@scc.nl) Received: (from daemon@localhost) by mail.scc.nl (8.9.3/8.9.3) id KAA71303 for arch@FreeBSD.org; Fri, 24 Dec 1999 10:10:04 +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: Fri, 24 Dec 1999 10:09:11 +0100 From: Marcel Moolenaar Message-ID: <38633837.53B5C3FF@scc.nl> Organization: SCC vof Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: , <19991224062920.3B9A81CCE@overcee.netplex.com.au> Subject: Re: cvs commit: src/usr.bin/genassym... Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Wemm wrote: > > The direction I'm working towards is building the kernel and modules at the > same time under a common configuration and not part of 'world' at all. ie: > the modules will be build under "GENERIC" along with the generic kernel. If you > build a highly tuned kernel, your modules are tuned as well. Do you add provisions to build "kernel-land" outside the source tree as well or will it be default behaviour? -- 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