From owner-freebsd-arch Sun Dec 5 2:25: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 B756A14D3F for ; Sun, 5 Dec 1999 02:25:33 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id LAA07266 for ; Sun, 5 Dec 1999 11:25:31 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id LAA01199 for freebsd-arch@freebsd.org; Sun, 5 Dec 1999 11:25:31 +0100 (MET) Received: from post.mail.nl.demon.net (post-10.mail.nl.demon.net [194.159.73.20]) by hub.freebsd.org (Postfix) with ESMTP id C06A214D3F for ; Sun, 5 Dec 1999 02:25:21 -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.02 #1) id 11uYq9-0004iC-00; Sun, 5 Dec 1999 10:24:25 +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 LAA17346; Sun, 5 Dec 1999 11:24:20 +0100 (CET) (envelope-from marcel@scc.nl) Message-ID: <384A3D54.3DFE76D6@scc.nl> Date: Sun, 05 Dec 1999 11:24:20 +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: Martin Cracauer Cc: Bruce Evans , freebsd-arch@freebsd.org Subject: Re: cvs commit: src/sys/i386/include signal.h References: <382E8A1B.B7D9B7F0@scc.nl> <19991115095729.A27507@cons.org> <382FDBE2.D075594@scc.nl> <19991115115552.A27870@cons.org> <382FF2AF.545C8C81@scc.nl> <19991204234145.A1221@cons.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Martin Cracauer wrote: > Also mcontext_t is proposed to be bumped to 512 bytes for possible > future extensions (because changing the size once 4.0 is out is > *bad*). mcontext_t is embedded in ucontext_t. If you want a nice round figure, I still think we should round ucontext_t and scale mcontext_t accordingly. Remember that ucontext_t and not mcontext_t is used in interfaces. mcontext_t is "just" a field of ucontext_t... > Decisions in order of importance: > - Do you accept bumping mcontext_t to 512 bytes? No, I'll accept ucontext_t to be bumped to a nice round number (say 512 bytes) and have the extra space used by mcontext_t :-) > - Do you like the bitmap scheme? Yes. It's quite common. > - If you would prefer the pointer scheme, you probably have some > processor-specific things that may end up in mcontext. Tell us! I think the pointer scheme is a bit too complex. About the patch: in struct context: ! int sc_fpemul[16]; ! int __morespare__[63]; in mcontext_t: ! int mc_fpemul[16]; /* Additional FPU emulator status */ ! int __morespare__[63]; /* For later additions, total = 512 */ There's no need to rub it in :-) I prefer `__spare__' to make it clear that it's not a regular field. I think Bruce would like you to use `sc_spare'... -- 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 Sun Dec 5 2:31: 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 9AF9714D3F for ; Sun, 5 Dec 1999 02:31: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 LAA07299 for ; Sun, 5 Dec 1999 11:29:35 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id LAA01254 for freebsd-arch@freebsd.org; Sun, 5 Dec 1999 11:29:35 +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 EB05A14D3F for ; Sun, 5 Dec 1999 02:29:29 -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 11uYtt-0006Kv-00; Sun, 5 Dec 1999 10:28:17 +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 LAA17425; Sun, 5 Dec 1999 11:28:20 +0100 (CET) (envelope-from marcel@scc.nl) Message-ID: <384A3E44.9837A129@scc.nl> Date: Sun, 05 Dec 1999 11:28:20 +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: mjacob@feral.com Cc: Martin Cracauer , Bruce Evans , freebsd-arch@freebsd.org Subject: Re: cvs commit: src/sys/i386/include signal.h References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Jacob wrote: > > Would any thinking about this be applicable to storing machine FPU > specific state for Alpha or Sparc? In particular for Sparc there's a lot > of userland fixup that can be done. I can't quite parse this unambiguisly (sp?), but if you mean that this should also be done on other ports, then the answer is probably yes. -- 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 Sun Dec 5 4:57: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 88C6414BD7 for ; Sun, 5 Dec 1999 04:57: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 NAA08451 for ; Sun, 5 Dec 1999 13:57:08 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA01967 for freebsd-arch@freebsd.org; Sun, 5 Dec 1999 13:57:07 +0100 (MET) Received: from knight.cons.org (knight.cons.org [194.233.237.195]) by hub.freebsd.org (Postfix) with ESMTP id 2913F14C39 for ; Sun, 5 Dec 1999 04:56:46 -0800 (PST) (envelope-from cracauer@knight.cons.org) Received: (from cracauer@localhost) by knight.cons.org (8.9.3/8.9.3) id NAA04024; Sun, 5 Dec 1999 13:56:25 +0100 (CET) Date: Sun, 5 Dec 1999 13:56:24 +0100 From: Martin Cracauer To: Marcel Moolenaar Cc: Martin Cracauer , Bruce Evans , freebsd-arch@freebsd.org Subject: Re: cvs commit: src/sys/i386/include signal.h Message-ID: <19991205135624.A4009@cons.org> References: <382E8A1B.B7D9B7F0@scc.nl> <19991115095729.A27507@cons.org> <382FDBE2.D075594@scc.nl> <19991115115552.A27870@cons.org> <382FF2AF.545C8C81@scc.nl> <19991204234145.A1221@cons.org> <384A3D54.3DFE76D6@scc.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <384A3D54.3DFE76D6@scc.nl>; from Marcel Moolenaar on Sun, Dec 05, 1999 at 11:24:20AM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In <384A3D54.3DFE76D6@scc.nl>, Marcel Moolenaar wrote: > Martin Cracauer wrote: > > Also mcontext_t is proposed to be bumped to 512 bytes for possible > > future extensions (because changing the size once 4.0 is out is > > *bad*). > > mcontext_t is embedded in ucontext_t. If you want a nice round figure, I > still think we should round ucontext_t and scale mcontext_t accordingly. > Remember that ucontext_t and not mcontext_t is used in interfaces. > mcontext_t is "just" a field of ucontext_t... > > > Decisions in order of importance: > > - Do you accept bumping mcontext_t to 512 bytes? > > No, I'll accept ucontext_t to be bumped to a nice round number (say 512 > bytes) and have the extra space used by mcontext_t :-) I'm afraid that is not useful, since there are only 64 bytes left (with FPU status already there), not enough to keep this extension scheme running for future extensions. What about 4K? :-]]] 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 5 5:29:52 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 6797F14DBF for ; Sun, 5 Dec 1999 05:29: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 OAA08687 for ; Sun, 5 Dec 1999 14:28:32 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA02027 for freebsd-arch@freebsd.org; Sun, 5 Dec 1999 14:28:32 +0100 (MET) Received: from mail.scc.nl (node1374.a2000.nl [62.108.19.116]) by hub.freebsd.org (Postfix) with ESMTP id E3AFC14DBF for ; Sun, 5 Dec 1999 05:28:21 -0800 (PST) (envelope-from freebsd-arch@scc.nl) Received: (from daemon@localhost) by mail.scc.nl (8.9.3/8.9.3) id OAA33189 for arch@FreeBSD.org; Sun, 5 Dec 1999 14:03:59 +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: Sun, 05 Dec 1999 14:03:56 +0100 From: Marcel Moolenaar Message-ID: <384A62BC.62E41CC1@scc.nl> Organization: SCC vof Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <382E8A1B.B7D9B7F0@scc.nl>, <19991205135624.A4009@cons.org> Subject: Re: cvs commit: src/sys/i386/include signal.h Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Martin Cracauer wrote: > > I'm afraid that is not useful, since there are only 64 bytes left > (with FPU status already there), not enough to keep this extension > scheme running for future extensions. > > What about 4K? :-]]] Hmm.. Just a marginal size change :-) -- 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 Sun Dec 5 5:30: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 030F414DBF for ; Sun, 5 Dec 1999 05:30:15 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id OAA08698 for ; Sun, 5 Dec 1999 14:29:16 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA02042 for freebsd-arch@freebsd.org; Sun, 5 Dec 1999 14:29:15 +0100 (MET) Received: from knight.cons.org (knight.cons.org [194.233.237.195]) by hub.freebsd.org (Postfix) with ESMTP id D5F8514DBF for ; Sun, 5 Dec 1999 05:28:58 -0800 (PST) (envelope-from cracauer@knight.cons.org) Received: (from cracauer@localhost) by knight.cons.org (8.9.3/8.9.3) id OAA04133; Sun, 5 Dec 1999 14:27:28 +0100 (CET) Date: Sun, 5 Dec 1999 14:27:28 +0100 From: Martin Cracauer To: freebsd-arch@freebsd.org Cc: Marcel Moolenaar Subject: Re: cvs commit: src/sys/i386/include signal.h Message-ID: <19991205142727.A4111@cons.org> References: <382E8A1B.B7D9B7F0@scc.nl> <19991115095729.A27507@cons.org> <382FDBE2.D075594@scc.nl> <19991115115552.A27870@cons.org> <382FF2AF.545C8C81@scc.nl> <19991204234145.A1221@cons.org> <384A3D54.3DFE76D6@scc.nl> <19991205135624.A4009@cons.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <19991205135624.A4009@cons.org>; from Martin Cracauer on Sun, Dec 05, 1999 at 01:56:24PM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As another datapoint in the issue, I had a look into the scheme SunOS-5.7 uses: mcontext_t includes: - a description of the CPU registers - a description of the FPU registers - no other extensions, no mechanism to turn the FPU status visibilty off. The FPU description is a union of two plain byte arrays, one for hardware FPU, one for the emulator, plus space for the Weitek chips. 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 5 6:13: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 5CFB714C85 for ; Sun, 5 Dec 1999 06:13: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 PAA08979 for ; Sun, 5 Dec 1999 15:13:41 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA02138 for freebsd-arch@freebsd.org; Sun, 5 Dec 1999 15:13:40 +0100 (MET) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 9892514C85 for ; Sun, 5 Dec 1999 06:12:51 -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 BAA03452; Mon, 6 Dec 1999 01:17:32 +1100 Date: Mon, 6 Dec 1999 01:12:08 +1100 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Martin Cracauer Cc: Marcel Moolenaar , freebsd-arch@freebsd.org Subject: Re: cvs commit: src/sys/i386/include signal.h In-Reply-To: <19991205135624.A4009@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 > > > Decisions in order of importance: > > > - Do you accept bumping mcontext_t to 512 bytes? > > > > No, I'll accept ucontext_t to be bumped to a nice round number (say 512 > > bytes) and have the extra space used by mcontext_t :-) > > I'm afraid that is not useful, since there are only 64 bytes left > (with FPU status already there), not enough to keep this extension > scheme running for future extensions. > > What about 4K? :-]]] Arrgh :-). Remember that the whole struct must be bzeroed to prevent leaking kernel data. I think I prefer a variable sized "struct" like struct dirent. 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 5 7:59:31 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 070DC14BD0 for ; Sun, 5 Dec 1999 07:59:28 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id QAA09736 for ; Sun, 5 Dec 1999 16:59:26 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA02470 for freebsd-arch@freebsd.org; Sun, 5 Dec 1999 16:59:26 +0100 (MET) Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id B808B14BD0 for ; Sun, 5 Dec 1999 07:59:19 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id QAA14949; Sun, 5 Dec 1999 16:05:15 GMT (envelope-from dfr@nlsystems.com) Date: Sun, 5 Dec 1999 16:05:15 +0000 (GMT) From: Doug Rabson To: Matthew Jacob Cc: Martin Cracauer , Marcel Moolenaar , Bruce Evans , freebsd-arch@freebsd.org Subject: Re: cvs commit: src/sys/i386/include signal.h In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 4 Dec 1999, Matthew Jacob wrote: > > Would any thinking about this be applicable to storing machine FPU > specific state for Alpha or Sparc? In particular for Sparc there's a lot > of userland fixup that can be done. For alpha, we already store FP state in the context. -- 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 Sun Dec 5 7:59:34 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 1BA9314D4E for ; Sun, 5 Dec 1999 07:59:29 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id QAA09741 for ; Sun, 5 Dec 1999 16:59:28 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA02484 for freebsd-arch@freebsd.org; Sun, 5 Dec 1999 16:59:28 +0100 (MET) Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id D25B514D4E for ; Sun, 5 Dec 1999 07:59:21 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id QAA14956; Sun, 5 Dec 1999 16:06:30 GMT (envelope-from dfr@nlsystems.com) Date: Sun, 5 Dec 1999 16:06:30 +0000 (GMT) From: Doug Rabson To: Martin Cracauer Cc: Marcel Moolenaar , Bruce Evans , freebsd-arch@freebsd.org Subject: Re: cvs commit: src/sys/i386/include signal.h In-Reply-To: <19991205135624.A4009@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, 5 Dec 1999, Martin Cracauer wrote: > In <384A3D54.3DFE76D6@scc.nl>, Marcel Moolenaar wrote: > > Martin Cracauer wrote: > > > Also mcontext_t is proposed to be bumped to 512 bytes for possible > > > future extensions (because changing the size once 4.0 is out is > > > *bad*). > > > > mcontext_t is embedded in ucontext_t. If you want a nice round figure, I > > still think we should round ucontext_t and scale mcontext_t accordingly. > > Remember that ucontext_t and not mcontext_t is used in interfaces. > > mcontext_t is "just" a field of ucontext_t... > > > > > Decisions in order of importance: > > > - Do you accept bumping mcontext_t to 512 bytes? > > > > No, I'll accept ucontext_t to be bumped to a nice round number (say 512 > > bytes) and have the extra space used by mcontext_t :-) > > I'm afraid that is not useful, since there are only 64 bytes left > (with FPU status already there), not enough to keep this extension > scheme running for future extensions. > > What about 4K? :-]]] [I've said this before] If we are reserving space for FP state on ia32, then we *must* reserve enough space for the new SSE registers. -- 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 Sun Dec 5 8:29:50 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 1959B151F0 for ; Sun, 5 Dec 1999 08:29: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 RAA09948 for ; Sun, 5 Dec 1999 17:29:45 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA02596 for freebsd-arch@freebsd.org; Sun, 5 Dec 1999 17:29:45 +0100 (MET) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 6D160151F0 for ; Sun, 5 Dec 1999 08:29:37 -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 DAA06604; Mon, 6 Dec 1999 03:34:30 +1100 Date: Mon, 6 Dec 1999 03:29:10 +1100 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Marcel Moolenaar Cc: Martin Cracauer , freebsd-arch@freebsd.org Subject: Re: cvs commit: src/sys/i386/include signal.h In-Reply-To: <384A3D54.3DFE76D6@scc.nl> 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, 5 Dec 1999, Marcel Moolenaar wrote: > Martin Cracauer wrote: > > Decisions in order of importance: > > - Do you accept bumping mcontext_t to 512 bytes? > > No, I'll accept ucontext_t to be bumped to a nice round number (say 512 > bytes) and have the extra space used by mcontext_t :-) I don't want a round number (except maybe to a cache line or -mpreferred-stack boundary). Leaving space at the end of ucontext_t alone doesn't work because it is discontiguous with uc_mcontext. Leaving space in the middle of ucontext_t would be little better. OTOH, any expansion of mcontext_t while it is in the middle of ucontext_t would break binary compatibility. I think mcontext_t should go at the end of ucontext_t and most extensions should be in mcontext_t (just leave a few spares in ucontext_t and try not to use them). We would have to break binary compatibility again to move mcontext_t :-(. > > > - Do you like the bitmap scheme? > > Yes. It's quite common. Yes. > in mcontext_t: > ! int mc_fpemul[16]; /* Additional FPU emulator > status */ > ! int __morespare__[63]; /* For later additions, total = > 512 */ > > There's no need to rub it in :-) I prefer `__spare__' to make it clear > that it's not a regular field. I think Bruce would like you to use > `sc_spare'... I like struct member names to have prefixes. Prefixes are almost required in API headers to limit namespace pollution. When you have a prefix, using underscores is just and obfuscation. 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 5 12:18: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 6120D14DCA for ; Sun, 5 Dec 1999 12:18: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 VAA12015 for ; Sun, 5 Dec 1999 21:18:21 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA03740 for freebsd-arch@freebsd.org; Sun, 5 Dec 1999 21:18:16 +0100 (MET) Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 980AD15445; Sun, 5 Dec 1999 12:16:45 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (root@d60-025.leach.ucdavis.edu [169.237.60.25]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id MAA27177; Sun, 5 Dec 1999 12:16:44 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id MAA69201; Sun, 5 Dec 1999 12:16:44 -0800 (PST) (envelope-from obrien) Date: Sun, 5 Dec 1999 12:16:43 -0800 From: "David O'Brien" To: arch@freebsd.org, audit@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h Message-ID: <19991205121643.A69177@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <89015.943945313@zippy.cdrom.com> <99Dec1.091202est.40330@border.alcanet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <99Dec1.091202est.40330@border.alcanet.com.au>; from jeremyp@gsmx07.alcatel.com.au on Wed, Dec 01, 1999 at 09:19:18AM +1100 X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Dec 01, 1999 at 09:19:18AM +1100, Peter Jeremy wrote: > >Not being able to predict pids (for useful purposes) would fall under > >the definition of "negative impact" for a number of admins. > > I agree. Digital UNIX uses something like random PID generation and I Well there you go, we now have an example that you can't depend on the linear behavior in Unix. So we have a strong case for making random PIDs the default. -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 5 12:25: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 AA705154C1 for ; Sun, 5 Dec 1999 12:25:33 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA12082 for ; Sun, 5 Dec 1999 21:25:17 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA03780 for freebsd-arch@freebsd.org; Sun, 5 Dec 1999 21:25:17 +0100 (MET) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id AF98514DCA; Sun, 5 Dec 1999 12:25:06 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id PAA06444; Sun, 5 Dec 1999 15:25:06 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Sun, 5 Dec 1999 15:25:05 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: freebsd-arch@freebsd.org Subject: ACL support: semantics vs. syntax in the context of multiple types of ACLs over multiple file systems in the VFS 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 thought I'd send out an email to discuss some design issues in the implementation of ACL support for FreeBSD. As you probably know, I'm in the process of implementing support for POSIX.1e security extensions to FreeBSD, and this includes support for Access Control Lists for files and directories (and possibly other things :-). The design questions arise because access control, in most cases, is a per-file system design. In FFS, there are file owners, groups, permissions for them, and some additional extended flags. In Coda and AFS, directories have a more extended set of permissions, but individual files don't have individual access control restrictions. In POSIX.1e, ACL semantics define an ACL for each file, and two for each directory (an access ACL, and a default ACL for new children). To a large extent, these ACLs all have the same syntax: a (sometimes restricted) list of ids (of some kind), with a bitmask of rights associated with them. What differs is the exact definition of what the id's refer to, and what the rights are, as well as some restrictions on combinations of ids and rights, as well as ACL targets. This suggests a model wherein the operations exposed to the VFS (i.e., vop_getacl and vop_setacl) require a specific syntax, but leave the specific semantics to whatever layer of the file system stack receives the request. For example, FFS might choose to map ACL operations onto standard attributes/permissions, and only allow ACLs that fit the possible permissions in FFS. AFS might choose to interpret the id's in question as viceids, and the permission mask as AFS permissions. An ACLfs extension to FFS might choose the POSIX.1e semantics. This would leave it up to the calling program to choose the correct type of ACL when setting it for a file or directory, and the requested ACL would be rejected if it didn't match. This leaves opportunities for a number of problems, including confusion by the user, application of an ACL designed for one set of semantics on another set of semantics, etc. Also, it means that some of the POSIX.1e ACL calls (such as acl_valid()) now depend on the target, not just on the ACL itself as a data structure, introducing a lot of complexity. That said, this may be the only way to go. The vast majority of UNIX operating systems have selected either direct POSIX.1e ACL syntax + semantics, or closely related semantics/syntax, including Solaris, IRIX, HPUX, and Linux. But given the complexity of POSIX.1e ACL behavior, and the desire to support other ACL models (such as the intuitive and powerful AFS/Coda model), we would also rather not define a mechanism useful for only one set of semantics. As such, I'm suggesting moving from just vop_getacl and vop_setacl VOPs, to: VOP_ACLVALID(vp, acl, type) VOP_GETACL(vp, acl, type) VOP_SETACL(vp, acl, type) Where type continues to index into the set of available ACLs for the vnode (access, default, etc), and acl is the desired ACL. The acl_valid() POSIX.1e call, currently handled in the library, would now query the vnode it would be applied to to see if the vnode would accept the ACL. The existing POSIX.1e acl_valid() call would simply ask whatever the root file system was whether the ACL was valid for it, and would be depreciated in favor of acl_valid_file() and acl_valid_fd() with specific targets. Currently POSIX.1e defines an ACL entry as being made up of three parts -- an id, id qualifier, and permission set. The id identifies a principal, the qualifier, the namespace for the principal, and the permission set is the mask of rights. POSIX.1e defines several qualifier types, including ACL_USER_OBJ, ACL_USER, ACL_GROUP_OBJ, ACL_GROUP, ACL_OTHER, and ACL_MASK. I believe expanding this namespace is sufficient to take into account differing semantics, although I'm not sure. For example, we could add an ACL_AFS_ID to indicate that the ACL applied to an AFS viceid. Presumably AFS vnodes would reject ACLs with qualifiers other than this, and POSIX.1e file systems would reject AFS entries. Another alternative would be to introduce additional ACL types, but I think that is not intuitive, as the types are currently "access" and "default", and "access" has the same semantics in both POSIX.1e and AFS. The advantage of all this is removing complexity and semantics awareness in the syscall and vnops, but the disadvantage is increasing awareness of semantics in the library -- the awareness in the file system itself was always required. The library would now have to be aware of how to print and interpret text versions of differing ACL types. So when AFS was added, it would just be a kernel module, but also a libc update. We might consider pluggable file system components in libc, but I see that as a hard task to address correctly (although it might be desirable, especially given different principal namespaces and the desire to print principal names in ls -l, etc). I plan to go ahead and reimplement components of the current ACL code to reflect this goal of a semantics-unaware vnops and syscall interface (for example, acl_syscall_set_file will no longer check ACL validity, instead rely on the fs to do this), but would like comments on whether this model suits the needs of the various ACL interface consumers, such as FFS ACL people, AFS people, Coda people, and concerned parties :-). It would also mean we could make use of a better ACL scheme on our own file systems yet support Solaris or IRIX exported file systems with POSIX.1e, and also support the new NFSv4 ACL scheme which is different from any of those mentioned so far :-). I've BCC'd this -security because -security people are interested in ACLs, but it's probably discussion for -arch, so it's actually addressed there. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 5 15: 7: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 19EAE14C2F for ; Sun, 5 Dec 1999 15:07: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 AAA13682 for ; Mon, 6 Dec 1999 00:07:36 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA04564 for freebsd-arch@freebsd.org; Mon, 6 Dec 1999 00:07:36 +0100 (MET) Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 0A6CB14C3E for ; Sun, 5 Dec 1999 15:07:30 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (root@d60-025.leach.ucdavis.edu [169.237.60.25]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id PAA28216; Sun, 5 Dec 1999 15:07:30 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id PAA74171; Sun, 5 Dec 1999 15:07:30 -0800 (PST) (envelope-from obrien) Date: Sun, 5 Dec 1999 15:07:30 -0800 From: "David O'Brien" To: Martin Cracauer Cc: freebsd-arch@freebsd.org Subject: Re: cvs commit: src/sys/i386/include signal.h Message-ID: <19991205150730.C74087@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <382E8A1B.B7D9B7F0@scc.nl> <19991115095729.A27507@cons.org> <382FDBE2.D075594@scc.nl> <19991115115552.A27870@cons.org> <382FF2AF.545C8C81@scc.nl> <19991204234145.A1221@cons.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <19991204234145.A1221@cons.org>; from cracauer@cons.org on Sat, Dec 04, 1999 at 11:41:45PM +0100 X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Dec 04, 1999 at 11:41:45PM +0100, Martin Cracauer wrote: > mcontext_t before the 4.0 codefreeze (15.12.1999)! 15-Dec-1999 is not code freeze. It is feature freeze. -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 6 2:54: 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 3ABC914D03 for ; Mon, 6 Dec 1999 02:54:07 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id LAA25019 for ; Mon, 6 Dec 1999 11:54:03 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id LAA07290 for freebsd-arch@freebsd.org; Mon, 6 Dec 1999 11:54:02 +0100 (MET) Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 8FCDE15140; Mon, 6 Dec 1999 02:53:43 -0800 (PST) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.11 #1) id 11uvm2-0006zQ-00; Mon, 06 Dec 1999 12:53:42 +0200 From: Sheldon Hearn To: obrien@freebsd.org Cc: arch@freebsd.org, audit@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h In-reply-to: Your message of "Sun, 05 Dec 1999 12:16:43 PST." <19991205121643.A69177@dragon.nuxi.com> Date: Mon, 06 Dec 1999 12:53:42 +0200 Message-ID: <26871.944477622@axl.noc.iafrica.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 05 Dec 1999 12:16:43 PST, "David O'Brien" wrote: > Well there you go, we now have an example that you can't depend on the > linear behavior in Unix. So we have a strong case for making random PIDs > the default. Nah, just leave the historical linear assignment as the default mode of operation for the sake of POLA and document the knob for random assignment in rc.conf.5 and wherever else might be appropriate. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 6 3:29: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 A2AC7150FF for ; Mon, 6 Dec 1999 03:29: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 MAA25579 for ; Mon, 6 Dec 1999 12:29:18 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id MAA07379 for freebsd-arch@freebsd.org; Mon, 6 Dec 1999 12:29:17 +0100 (MET) Received: from tank.skynet.be (tank.skynet.be [195.238.2.35]) by hub.freebsd.org (Postfix) with ESMTP id 268AF150FF; Mon, 6 Dec 1999 03:29:03 -0800 (PST) (envelope-from root@foxbert.skynet.be) Received: from foxbert.skynet.be (foxbert.skynet.be [195.238.1.45]) by tank.skynet.be (8.9.3/odie-relay-v1.0) with ESMTP id MAA15484; Mon, 6 Dec 1999 12:28:59 +0100 (MET) Received: (from root@localhost) by foxbert.skynet.be (8.9.1/jovi-pop-2.1) id MAA25586; Mon, 6 Dec 1999 12:28:57 +0100 (MET) Mime-Version: 1.0 X-Sender: blk@foxbert.skynet.be Message-Id: In-Reply-To: <26871.944477622@axl.noc.iafrica.com> References: <26871.944477622@axl.noc.iafrica.com> Date: Mon, 6 Dec 1999 12:28:15 +0100 To: Sheldon Hearn , obrien@freebsd.org From: Brad Knowles Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h Cc: arch@freebsd.org, audit@freebsd.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 12:53 PM +0200 1999/12/6, Sheldon Hearn wrote: > Nah, just leave the historical linear assignment as the default mode > of operation for the sake of POLA and document the knob for random > assignment in rc.conf.5 and wherever else might be appropriate. I don't suppose that this is a democracy, and that we can each vote for the default we want to have, can we? I can't speak for the "convenience" of having linear PID assignment (I just can't imagine a way that anyone could take advantage of this in a "good" way). However, I can say that there are a boatload of dain-bramaged scripts out there that I think would have their security measurably increased (even if by a small amount), if this option were turned on. Hell, I think just about every script I've ever written would fall in this category. ;-) My understanding was that we're trying to increase the default security level of the OS, and unless there were really big problems in changing the defaults for something that would help us towards this goal, we would go ahead and make the change (properly documented and instrumented, of course). I mean, we *are* talking about -CURRENT here, right? It's my understanding that anyone running -CURRENT has to expect that the thing won't be usable (heck, may not even compile) at any one particular point in time, and if they want to actually try to use -CURRENT, it's their responsibility to track the mailing list, CVS commit log, etc... and then do their own work to make the system usable -- and then provide those changes back to the community, so that others can benefit. Unless I'm missing something fundamental here, I don't see why we can't make changes of this scale. Much larger changes have been made to -CURRENT in the past, and I'm sure that much larger changes will be made to -CURRENT in the future. It seems to me that the sort of stuff we're talking about would fit into that same mold, and could even be more important than some of the really huge changes that have been made previously -- those were just functionality, whereas now we're talking about security. If we don't make the leap now to try to raise the default security level of the OS, then when are we? -- These are my opinions -- not to be taken as official Skynet policy ____________________________________________________________________ |o| Brad Knowles, Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 6 3:35: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 81A4E14CC3 for ; Mon, 6 Dec 1999 03:35: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 MAA25684 for ; Mon, 6 Dec 1999 12:35:22 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id MAA07424 for freebsd-arch@freebsd.org; Mon, 6 Dec 1999 12:35:21 +0100 (MET) Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id F2CDF14CC3; Mon, 6 Dec 1999 03:35:08 -0800 (PST) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.11 #1) id 11uwPu-0007Jz-00; Mon, 06 Dec 1999 13:34:54 +0200 From: Sheldon Hearn To: Brad Knowles Cc: obrien@freebsd.org, arch@freebsd.org, audit@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h In-reply-to: Your message of "Mon, 06 Dec 1999 12:28:15 +0100." Date: Mon, 06 Dec 1999 13:34:54 +0200 Message-ID: <28146.944480094@axl.noc.iafrica.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 06 Dec 1999 12:28:15 +0100, Brad Knowles wrote: > I mean, we *are* talking about -CURRENT here, right? It's my > understanding that anyone running -CURRENT has to expect that the > thing won't be usable One thing you're missing here is that CURRENT often _becomes_ STABLE later. :-) However, I think I agree with you. Perhaps a small POLA sacrifice for the sake of a large security gain is cool. I don't see a massive gain for day-to-day stuff myself, but folks are talking like it's a large gain. Some of them are sensible folks. ;-) Ciao, Sheldon. PS: Damnit, I didn't realize that the message I replied to originally was a cross-post. Sorry. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 6 4: 2:13 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id D06381522B for ; Mon, 6 Dec 1999 04:02:08 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id NAA26128 for ; Mon, 6 Dec 1999 13:02:04 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA07523 for freebsd-arch@freebsd.org; Mon, 6 Dec 1999 13:02:03 +0100 (MET) Received: from fgwmail7.fujitsu.co.jp (fgwmail7.fujitsu.co.jp [192.51.44.37]) by hub.freebsd.org (Postfix) with ESMTP id 3B69414F80; Mon, 6 Dec 1999 04:01:53 -0800 (PST) (envelope-from shin@nd.net.fujitsu.co.jp) Received: from m5.gw.fujitsu.co.jp by fgwmail7.fujitsu.co.jp (8.9.3/3.7W-MX9911-Fujitsu Gateway) id VAA23136; Mon, 6 Dec 1999 21:01:52 +0900 (JST) Received: from chisato.nd.net.fujitsu.co.jp by m5.gw.fujitsu.co.jp (8.9.3/3.7W-9911-Fujitsu Domain Master) id VAA11667; Mon, 6 Dec 1999 21:01:51 +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 VAA17770; Mon, 6 Dec 1999 21:01:51 +0900 (JST) To: asmodai@wxs.nl Cc: freebsd-arch@freebsd.org, cvs-committers@freebsd.org Subject: Re: [Solicite review for KAME 3rd patch] In-Reply-To: <19991204154807.G711@daemon.ninth-circle.org> References: <19991203050711F.shin@nd.net.fujitsu.co.jp> <19991204154807.G711@daemon.ninth-circle.org> 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: <19991206210212K.shin@nd.net.fujitsu.co.jp> Date: Mon, 06 Dec 1999 21:02:12 +0900 From: Yoshinobu Inoue X-Dispatcher: imput version 990905(IM130) Lines: 145 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hello Inoue-san, Hello Mr. Ruigrok, Thanks for your detailed comments. > All patches succeeded on a fresh CURRENT source tree except for: > > - sbin/ifconfig/Makefile > - sbin/route/Makefile > - usr.bin/netstat/Makefile > > no .rej file was made curiously enough. Patched by hand. Was your fix uncommenting #CFLAGS+=-DINET6 ? Then, I intentionally commented them out by default, because INET6 kernel config option is also not enabled by default. > sys/conf/files: > > I like the rearranging of the netinet options, it certainly clarifies > things. Thanks, though I'm a little bit uncertain where is the best place ipfilter related files should be put in. > sys/i386/conf/LINT: > > COMPATIBILITY OPTIONS seems to be a whitespace fix. Not needed IMHO. (and all comments about whitespaces) I exec'ed some script which do removing whitespaces and tabs at the end of each line and etc for all files I touched, in case I mistakenly put them. But, > My suggestion: checkout a new source tree and only modify that what you want to > change and ignore tab line-ups and concentrate on the functionality. White > space corrections are best done in cosmestic commits. I agree, I'll take care of whitespaces later. > Does the gif comment imply that IPv4 in IPv4, IPv4 in IPv6, IPv6 in > IPv4, IPv6 in IPv6 tunneling is supported? I think it does, but I > wonder if others might not understand the notation used. One more > comment line to clarify things from the start wouldn't hurt and would > save questions to -questions. Also, use `gif' instead of `gif`, minor > nitpick to remain consistent. OK, I updated the comment. > The `faith` pseudo-device catches those packets which sent to it, and > forwards then to IPv4 and IPv6 translating daemon. > > Should this be: > > The `faith' pseudo-device captures packets sent to it and forwards them > to the IPv4/IPv6 translation daemon. Thanks, I use it. > Although I wonder if forwards could be changed to divert. Is the word "divert" more natural? Then I change the description. > Something which I wonder about is the removal of opt_inet.h in if.c. > All other source files seem to retain their opt_inet.h alongside the > opt_inet6.h. Was this intentional? It was not included in the first place and add by last KAME patch, because INET6 was kept in opt_inet.h at that time and several INET6 related ifdefs was added to if.c. From this patch, INET6 is kept in opt_inet6.h, so opt_inet.h inclusion become unnecessary. > Does faith replace loop? If so, what is against adding the IPv6 > functionality to loop? Its if_type IFT_FAITH is also important. Packets catched by faith is put into ip6 input queue and processed by ip6_input() again. But this 2nd time input, it matches this check, and treated as 'ours'. if (ip6_forward_rt.ro_rt && ip6_forward_rt.ro_rt->rt_ifp && ip6_forward_rt.ro_rt->rt_ifp->if_type == IFT_FAITH) ours = 1; > Also, wouldn't it be better to follow INET6 directly after INET, since > both are effectively the same protocol, except a different version? > Just like you did with the #ifdef INET6 later on in this file. Later on > with the ETHERTYPE cases, you now position yourself between NS and > DECNET, why not follow directly after INET? Yes, I fixed it. > sometimes even revert the previous style(9) compliant code. Removal of > the $FreeBSD$ doesn't seem needed. It was my mistake. fixed it. > And the file suffers from continuous whitespace fixes. Find an update > of your patch at http://home.wxs.nl/~asmodai/udp-for-ipv6-fixed.19991203 This > update only fixes the whitespace problems for a couple files. I grew weary > after file 16 or so. Woops, sorry and great thanks. But just one point, I think this patch should be left, shouldn't it? -#if defined(INET) || defined(NS) || defined(DECNET) || defined(IPX) || defined(NETATALK) +#if defined(INET) || defined(INET6) || defined(NS) || defined(DECNET) || defined(IPX) || defined(NETATALK) > I compiled a world and got: > > cc -O -pipe -DKERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline - Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I/usr/obj/usr/src/sys/modules/if_disc -I/usr/obj/usr/src/sys/modules/if_disc/@ -mpreferred-stack-boundary=2 -c /usr/src/sys/modules/if_disc/../../net/if_disc.c /usr/src/sys/modules/if_disc/../../net/if_disc.c:55: opt_inet6.h: No such file or directory > *** Error code 1 > Stop in /usr/src/sys/modules/if_disc. That was also my mistake. I think I fixed it. > Hope this helps, Thanks very much again. When I cvs updated my environments I'll soon prepare new diff. (But freefall seems to be heavy now.) Yoshinobu Inoue > -- > Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl > The BSD Programmer's Documentation Project > Network/Security Specialist BSD: Technical excellence at its best > Learn e-mail netiquette: http://www.lemis.com/email.html > ...fools rush in where Daemons fear to tread. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 6 4:22: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 2DB9614FB0 for ; Mon, 6 Dec 1999 04:22: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 NAA26528 for ; Mon, 6 Dec 1999 13:22:54 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA07618 for freebsd-arch@freebsd.org; Mon, 6 Dec 1999 13:22:54 +0100 (MET) Received: from Thingol.KryptoKom.DE (Thingol.KryptoKom.DE [194.245.91.1]) by hub.freebsd.org (Postfix) with ESMTP id 8988A14FCE for ; Mon, 6 Dec 1999 04:22:41 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.org) Received: (from root@localhost) by Thingol.KryptoKom.DE (8.9.1/8.9.1) id NAA02810 for ; Mon, 6 Dec 1999 13:21:22 +0100 Received: from cirdan.kryptokom.de by KryptoWall via smtpp (Version 1.2.0) id kwa02748; Mon Dec 06 13:21:07 1999 Received: (from root@localhost) by Cirdan.KryptoKom.DE (8.9.1/8.8.8) id MAA24145; Mon, 6 Dec 1999 12:35:42 GMT Received: from Thingol.KryptoKom.DE (Thingol.KryptoKom.DE [192.168.6.1]) by Cirdan.KryptoKom.DE (8.9.1/8.8.8) with ESMTP id HAA12453 for ; Mon, 6 Dec 1999 07:58:54 GMT Received: (from root@localhost) by Thingol.KryptoKom.DE (8.9.1/8.9.1) id IAA24773 for ; Mon, 6 Dec 1999 08:44:19 +0100 Received: from baerenklau.de.freebsd.org by KryptoWall via smtpp (Version 1.2.0) id kwa24295; Mon Dec 06 08:44:06 1999 Received: from hub.freebsd.org (hub.FreeBSD.ORG [204.216.27.18]) by baerenklau.de.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA24096; Sun, 5 Dec 1999 21:27:00 +0100 (CET) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: by hub.freebsd.org (Postfix, from userid 538) id 785F71543F; Sun, 5 Dec 1999 12:25:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id 4D4551CD73E; Sun, 5 Dec 1999 12:25:13 -0800 (PST) (envelope-from owner-freebsd-security) Received: by hub.freebsd.org (bulk_mailer v1.12); Sun, 5 Dec 1999 12:25:13 -0800 Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id AF98514DCA; Sun, 5 Dec 1999 12:25:06 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id PAA06444; Sun, 5 Dec 1999 15:25:06 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Sun, 5 Dec 1999 15:25:05 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: freebsd-arch@freebsd.org Subject: ACL support: semantics vs. syntax in the context of multiple types of ACLs over multiple file systems in the VFS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I thought I'd send out an email to discuss some design issues in the implementation of ACL support for FreeBSD. As you probably know, I'm in the process of implementing support for POSIX.1e security extensions to FreeBSD, and this includes support for Access Control Lists for files and directories (and possibly other things :-). The design questions arise because access control, in most cases, is a per-file system design. In FFS, there are file owners, groups, permissions for them, and some additional extended flags. In Coda and AFS, directories have a more extended set of permissions, but individual files don't have individual access control restrictions. In POSIX.1e, ACL semantics define an ACL for each file, and two for each directory (an access ACL, and a default ACL for new children). To a large extent, these ACLs all have the same syntax: a (sometimes restricted) list of ids (of some kind), with a bitmask of rights associated with them. What differs is the exact definition of what the id's refer to, and what the rights are, as well as some restrictions on combinations of ids and rights, as well as ACL targets. This suggests a model wherein the operations exposed to the VFS (i.e., vop_getacl and vop_setacl) require a specific syntax, but leave the specific semantics to whatever layer of the file system stack receives the request. For example, FFS might choose to map ACL operations onto standard attributes/permissions, and only allow ACLs that fit the possible permissions in FFS. AFS might choose to interpret the id's in question as viceids, and the permission mask as AFS permissions. An ACLfs extension to FFS might choose the POSIX.1e semantics. This would leave it up to the calling program to choose the correct type of ACL when setting it for a file or directory, and the requested ACL would be rejected if it didn't match. This leaves opportunities for a number of problems, including confusion by the user, application of an ACL designed for one set of semantics on another set of semantics, etc. Also, it means that some of the POSIX.1e ACL calls (such as acl_valid()) now depend on the target, not just on the ACL itself as a data structure, introducing a lot of complexity. That said, this may be the only way to go. The vast majority of UNIX operating systems have selected either direct POSIX.1e ACL syntax + semantics, or closely related semantics/syntax, including Solaris, IRIX, HPUX, and Linux. But given the complexity of POSIX.1e ACL behavior, and the desire to support other ACL models (such as the intuitive and powerful AFS/Coda model), we would also rather not define a mechanism useful for only one set of semantics. As such, I'm suggesting moving from just vop_getacl and vop_setacl VOPs, to: VOP_ACLVALID(vp, acl, type) VOP_GETACL(vp, acl, type) VOP_SETACL(vp, acl, type) Where type continues to index into the set of available ACLs for the vnode (access, default, etc), and acl is the desired ACL. The acl_valid() POSIX.1e call, currently handled in the library, would now query the vnode it would be applied to to see if the vnode would accept the ACL. The existing POSIX.1e acl_valid() call would simply ask whatever the root file system was whether the ACL was valid for it, and would be depreciated in favor of acl_valid_file() and acl_valid_fd() with specific targets. Currently POSIX.1e defines an ACL entry as being made up of three parts -- an id, id qualifier, and permission set. The id identifies a principal, the qualifier, the namespace for the principal, and the permission set is the mask of rights. POSIX.1e defines several qualifier types, including ACL_USER_OBJ, ACL_USER, ACL_GROUP_OBJ, ACL_GROUP, ACL_OTHER, and ACL_MASK. I believe expanding this namespace is sufficient to take into account differing semantics, although I'm not sure. For example, we could add an ACL_AFS_ID to indicate that the ACL applied to an AFS viceid. Presumably AFS vnodes would reject ACLs with qualifiers other than this, and POSIX.1e file systems would reject AFS entries. Another alternative would be to introduce additional ACL types, but I think that is not intuitive, as the types are currently "access" and "default", and "access" has the same semantics in both POSIX.1e and AFS. The advantage of all this is removing complexity and semantics awareness in the syscall and vnops, but the disadvantage is increasing awareness of semantics in the library -- the awareness in the file system itself was always required. The library would now have to be aware of how to print and interpret text versions of differing ACL types. So when AFS was added, it would just be a kernel module, but also a libc update. We might consider pluggable file system components in libc, but I see that as a hard task to address correctly (although it might be desirable, especially given different principal namespaces and the desire to print principal names in ls -l, etc). I plan to go ahead and reimplement components of the current ACL code to reflect this goal of a semantics-unaware vnops and syscall interface (for example, acl_syscall_set_file will no longer check ACL validity, instead rely on the fs to do this), but would like comments on whether this model suits the needs of the various ACL interface consumers, such as FFS ACL people, AFS people, Coda people, and concerned parties :-). It would also mean we could make use of a better ACL scheme on our own file systems yet support Solaris or IRIX exported file systems with POSIX.1e, and also support the new NFSv4 ACL scheme which is different from any of those mentioned so far :-). I've BCC'd this -security because -security people are interested in ACLs, but it's probably discussion for -arch, so it's actually addressed there. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" 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 Mon Dec 6 8: 1: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 A961214E30 for ; Mon, 6 Dec 1999 08:01: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 RAA07379 for ; Mon, 6 Dec 1999 17:01:20 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA08984 for freebsd-arch@freebsd.org; Mon, 6 Dec 1999 17:01:19 +0100 (MET) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 2B2E814E30; Mon, 6 Dec 1999 08:01:07 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id LAA10811; Mon, 6 Dec 1999 11:00:59 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Mon, 6 Dec 1999 11:00:59 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Brad Knowles Cc: Sheldon Hearn , obrien@freebsd.org, arch@freebsd.org, audit@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h 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, 6 Dec 1999, Brad Knowles wrote: > At 12:53 PM +0200 1999/12/6, Sheldon Hearn wrote: > > > Nah, just leave the historical linear assignment as the default mode > > of operation for the sake of POLA and document the knob for random > > assignment in rc.conf.5 and wherever else might be appropriate. > > I don't suppose that this is a democracy, and that we can each > vote for the default we want to have, can we? > > > I can't speak for the "convenience" of having linear PID > assignment (I just can't imagine a way that anyone could take > advantage of this in a "good" way). > > However, I can say that there are a boatload of dain-bramaged > scripts out there that I think would have their security measurably > increased (even if by a small amount), if this option were turned on. > Hell, I think just about every script I've ever written would fall in > this category. ;-) An interesting, although perhaps not useful, observation is that an attacker can easily coerce linear PID allocation to non-linear allocation, even without an account on the machine. Most daemons are quite happy to fork children with little provocation (i.e., a connection) and this chews through the PID space. Similarly, given an account, they can run #include while (1) if (fork()) exit(0); So it's clear that nothing should *rely* on linear allocation if it's going to resist disruption as the result of an attack. On the other hand, it has usefully been observed that poorly written scripts (over which we have no control, so can't fix) have been vulnerable as a result of predictable PID allocation--and while we can force non-linear PID allocation, there is no way for us to force linear allocation :-). I vote yes on this change (not that it's a democracy). On any busy system, especially an SMP machine, linear allocation of PIDs is an unsafe assumption, even during the boot process where, for example, named will spawn off an indefinite number of named-xfers based on third party changes to zone files, or where sendmail (and even route add default) are willing to block based on network conditions (name lookup availability), screwing around with ordering of events. For most debugging purposes, /var/run/whatever.pid, the PPID entry, and accounting (if desired) are quite adequate replacements. And there's always killall :-). Robert To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 6 12:12:16 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 48E7F156C0 for ; Mon, 6 Dec 1999 12:12: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 VAA09862 for ; Mon, 6 Dec 1999 21:12:13 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA09943 for freebsd-arch@freebsd.org; Mon, 6 Dec 1999 21:12:12 +0100 (MET) Received: from fgwmail9.fujitsu.co.jp (fgwmail9.fujitsu.co.jp [192.51.44.39]) by hub.freebsd.org (Postfix) with ESMTP id 3EFCE15501; Mon, 6 Dec 1999 11:22:19 -0800 (PST) (envelope-from shin@nd.net.fujitsu.co.jp) Received: from fgwmail5.fujitsu.co.jp by fgwmail9.fujitsu.co.jp (8.9.3/3.7W-MX9912-Fujitsu Gateway) id DAA09023; Tue, 7 Dec 1999 03:06:35 +0900 (JST) Received: from m5.gw.fujitsu.co.jp by fgwmail5.fujitsu.co.jp (8.9.3/3.7W-MX9911-Fujitsu Gateway) id DAA23942; Tue, 7 Dec 1999 03:03:24 +0900 (JST) Received: from incapgw.fujitsu.co.jp by m5.gw.fujitsu.co.jp (8.9.3/3.7W-9911-Fujitsu Domain Master) id DAA09839; Tue, 7 Dec 1999 03:03:24 +0900 (JST) Received: from localhost ([192.168.245.47]) by incapgw.fujitsu.co.jp (8.9.3/3.7W-9911) id DAA13095; Tue, 7 Dec 1999 03:03:22 +0900 (JST) To: freebsd-arch@freebsd.org, cvs-committers@freebsd.org Subject: Re: [Solicite review for KAME 3rd patch] In-Reply-To: <19991206210212K.shin@nd.net.fujitsu.co.jp> References: <19991203050711F.shin@nd.net.fujitsu.co.jp> <19991204154807.G711@daemon.ninth-circle.org> <19991206210212K.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: <19991207030343N.shin@nd.net.fujitsu.co.jp> Date: Tue, 07 Dec 1999 03:03:43 +0900 From: Yoshinobu Inoue X-Dispatcher: imput version 990905(IM130) Lines: 10 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I reflected comments and prepared an updated patches below. http://paradise.kame.net/v6proxy/diana2/shin/work/freebsd/udp-for-ipv6-etc.19991207 If someone find any time consuming problems, please just let me know and I'll fix them. 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 Mon Dec 6 15:24:48 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 5EEB41505F for ; Mon, 6 Dec 1999 15:24: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 AAA12303 for ; Tue, 7 Dec 1999 00:24:39 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA11621 for freebsd-arch@freebsd.org; Tue, 7 Dec 1999 00:24:38 +0100 (MET) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 4806D1505F; Mon, 6 Dec 1999 15:21:10 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id SAA13228; Mon, 6 Dec 1999 18:21:16 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Mon, 6 Dec 1999 18:21:16 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: freebsd-arch@freebsd.org Subject: Extended File Attributes for FFS (request for design comments) 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 Adding trusted operating system behavior (MAC, Capabilities, ACLs, etc) to FreeBSD requires that additional state be maintained for files and directories. For example, in POSIX.1e, an ACL is maintained for each file, and two for directories. Similarly, a MAC label is required for each file and directory in the file system. This, of course, raises the issue of where to keep this data. Various operating systems take various approaches -- I posted a fairly comprehensive list of OS choices on the posix1e mailing list a couple of months ago while looking for a solution. They vary from extra block pointers, additional inodes, userland databases with upcalls, etc. The cleanest solution, in my view, was the IRIX XFS extended attribute code. Named extended attributes are defined for each inode, and may contain arbitrary information. Needless to say, there is performance overhead associated with this approach, but it seemed the most flexible from a new feature standpoint, and still allowed for optimization, etc. As such, I'd like to suggest a similar mechanism for our VFS, along with a hacky implementation for FFS that is sufficient to back the ACL, Capability, and MAC support until we have functioning layering. Even after layering, the VFS vnops still need expanding to support this functionality, so that would stick around. Two new vnops would be introduced for managing extended attributs: vop_setextattr(vp, name, buffer, len) Set an extended attribute: vp vnode pointer to set attribute for name attribute to set buffer data for attribute value len length of data Returns 0 on success, otherwise an error. buffer of size len must fit into the preconfigured attribute size. vop_getextattr(vp, name, buffer, &len) Get an extended attribute: vp vnode pointer to get attribute fur name attribute to get buffer buffer for data len input: length of buffer; output: length of data Returns 0 on success, otherwise an error. buffer of size len must be able to hold all of preconfigured attribute size, or an error will be returned. My assumption is that these attributes would be of fixed size, and a predetermined maximum size. This is consistent with the various security attributes we've looked at, and some of the none-security uses of attributes. Each file/directory would have a set of named attributes, settable and retrievable using this interface. Decent names might include EXTATTR_ACL_ACCESS, EXTATTR_ACL_DEFAULT, EXTATTR_MAC_LABEL, etc. You can easily imagine backing this with a layered fs implementation on top of FFS--for example, an ACLfs that converts get/set ACL calls to extended attribute calls, and hooks open(/etc) to make use of the ACLs for access control (this is very similar to work done by Jeff Weidner at UCLA as part of the layering work). However, the ACL code is ready to go today, and needs backing to get it to work, so waiting for layering is probably not an option. As an interim solution, I'd like to implement an attribute solution for UFS (and hence FFS, MFS) which, like quotas, makes use of files off of the file system root. Each named attribute would be backed by a file attribute/name, and effectively be an array of attribute data, indexed by inode number. Hooks, as with quotas, would be stuck in inode allocation and freeing, etc. ACL calls on UFS would be converted, within UFS, to attribute calls, etc. This solution is not as clean as the layering solution, but would be relatively quick to implement. This raises questions such as how to runtime configure support for attributes, ACLs, etc. My guess is that a mount flag, extattr, would be defined to enable support for extended attributes, and automatic loading of attribute data from attributes/ off of the fs root. It might be desirable to seperately enable ACL support (and so on) via other flags, although this is less clean. Quota's define a quotactl syscall/vop to manage UFS quota behavior, but that seems not-so-general. I'm not sure that there is currently a mechanism to push configuration information down the VFS stacks to specific file systems, other than the mount info. One possibility would be to add a control MIB of some kind and a management call in VFS, or just to use sysctl and go outside the framework of VFS. These areas where I'd much appreciate comments. I would like to start implementing this later this week, starting with VFS calls (the above are my proposed prototypes, but suggestions are welcome) followed by a UFS implementation RSN so that we can back ACLs, Capabilities, and MAC onto it and make some more progress in getting these working. Thanks, Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 6 16:28: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 640D6150BA for ; Mon, 6 Dec 1999 16:28: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 BAA12935 for ; Tue, 7 Dec 1999 01:28:00 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA11877 for freebsd-arch@freebsd.org; Tue, 7 Dec 1999 01:27:59 +0100 (MET) Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 88FE6150BA for ; Mon, 6 Dec 1999 16:27:46 -0800 (PST) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id RAA26439; Mon, 6 Dec 1999 17:27:37 -0700 (MST) Message-Id: <4.2.0.58.19991206172414.03e973a0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 06 Dec 1999 17:27:35 -0700 To: Robert Watson , freebsd-arch@freebsd.org From: Brett Glass Subject: Re: Extended File Attributes for FFS (request for design comments) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I seem to recall that HP/UX does something very much like what you describe. (Actually, they get even fancier; they can cause you to open or see a DIFFERENT FILE depending on what architecture you're running. This trickery is done via environment variables.) Their file system extensions might be worth a look. --Brett At 04:21 PM 12/6/1999 , Robert Watson wrote: >Adding trusted operating system behavior (MAC, Capabilities, ACLs, etc) to >FreeBSD requires that additional state be maintained for files and >directories. For example, in POSIX.1e, an ACL is maintained for each >file, and two for directories. Similarly, a MAC label is required for >each file and directory in the file system. This, of course, raises the >issue of where to keep this data. > >Various operating systems take various approaches -- I posted a fairly >comprehensive list of OS choices on the posix1e mailing list a couple of >months ago while looking for a solution. They vary from extra block >pointers, additional inodes, userland databases with upcalls, etc. The >cleanest solution, in my view, was the IRIX XFS extended attribute code. >Named extended attributes are defined for each inode, and may contain >arbitrary information. Needless to say, there is performance overhead >associated with this approach, but it seemed the most flexible from a new >feature standpoint, and still allowed for optimization, etc. As such, I'd >like to suggest a similar mechanism for our VFS, along with a hacky >implementation for FFS that is sufficient to back the ACL, Capability, and >MAC support until we have functioning layering. Even after layering, the >VFS vnops still need expanding to support this functionality, so that >would stick around. > >Two new vnops would be introduced for managing extended attributs: > >vop_setextattr(vp, name, buffer, len) > >Set an extended attribute: > vp vnode pointer to set attribute for > name attribute to set > buffer data for attribute value > len length of data > >Returns 0 on success, otherwise an error. buffer of size len must >fit into the preconfigured attribute size. > >vop_getextattr(vp, name, buffer, &len) > >Get an extended attribute: > vp vnode pointer to get attribute fur > name attribute to get > buffer buffer for data > len input: length of buffer; output: length of data > >Returns 0 on success, otherwise an error. buffer of size len must be >able to hold all of preconfigured attribute size, or an error will be >returned. > > >My assumption is that these attributes would be of fixed size, and a >predetermined maximum size. This is consistent with the various security >attributes we've looked at, and some of the none-security uses of >attributes. Each file/directory would have a set of named attributes, >settable and retrievable using this interface. Decent names might include >EXTATTR_ACL_ACCESS, EXTATTR_ACL_DEFAULT, EXTATTR_MAC_LABEL, etc. > >You can easily imagine backing this with a layered fs implementation on >top of FFS--for example, an ACLfs that converts get/set ACL calls to >extended attribute calls, and hooks open(/etc) to make use of the ACLs for >access control (this is very similar to work done by Jeff Weidner at UCLA >as part of the layering work). > >However, the ACL code is ready to go today, and needs backing to get it to >work, so waiting for layering is probably not an option. As an interim >solution, I'd like to implement an attribute solution for UFS (and hence >FFS, MFS) which, like quotas, makes use of files off of the file system >root. Each named attribute would be backed by a file attribute/name, and >effectively be an array of attribute data, indexed by inode number. >Hooks, as with quotas, would be stuck in inode allocation and freeing, >etc. ACL calls on UFS would be converted, within UFS, to attribute calls, >etc. This solution is not as clean as the layering solution, but would be >relatively quick to implement. > >This raises questions such as how to runtime configure support for >attributes, ACLs, etc. My guess is that a mount flag, extattr, would be >defined to enable support for extended attributes, and automatic loading >of attribute data from attributes/ off of the fs root. It might be >desirable to seperately enable ACL support (and so on) via other flags, >although this is less clean. Quota's define a quotactl syscall/vop to >manage UFS quota behavior, but that seems not-so-general. I'm not sure >that there is currently a mechanism to push configuration information down >the VFS stacks to specific file systems, other than the mount info. One >possibility would be to add a control MIB of some kind and a management >call in VFS, or just to use sysctl and go outside the framework of VFS. > >These areas where I'd much appreciate comments. I would like to start >implementing this later this week, starting with VFS calls (the above are >my proposed prototypes, but suggestions are welcome) followed by a UFS >implementation RSN so that we can back ACLs, Capabilities, and MAC onto it >and make some more progress in getting these working. > >Thanks, > > Robert N M Watson > >robert@fledge.watson.org http://www.watson.org/~robert/ >PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 >TIS Labs at Network Associates, Safeport Network Services > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-security" 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 Mon Dec 6 20:15: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 DAE5D14BE7 for ; Mon, 6 Dec 1999 20:15:24 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id FAA15367 for ; Tue, 7 Dec 1999 05:15:22 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA12741 for freebsd-arch@freebsd.org; Tue, 7 Dec 1999 05:15:21 +0100 (MET) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 60BBF14BE7 for ; Mon, 6 Dec 1999 20:13:33 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id XAA14146; Mon, 6 Dec 1999 23:13:15 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Mon, 6 Dec 1999 23:13:15 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Brett Glass Cc: freebsd-arch@freebsd.org Subject: Re: Extended File Attributes for FFS (request for design comments) In-Reply-To: <4.2.0.58.19991206172414.03e973a0@localhost> 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, 6 Dec 1999, Brett Glass wrote: > I seem to recall that HP/UX does something very much like what you describe. > (Actually, they get even fancier; they can cause you to open or see a > DIFFERENT FILE depending on what architecture you're running. This trickery > is done via environment variables.) > > Their file system extensions might be worth a look. My understanding is that TRIX (Trusted IRIX) and some other trusted operating systems play namespace games to maintain the MAC properties of publically writable directories (i.e., a "SECRET" vs. "TOPSECRET" tmp dir), but that the namespace tricks are not part of the attribute functionality, but instead a property of special symlinks (or the like), not unlike the AFS @sys behavior. I believe there was an extensive discussion of the costs/merits of namespace games on -CURRENT last year sometime, but that the idea was rejected for various reasons. It should be noted that this attribute behavior does not introduce significant cost in the cases where it is not used--only a boolean if check + pointer dereference, most likely. And you could even compile out all the codepaths if desired (#ifdef UFS_EXT_ATTR). Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 6 23: 1: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 D0D3C14CA2 for ; Mon, 6 Dec 1999 23:01: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 IAA16360 for ; Tue, 7 Dec 1999 08:01:17 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA13165 for freebsd-arch@freebsd.org; Tue, 7 Dec 1999 08:01:16 +0100 (MET) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id B529E14CA2 for ; Mon, 6 Dec 1999 23:01:09 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id CAA14799; Tue, 7 Dec 1999 02:01:14 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Tue, 7 Dec 1999 02:01:14 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Michael Schuster - TSC SunOS Germany Cc: freebsd-arch@freebsd.org Subject: Re: Extended File Attributes for FFS (request for design comments) In-Reply-To: <384CACF3.4A55658C@germany.sun.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 (CC'ing this out onto the list because others have mentioned the same thing) On Tue, 7 Dec 1999, Michael Schuster - TSC SunOS Germany wrote: > Robert Watson wrote: > > > My assumption is that these attributes would be of fixed size, and a > > predetermined maximum size. > > Robert, I'm folowing this with half an ear, so to speak, so I may have > missed what I'm asking now: I don't quite see how you can get a > reasonable maximum for ACLs, seeing that you can have any number of them > for any given file (I'd wager you could say the same for other extended > attributes as well, I can't think of one just now ...). > Am I missing something elementary here? If not, I feel we might be > artificially and unnecessarily limiting ourselves before we actually get > started ... > My idea would be a kind of (type,length,value) tuple, a bit like > directory entries. Michael, The same issue came up on the #bsdcode irc channel this evening when I logged in for a bit to gather comments. The question is really whether or not extended attributes should be more or less capable. The problem with making them too strong is that you end up implementing (as you observe) something very much like the directory/file relationship. I was probably not entirely clear about how the limitation would work. I propose that there be (effectively) unlimited possible attributes for a given file/directory, as attribute names are handled via a filename off of the fs root (in the case of UFS/FFS). However, the value portion of the name=value component of the attribute would have a fixed size for each instance. So, for example, when the acl_access attribute was declared for /usr, a maximum size would be declared for any entry for any file with that attribute. My struct acl is 388 bytes, so that would make a good choice (most ACL implementations, except solaris, limit ACL entries to some fixed number of entries). For attribute capabilities, it might be 24 bytes, etc. The goal is to optimize for lookup performance on the attribute--it's acceptable to have a moderately costly setextattr, as long as getextattr is real fast, at least in the case of MAC labels, Capabilities, and ACLs. The ACLs will be hit for each vop_access(), which for directory trees can be pretty frequently. All of the attributes I'm looking at have a fixed size, which is nice. Supporting a fully-fledged file fork approach to attributes was discussed the evening, but I think there was concensus that this service is provided by the directory system already: if you want n named address spaces, you really want a directory with n files with those names, not a file with n forks. Using a fixed maximum size allows the UFS implemention to resemble the quota implementation: treat the attribute storage file as an array of fixed-size structures, and index into it based on inode number. If refcounting is desired (courtesy DCS), then you can do an indirection scheme and just store hashes in this, indirecting to some other storage file for the details. The first pass implementation will probably just store everything directly in the attribute file with the attribute name, just for simplicity and correctness. I guess the key question would be: are there any generally agreed upon legitimate applications for the use of a completely general attribute mechanism (i.e., no fixed size limit on the attribute values)? If so, then the fixed size limit (the feature that's hit on the most objections when it comes to designing a general-purpose mechanism) needs to be rethought. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 6 23:13: 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 5046E15213 for ; Mon, 6 Dec 1999 23:12: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 IAA16456 for ; Tue, 7 Dec 1999 08:12:57 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA13225 for freebsd-arch@freebsd.org; Tue, 7 Dec 1999 08:12:56 +0100 (MET) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id A4CF014CA2 for ; Mon, 6 Dec 1999 23:12:47 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id CAA14875 for ; Tue, 7 Dec 1999 02:12:54 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Tue, 7 Dec 1999 02:12:54 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: freebsd-arch@freebsd.org Subject: Extended Attributes: a few more calls and more details 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 It became clear in #bsdcode discussion that the interface I recommended didn't provide all of the bootstrapping information people needed to understand my intent. As such, I suggested a couple of vfs calls, similar to quotactl, for initalizing and managing attributes: vfs_extattr_create(mount, name, size, access) This would create a new attribute of fixed size size in the specified file system. Access would be an indicator of who was allowed to modify the values of these attributes--useful values considered so far have been "kernel only" vs. "file owner". Would fail if it already existed, or something nasty went wrong :-). vfs_extattr_delete(mount, name) Delete the specified attribute and recover all space associated with storing that attribute, stripping the values from all files. Only works if it existed :-). To set up a UFS file system for quotas, you'd want to do (hypothetical user command line util): chattr create /usr name="acl_access" size=388 access="kernel" chattr creaet /usr name="acl_default" size=388 access="kernel" And remove the support later: chattr delete /usr name="acl_access" chattr delete /usr name="acl_default" This would be a bad idea while ACLs are active on the fs, however. You can imagine some other useful ones, such as name="mac_label", name="capabilities", name="tripwire_md5", name="dumpstate", name="mime_type", etc. The intent of these attributes would be to provide local system support for fs-oriented features, not to provide a broader-than-flat-file semantic for the file system (such as file forks) for user applications. This would mean "don't put icons here", and "don't make files that contain both HTML and text versions this way". Instead it would be for optimized, consistently-sized per-file/per-directory meta data of a systems nature. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 7 0: 6:52 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 549D814E1C for ; Tue, 7 Dec 1999 00: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 JAA17070 for ; Tue, 7 Dec 1999 09:06:23 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id JAA13370 for freebsd-arch@freebsd.org; Tue, 7 Dec 1999 09:06:21 +0100 (MET) Received: from orange.kame.net (orange.kame.net [203.178.141.194]) by hub.freebsd.org (Postfix) with ESMTP id 1E18D14E1C; Tue, 7 Dec 1999 00:04:01 -0800 (PST) (envelope-from shin@nd.net.fujitsu.co.jp) Received: from localhost (kame211.kame.net [203.178.141.211]) by orange.kame.net (8.9.1+3.1W/3.7W) with ESMTP id RAA05314; Tue, 7 Dec 1999 17:03:51 +0900 (JST) To: asmodai@wxs.nl Cc: guido@freebsd.org Cc: freebsd-arch@freebsd.org, cvs-committers@freebsd.org Subject: Re: [Solicite review for KAME 3rd patch] In-Reply-To: <19991206195341.B11220@daemon.ninth-circle.org> References: <19991204154807.G711@daemon.ninth-circle.org> <19991206210212K.shin@nd.net.fujitsu.co.jp> <19991206195341.B11220@daemon.ninth-circle.org> 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: <19991207170413J.shin@nd.net.fujitsu.co.jp> Date: Tue, 07 Dec 1999 17:04:13 +0900 From: Yoshinobu Inoue X-Dispatcher: imput version 990905(IM130) Lines: 85 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >Then, I intentionally commented them out by default, because > >INET6 kernel config option is also not enabled by default. > > Well, a make world shouldn't be dying from lack of specifying INET6. I confirmed that now make world won't stop even if INET6 is not defined at user-land, after the updated patch. > 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. I don't know any automatic way, but how about putting CFLAGS= -DINET6 [and any other things needed] into /etc/make.conf when someone want to use IPv6, before make world?, and if there is any apps which overwrites CFLAGS, to fix them? > >Thanks, though I'm a little bit uncertain where is the best > >place ipfilter related files should be put in. > > Please ask Guido van Rooij about this. I am uncertain about the file re-order rule in sys/conf/files. Now they seems to be ordered alphabetically, but if ipfilter related files are re-ordered alphabetically, they are dispersed. > >> The `faith' pseudo-device captures packets sent to it and forwards them > >> to the IPv4/IPv6 translation daemon. > > > >Thanks, I use it. > > Only if what I said is what it really does of course. Looking through > the sources I think my description matches or at least comes close. > (Which is of course based on your description.) I feel your description more natural, and matches what faith does. > >> Does faith replace loop? If so, what is against adding the IPv6 > >> functionality to loop? > > > >Its if_type IFT_FAITH is also important. > > Aha, so we have loop and faith, which both provide the same > functionality. Is the functionality _EXACT_ the same and does it differ > only in terms of IPv6 support or does it differ even more aside from > that. That wasn't too clear to me. I think they are exactly same other than their if_type and mtu size. Then, we might only need faithattach() function and let it set, ifp->if_ioctl = loioctl; ifp->if_output = looutput; Is that what you are thinking of? > Aha, so the true difference is the reprocessing of previously matched > packets? Yes, exactly. > Inoue-san, feel free to mail me when your new patches are done as I am > very eager to help getting KAME intergrated as fast as possible without > too many hick-ups. > > Kind regards, Thanks. I already sent my new patches announce, but I'll fix if_faith.c and create another patch. 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 Tue Dec 7 2:27: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 2E26514FAA for ; Tue, 7 Dec 1999 02:27:29 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id LAA19541 for ; Tue, 7 Dec 1999 11:27:27 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id LAA13825 for freebsd-arch@freebsd.org; Tue, 7 Dec 1999 11:27:12 +0100 (MET) Received: from frosch.all.de (frosch.all.de [212.42.242.2]) by hub.freebsd.org (Postfix) with ESMTP id E332114FAA for ; Tue, 7 Dec 1999 02:27:01 -0800 (PST) (envelope-from wagner@luthien.iceflower.in-berlin.de) Received: by frosch.all.de (8.9.3/nora-19990817) with UUCP (envelope-from wagner@luthien.iceflower.in-berlin.de) id LAA48661; Tue, 7 Dec 1999 11:26:55 +0100 (CET) Received: (from wagner@localhost) by luthien.iceflower.in-berlin.de (8.9.3/8.8.3) id LAA28173; Tue, 7 Dec 1999 11:23:24 +0100 (MET) Date: Tue, 7 Dec 1999 11:23:24 +0100 (MET) From: Olaf Wagner Message-Id: <199912071023.LAA28173@luthien.iceflower.in-berlin.de> To: freebsd-arch@freebsd.org Cc: Robert Watson Subject: Re: ACL support: semantics vs. syntax in the context of multiple types of ACLs over multiple file systems in the VFS X-Newsgroups: luthien.freebsd.arch In-Reply-To: Organization: 'Holistic Computing Services' User-Agent: tin/pre-1.4-19990216 ("Styrofoam") (UNIX) (FreeBSD/3.3-RC (i386)) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you wrote: > This suggests a model wherein the operations exposed to the VFS (i.e., > vop_getacl and vop_setacl) require a specific syntax, but leave the > specific semantics to whatever layer of the file system stack receives the > request. For example, FFS might choose to map ACL operations onto > standard attributes/permissions, and only allow ACLs that fit the possible > permissions in FFS. AFS might choose to interpret the id's in question as > viceids, and the permission mask as AFS permissions. An ACLfs extension > to FFS might choose the POSIX.1e semantics. This would leave it up to the > calling program to choose the correct type of ACL when setting it for a > file or directory, and the requested ACL would be rejected if it didn't > match. This leaves opportunities for a number of problems, including > confusion by the user, application of an ACL designed for one set of > semantics on another set of semantics, etc. Also, it means that some of > the POSIX.1e ACL calls (such as acl_valid()) now depend on the target, not > just on the ACL itself as a data structure, introducing a lot of > complexity. [...] > That said, this may be the only way to go. The vast majority of UNIX > operating systems have selected either direct POSIX.1e ACL syntax + > semantics, or closely related semantics/syntax, including Solaris, IRIX, > HPUX, and Linux. But given the complexity of POSIX.1e ACL behavior, and > the desire to support other ACL models (such as the intuitive and powerful > AFS/Coda model), we would also rather not define a mechanism useful for > only one set of semantics. [...] > As such, I'm suggesting moving from just vop_getacl and vop_setacl VOPs, > to: > VOP_ACLVALID(vp, acl, type) > VOP_GETACL(vp, acl, type) > VOP_SETACL(vp, acl, type) > Currently POSIX.1e defines an ACL entry as being made up of three parts -- > an id, id qualifier, and permission set. The id identifies a principal, > the qualifier, the namespace for the principal, and the permission set is > the mask of rights. POSIX.1e defines several qualifier types, including > ACL_USER_OBJ, ACL_USER, ACL_GROUP_OBJ, ACL_GROUP, ACL_OTHER, and ACL_MASK. > I believe expanding this namespace is sufficient to take into account > differing semantics, although I'm not sure. For example, we could add an > ACL_AFS_ID to indicate that the ACL applied to an AFS viceid. Presumably > AFS vnodes would reject ACLs with qualifiers other than this, and POSIX.1e > file systems would reject AFS entries. Another alternative would be to > introduce additional ACL types, but I think that is not intuitive, as the > types are currently "access" and "default", and "access" has the same > semantics in both POSIX.1e and AFS. The standard object oriented solution for the problem you describe would be to define an ACL as an `abstract type' or an `interface', and to rely on specialized implementations of some well-defined functions for everything that is different between different types of ACLs. Now of course C is no object oriented language, but can nonetheless be used to implement object oriented concepts (the vnode fs layer is an example). The crucial point is of course the definition of the `common' interface (including the semantics) of all ACL types. As I don't really know the POSIX standard for ACLs I can of course not be sure if it is flexible enough to allow for the mentioned kind of object oriented implementation, but I would give it at least a try. In your place I would try to define a specification for all concrete types of ACL you can now imagine, considering that you are implementing abstract data types where all methods handling the data need to be contained in one module. All methods of the module (except the generation method (e.g. new_afs_acl)) would of course get a pointer to an appropriate type of ACL object as their first parameter. Then abstract the common parts into one generic ACL module, and leave the different implementations as virtual functions, that are called via a jump table. The abstract definition of a generic ACL must of course include a pointer to such a jump table, i.e. a reference to the concrete implementations of virtual methods. If you want to make the representation of an ACL public, you can do so by defining the generic part as a structure in the generic module, and extending the structure for every concrete implementation. All generation methods of ACL modules will return an extended, concrete representation of an ACL. In this way you can keep all the ACL specific stuff in one module (that can be loaded on demand) and refer all operations that need knowledge of the specific parts to the correct module (by use of abstract interfaces). To make your implementation more robust, you can also add magic numbers or type ids to all ACL objects, and implement appropriate checks at the start of every operation. I know it's a lot of work to realize an oo design in C, but at certain places the efforts are worth it and rewarded with a flexible and extensible system. I hope I haven't bored you with things that were clear to you from the beginning and not what you were really asking for, but the solution seemed so obvious and classical to me that I couldn't resist. -- /\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ || Olaf Wagner | wagner@luthien.in-berlin.de (private) | || Cranachstrasse 7 | wagner@elego.de (business) | || D-12157 Berlin | phone: +49 30 85 60 26 70 | || Germany / Deutschland | fax: +49 30 85 60 26 71 | \///////////////////////////////////////////////////////////////// To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 7 2:34:10 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 22F5214E32 for ; Tue, 7 Dec 1999 02:34:07 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id LAA19636 for ; Tue, 7 Dec 1999 11:34:06 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id LAA13863 for freebsd-arch@freebsd.org; Tue, 7 Dec 1999 11:34:06 +0100 (MET) Received: from orange.kame.net (orange.kame.net [203.178.141.194]) by hub.freebsd.org (Postfix) with ESMTP id 145B114FAA; Tue, 7 Dec 1999 02:33:46 -0800 (PST) (envelope-from shin@nd.net.fujitsu.co.jp) Received: from localhost (kame211.kame.net [203.178.141.211]) by orange.kame.net (8.9.1+3.1W/3.7W) with ESMTP id TAA06542; Tue, 7 Dec 1999 19:33:41 +0900 (JST) To: asmodai@wxs.nl Cc: freebsd-arch@freebsd.org, cvs-committers@freebsd.org Subject: Re: [Solicite review for KAME 3rd patch] In-Reply-To: <19991207170413J.shin@nd.net.fujitsu.co.jp> References: <19991206210212K.shin@nd.net.fujitsu.co.jp> <19991206195341.B11220@daemon.ninth-circle.org> <19991207170413J.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: <19991207193403K.shin@nd.net.fujitsu.co.jp> Date: Tue, 07 Dec 1999 19:34:03 +0900 From: Yoshinobu Inoue X-Dispatcher: imput version 990905(IM130) Lines: 11 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I already sent my new patches announce, but I'll fix > if_faith.c and create another patch. This is updated one. http://paradise.kame.net/v6proxy/diana2/shin/work/freebsd/udp-for-ipv6-etc.19991207a The change from previous one is that sys/net/if_faith.c share some of sys/net/if_loop.c code. Yoshinobu Inoue To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 7 7: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 3A0EF152B9 for ; Tue, 7 Dec 1999 07:33: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 QAA25295 for ; Tue, 7 Dec 1999 16:33:02 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA15655 for freebsd-arch@freebsd.org; Tue, 7 Dec 1999 16:33:02 +0100 (MET) Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36]) by hub.freebsd.org (Postfix) with ESMTP id EB8C3152CE; Tue, 7 Dec 1999 07:32:33 -0800 (PST) (envelope-from shin@nd.net.fujitsu.co.jp) Received: from m5.gw.fujitsu.co.jp by fgwmail6.fujitsu.co.jp (8.9.3/3.7W-MX9911-Fujitsu Gateway) id AAA18361; Wed, 8 Dec 1999 00:32:28 +0900 (JST) Received: from incapgw.fujitsu.co.jp by m5.gw.fujitsu.co.jp (8.9.3/3.7W-9911-Fujitsu Domain Master) id AAA28062; Wed, 8 Dec 1999 00:32:28 +0900 (JST) Received: from localhost ([192.168.245.145]) by incapgw.fujitsu.co.jp (8.9.3/3.7W-9911) id AAA08122; Wed, 8 Dec 1999 00:32:16 +0900 (JST) To: freebsd-arch@freebsd.org, cvs-committers@freebsd.org Subject: [Solicite review for KAME 4th patch] In-Reply-To: <19991207193403K.shin@nd.net.fujitsu.co.jp> References: <19991206195341.B11220@daemon.ninth-circle.org> <19991207170413J.shin@nd.net.fujitsu.co.jp> <19991207193403K.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: <19991208003232E.shin@nd.net.fujitsu.co.jp> Date: Wed, 08 Dec 1999 00:32:32 +0900 From: Yoshinobu Inoue X-Dispatcher: imput version 990905(IM130) Lines: 20 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > This is updated one. > > http://paradise.kame.net/v6proxy/diana2/shin/work/freebsd/udp-for-ipv6-etc.19991207a > > The change from previous one is that sys/net/if_faith.c share > some of sys/net/if_loop.c code. If people don't have any big comment for this, I would like to commit this. And now I have another user-land patch. Comments please. http://paradise.kame.net/v6proxy/diana2/shin/work/freebsd/libc_net.19991208 This is IPv6 specific functions addition to lib/libc/net, but no resolver related updates yet. So I think this is not harmful. Yoshinobu Inoue To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 8 15:19:12 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 19AFE1524E for ; Wed, 8 Dec 1999 15:19: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 AAA18493 for ; Thu, 9 Dec 1999 00:19:03 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA24671 for freebsd-arch@freebsd.org; Thu, 9 Dec 1999 00:19:02 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id A2AF61527F for ; Wed, 8 Dec 1999 15:18:22 -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 PAA67652 for ; Wed, 8 Dec 1999 15:18:20 -0800 (PST) Date: Wed, 8 Dec 1999 15:18:19 -0800 (PST) From: Julian Elischer To: freebsd-arch@freebsd.org Subject: Threads discussion 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 is not dead.. we're all catching our breath! Tomorrow at the Bay Area Freebsd Users Group (BAFUG) there will be a food fight over threads kernel support. Anyone within driving range is urged to attend. I'll be there, as will Matt, Terry, and Jason. Pizza wil be surved as per ususal and there is mucho parking. (At whistle) Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 8 16:35: 2 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 26DDE1520D for ; Wed, 8 Dec 1999 16:35: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 BAA19136 for ; Thu, 9 Dec 1999 01:34:57 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA25019 for freebsd-arch@freebsd.org; Thu, 9 Dec 1999 01:34:56 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id D645115219 for ; Wed, 8 Dec 1999 16:34:42 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt94.pcnet.net [206.105.29.168]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id TAA02146; Wed, 8 Dec 1999 19:34:30 -0500 (EST) Message-ID: <384EF8CB.D83F47EB@vigrid.com> Date: Wed, 08 Dec 1999 19:33:15 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Threads discussion 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: > > is not dead.. we're all catching our breath! > > Tomorrow at the Bay Area Freebsd Users Group (BAFUG) > there will be a food fight over threads kernel support. > Anyone within driving range is urged to attend. Hey, this isn't fair! > I'll be there, as will Matt, Terry, and Jason. If I wasn't 2700 miles away, I'd be there too. Please let us know what was discussed. BTW, I don't think the kernel can always know if a subprocess is in a notification upcall by looking at the user stack pointer. The upcall notification may be temporarily switched to resume a preempted thread holding a critical resource. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 8 16:45:16 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3204E152F0 for ; Wed, 8 Dec 1999 16:45:12 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id BAA19203 for ; Thu, 9 Dec 1999 01:45:10 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA25089 for freebsd-arch@freebsd.org; Thu, 9 Dec 1999 01:45:10 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 2ABF914E1A for ; Wed, 8 Dec 1999 16:44:56 -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 QAA70157; Wed, 8 Dec 1999 16:44:51 -0800 (PST) Date: Wed, 8 Dec 1999 16:44:50 -0800 (PST) From: Julian Elischer To: "Daniel M. Eischen" Cc: freebsd-arch@freebsd.org Subject: Re: Threads discussion In-Reply-To: <384EF8CB.D83F47EB@vigrid.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 8 Dec 1999, Daniel M. Eischen wrote: > Julian Elischer wrote: > > > > is not dead.. we're all catching our breath! > > > > Tomorrow at the Bay Area Freebsd Users Group (BAFUG) > > there will be a food fight over threads kernel support. > > Anyone within driving range is urged to attend. > > Hey, this isn't fair! :-) just chance.. Alfred perlstein will be there too. > > > I'll be there, as will Matt, Terry, and Jason. > > If I wasn't 2700 miles away, I'd be there too. Please > let us know what was discussed. I think we'll just be swapping ideas. but we MAY be able to get the speaker phone hooked in.. wouldn't that be interesting? I'm not sure how I'd get a conference call set up but that may even be a possibility. (!) > > BTW, I don't think the kernel can always know if a subprocess > is in a notification upcall by looking at the user stack > pointer. The upcall notification may be temporarily switched > to resume a preempted thread holding a critical resource. I wasn't thinking of just upcalls but it may be important to know whether it is in the scheduler when responding to a pagefault. I think page faults in the scheduler should just block. > > Dan Eischen > eischen@vigrid.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 8 17: 6: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 3668B151D9 for ; Wed, 8 Dec 1999 17:06: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 CAA19656 for ; Thu, 9 Dec 1999 02:06:34 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA25396 for freebsd-arch@freebsd.org; Thu, 9 Dec 1999 02:06:34 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 9459815260 for ; Wed, 8 Dec 1999 17:06:24 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt37.pcnet.net [206.105.29.111]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id UAA06109; Wed, 8 Dec 1999 20:06:22 -0500 (EST) Message-ID: <384F0044.3292DAC@vigrid.com> Date: Wed, 08 Dec 1999 20:05:08 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Threads discussion References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > > On Wed, 8 Dec 1999, Daniel M. Eischen wrote: > > > Julian Elischer wrote: > > > > > > is not dead.. we're all catching our breath! > > > > > > Tomorrow at the Bay Area Freebsd Users Group (BAFUG) > > > there will be a food fight over threads kernel support. > > > Anyone within driving range is urged to attend. > > > > Hey, this isn't fair! > > :-) > just chance.. > Alfred perlstein will be there too. I miss out on all the fun :( > I think we'll just be swapping ideas. but we MAY be able to get the > speaker phone hooked in.. > wouldn't that be interesting? Yes :) > I'm not sure how I'd get a conference call set up but that may even be a > possibility. (!) Well, if you need another person on your async call-gate/SA side, hook me up. > > > > BTW, I don't think the kernel can always know if a subprocess > > is in a notification upcall by looking at the user stack > > pointer. The upcall notification may be temporarily switched > > to resume a preempted thread holding a critical resource. > > I wasn't thinking of just upcalls but it may be important to know > whether it is in the scheduler when responding to a pagefault. Yes, I agree. > I think page faults in the scheduler should just block. Hmm, that's certainly the easy route to take. But it still might be possible for another scheduler to make progress. If you have user-level scheduling queues for each subprocess or if the fault was on the scheduler stack, for instance. Just thinking out loud... Details that can be worked out later, I suppose. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 8 18:28:37 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 4DD4C15587 for ; Wed, 8 Dec 1999 18:28:35 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id DAA21849 for ; Thu, 9 Dec 1999 03:28:33 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA25798 for freebsd-arch@freebsd.org; Thu, 9 Dec 1999 03:28:33 +0100 (MET) Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 0755F15580 for ; Wed, 8 Dec 1999 18:28:23 -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 SAA22363; Wed, 8 Dec 1999 18:28:19 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id SAA12152; Wed, 8 Dec 1999 18:28:18 -0800 Received: from softweyr.com (dyn0.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA06724; Wed, 8 Dec 99 18:28:16 PST Message-Id: <384F13E6.4AEDC801@softweyr.com> Date: Wed, 08 Dec 1999 19:28:54 -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: "Daniel M. Eischen" Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads discussion References: <384EF8CB.D83F47EB@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 "Daniel M. Eischen" wrote: > > Julian Elischer wrote: > > > > is not dead.. we're all catching our breath! > > > > Tomorrow at the Bay Area Freebsd Users Group (BAFUG) > > there will be a food fight over threads kernel support. > > Anyone within driving range is urged to attend. > > Hey, this isn't fair! > > > I'll be there, as will Matt, Terry, and Jason. > > If I wasn't 2700 miles away, I'd be there too. Please > let us know what was discussed. Better yet, tape the whole thing and post an MP3 somewhere. Can we get streaming video? ;^) -- "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 8 20:14:54 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3CC5615609 for ; Wed, 8 Dec 1999 20:14: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 FAA23846 for ; Thu, 9 Dec 1999 05:14:10 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA26259 for freebsd-arch@freebsd.org; Thu, 9 Dec 1999 05:14:09 +0100 (MET) Received: from smtp03.wxs.nl (smtp03.wxs.nl [195.121.6.37]) by hub.freebsd.org (Postfix) with ESMTP id E7CF6152EA; Wed, 8 Dec 1999 20:13:23 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org ([195.121.198.86]) by smtp03.wxs.nl (Netscape Messaging Server 3.61) with ESMTP id AAB1F7B; Mon, 6 Dec 1999 20:05:06 +0100 Received: (from asmodai@localhost) by daemon.ninth-circle.org (8.9.3/8.9.3) id TAA98075; Mon, 6 Dec 1999 19:53:42 +0100 (CET) (envelope-from asmodai) Date: Mon, 6 Dec 1999 19:53:41 +0100 From: Jeroen Ruigrok/Asmodai To: Yoshinobu Inoue Cc: freebsd-arch@freebsd.org, cvs-committers@freebsd.org Subject: Re: [Solicite review for KAME 3rd patch] Message-ID: <19991206195341.B11220@daemon.ninth-circle.org> References: <19991203050711F.shin@nd.net.fujitsu.co.jp> <19991204154807.G711@daemon.ninth-circle.org> <19991206210212K.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: <19991206210212K.shin@nd.net.fujitsu.co.jp>; from shin@nd.net.fujitsu.co.jp on Mon, Dec 06, 1999 at 09:02:12PM +0900 Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [19991206 16:00], Yoshinobu Inoue (shin@nd.net.fujitsu.co.jp) wrote: >Thanks for your detailed comments. You are quite welcome. It is in my own interest to do so. >> All patches succeeded on a fresh CURRENT source tree except for: >> >> - sbin/ifconfig/Makefile >> - sbin/route/Makefile >> - usr.bin/netstat/Makefile >> >> no .rej file was made curiously enough. Patched by hand. > >Was your fix uncommenting > >#CFLAGS+=-DINET6 No, as Peter Wemm was kind enough to explain to me, I forgot to use -p and -I flags. >Then, I intentionally commented them out by default, because >INET6 kernel config option is also not enabled by default. 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. >> sys/conf/files: >> >> I like the rearranging of the netinet options, it certainly clarifies >> things. > >Thanks, though I'm a little bit uncertain where is the best >place ipfilter related files should be put in. Please ask Guido van Rooij about this. >> COMPATIBILITY OPTIONS seems to be a whitespace fix. Not needed IMHO. >(and all comments about whitespaces) > >I exec'ed some script which do removing whitespaces and tabs at the end >of each line and etc for all files I touched, in case I mistakenly put >them. Heh, don't do that. =) >But, > >> My suggestion: checkout a new source tree and only modify that what you want to >> change and ignore tab line-ups and concentrate on the functionality. White >> space corrections are best done in cosmestic commits. > >I agree, I'll take care of whitespaces later. Thanks. >> The `faith` pseudo-device catches those packets which sent to it, and >> forwards then to IPv4 and IPv6 translating daemon. >> >> Should this be: >> >> The `faith' pseudo-device captures packets sent to it and forwards them >> to the IPv4/IPv6 translation daemon. > >Thanks, I use it. Only if what I said is what it really does of course. Looking through the sources I think my description matches or at least comes close. (Which is of course based on your description.) >> Although I wonder if forwards could be changed to divert. > >Is the word "divert" more natural? >Then I change the description. Well, that's what I am wondering about. Divert is something which is also used a lot in NAT related set-ups in which all specified traffic gets send to a specific port or host. In this case to a daemon. So I think divert might be better use to remain consistent with the rest of the terminology. But of course I am open to suggestions from long term veterans such as Mr Wollman. >> Does faith replace loop? If so, what is against adding the IPv6 >> functionality to loop? > >Its if_type IFT_FAITH is also important. Aha, so we have loop and faith, which both provide the same functionality. Is the functionality _EXACT_ the same and does it differ only in terms of IPv6 support or does it differ even more aside from that. That wasn't too clear to me. >Packets catched by faith is put into ip6 input queue and >processed by ip6_input() again. >But this 2nd time input, it matches this check, and treated as >'ours'. Aha, so the true difference is the reprocessing of previously matched packets? >But just one point, >I think this patch should be left, shouldn't it? > >-#if defined(INET) || defined(NS) || defined(DECNET) || defined(IPX) || defined(NETATALK) >+#if defined(INET) || defined(INET6) || defined(NS) || defined(DECNET) || defined(IPX) || defined(NETATALK) Oh sorry. A mistake on my part. =) Aye, that was meant to stay there. Too much dd'ing of whitespace changes. >> Hope this helps, > >Thanks very much again. You are welcome. >When I cvs updated my environments I'll soon prepare new diff. >(But freefall seems to be heavy now.) It was having severe disk problems. I think Peter Wemm solved them all this afternoon. (If anyone has disks to spare, feel free to let the project know =) ) Inoue-san, feel free to mail me when your new patches are done as I am very eager to help getting KAME intergrated as fast as possible without too many hick-ups. Kind regards, -- 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 Wed Dec 8 22:52: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 595DD14A0D for ; Wed, 8 Dec 1999 22:52: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 HAA24898 for ; Thu, 9 Dec 1999 07:52:46 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id HAA26797 for freebsd-arch@freebsd.org; Thu, 9 Dec 1999 07:52:46 +0100 (MET) Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id E11BC151E9; Wed, 8 Dec 1999 22:52:31 -0800 (PST) (envelope-from jhay@zibbi.mikom.csir.co.za) Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.9.3/8.9.3) id IAA95501; Thu, 9 Dec 1999 08:51:38 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <199912090651.IAA95501@zibbi.mikom.csir.co.za> Subject: Re: [Solicite review for KAME 3rd patch] In-Reply-To: <19991206195341.B11220@daemon.ninth-circle.org> from Jeroen Ruigrok/Asmodai at "Dec 6, 1999 07:53:41 pm" To: asmodai@wxs.nl (Jeroen Ruigrok/Asmodai) Date: Thu, 9 Dec 1999 08:51:38 +0200 (SAT) Cc: shin@nd.net.fujitsu.co.jp (Yoshinobu Inoue), freebsd-arch@freebsd.org, cvs-committers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> All patches succeeded on a fresh CURRENT source tree except for: > >> > >> - sbin/ifconfig/Makefile > >> - sbin/route/Makefile > >> - usr.bin/netstat/Makefile > >> > >> no .rej file was made curiously enough. Patched by hand. > > > >Was your fix uncommenting > > > >#CFLAGS+=-DINET6 > > No, as Peter Wemm was kind enough to explain to me, I forgot to use -p > and -I flags. > > >Then, I intentionally commented them out by default, because > >INET6 kernel config option is also not enabled by default. > > 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. Then you only need to compile a kernel with INET6 to have a working IPv6 machine. 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. John -- John Hay -- John.Hay@mikom.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 9 12:12:48 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id F389515703 for ; Thu, 9 Dec 1999 12:12: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 VAA07115 for ; Thu, 9 Dec 1999 21:12:38 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA31112 for freebsd-arch@freebsd.org; Thu, 9 Dec 1999 21:12:37 +0100 (MET) Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 89DDD156F6 for ; Thu, 9 Dec 1999 12:07:48 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id OAA21413; Thu, 9 Dec 1999 14:51:27 -0500 (EST) Reply-To: Randell Jesup To: Julian Elischer Cc: arch@freebsd.org Subject: Re: kernel entry costs. References: From: Randell Jesup Date: 09 Dec 1999 14:51:56 -0500 In-Reply-To: Julian Elischer's message of "Sun, 28 Nov 1999 14:11:13 -0800 (PST)" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer writes: >> > Julian, you shouldn't worry about userland<->kernel context switchso much. >> > The overhead for going into the kernel and coming out again, if all the >> > cruft is removed, is *very* tiny -- it's almost like a subroutine call. >> >> I was rather suprised when I found out just how expensive kernel entry was >> some time ago.. What I was doing was a reentrant syscall that aquired no >> locks and ran about 5 instructions in kernel context.. Anyway, it took >> something like 300 times longer to do that (called via int $0x81) than to >> do a 'call' to equivalent code in userland. Anyway, with overheads on that >> scale, whether we push 5 or 8 or whatever registers in the handler is >> almost lost in the noise. > >the IDT vercor is read >leading to the Interrupt gate that must be read, [ lots of stuff snipped ] >the new segment registers are then loaded. The generic syscall code is >called, and the appropriate function is selected and called. > >on return, the return values are saved into the registers in a >towers of hanoi simulation as the registers are reloaded and the >segment registers are reloaded. Then the flags , SP and IP are reloaded. > >this is not an insignificant amount of work! Don't forget that even though it's 'invisible', there may be extra overhead involved in the page table changes and TLB reloads occuring, cache misses, etc. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 9 16:19:20 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 05FFD15371 for ; Thu, 9 Dec 1999 16:19:17 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id BAA09397 for ; Fri, 10 Dec 1999 01:19:13 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA32697 for freebsd-arch@freebsd.org; Fri, 10 Dec 1999 01:19:11 +0100 (MET) Received: from fgwmail5.fujitsu.co.jp (fgwmail5.fujitsu.co.jp [192.51.44.35]) by hub.freebsd.org (Postfix) with ESMTP id CF4FF152E8; Thu, 9 Dec 1999 16:18:59 -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-MX9911-Fujitsu Gateway) id JAA12526; Fri, 10 Dec 1999 09:18:55 +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 JAA23675; Fri, 10 Dec 1999 09:18:55 +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 JAA04613; Fri, 10 Dec 1999 09:18:54 +0900 (JST) To: jhay@mikom.csir.co.za Cc: asmodai@wxs.nl, freebsd-arch@freebsd.org, cvs-committers@freebsd.org Subject: Re: [Solicite review for KAME 3rd patch] In-Reply-To: <199912090651.IAA95501@zibbi.mikom.csir.co.za> References: <19991206195341.B11220@daemon.ninth-circle.org> <199912090651.IAA95501@zibbi.mikom.csir.co.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: <19991210091917L.shin@nd.net.fujitsu.co.jp> Date: Fri, 10 Dec 1999 09:19:17 +0900 From: Yoshinobu Inoue X-Dispatcher: imput version 990905(IM130) Lines: 21 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > My suggestion would be to always enable IPv6 support in the userlevel > programs. Then you only need to compile a kernel with INET6 to have > a working IPv6 machine. 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. OK, then I think "#ifdef INET6" in user-land apps should be removed eventually. For the moment, I'll uncomment "CFLAGS+= -DINET6" after I checked it on non INET6 enabled kernel. Thanks, Yoshinobu Inoue > John > -- > John Hay -- John.Hay@mikom.csir.co.za > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 9 20:43:19 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id A1C8B14BFE for ; Thu, 9 Dec 1999 20:43: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 FAA14288 for ; Fri, 10 Dec 1999 05:43:15 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA33585 for freebsd-arch@freebsd.org; Fri, 10 Dec 1999 05:43:14 +0100 (MET) Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id B7143153B3 for ; Thu, 9 Dec 1999 20:41:38 -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 XAA08772 for ; Thu, 9 Dec 1999 23:40:40 -0500 (EST) (envelope-from chuckr@picnic.mat.net) Date: Thu, 9 Dec 1999 23:40:40 -0500 (EST) From: Chuck Robey To: freebsd-arch@freebsd.org Subject: Thread scheduling 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 In scheduling multiple threads on a FreeBSD SMP system, is it just important that if a thread asks for multiple processors, then it can contend for multiple processors, or is it in any way important that these multiple instances of execution from the same memory space actually occur at the same point in time. That is, is it important at all that all processors be doing the same multithreading task (if it's multithreaded, and wants it) at exactly the same time? The alternative would give it a multiple of the execution time, but not be constrained at all to make those execution windows overlap in time. It's going to make a difference in scheduling and how the multiple kernel side of threading is handled, and I'm thinking about that now. ---------------------------------------------------------------------------- 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 Thu Dec 9 21: 4:28 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 6F33C14CBF for ; Thu, 9 Dec 1999 21:04:24 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id GAA14415 for ; Fri, 10 Dec 1999 06:04:22 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA33652 for freebsd-arch@freebsd.org; Fri, 10 Dec 1999 06:04:21 +0100 (MET) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 9342714E24 for ; Thu, 9 Dec 1999 21:04:13 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40337>; Fri, 10 Dec 1999 15:56:00 +1100 Content-return: prohibited Date: Fri, 10 Dec 1999 16:02:40 +1100 From: Peter Jeremy Subject: Re: Thread scheduling In-reply-to: ; from chuckr@picnic.mat.net on Fri, Dec 10, 1999 at 03:40:40PM +1100 To: Chuck Robey Cc: freebsd-arch@freebsd.org Message-Id: <99Dec10.155600est.40337@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=us-ascii References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Dec-10 15:40:40 +1100, Chuck Robey wrote: >That is, is it important at all that all processors be doing the same >multithreading task (if it's multithreaded, and wants it) at exactly the >same time? I don't think this is guaranteed anywhere. In any case, IMHO it would be virtually impossible for a system to provide such a guarantee - consider a system which provided such a guarantee and currently has two threads executing on two CPUs. An interrupt then occurs on one CPU - what happens to the thread on the other CPU (which hasn't seen the interrupt)? What happens if (as a result of the interrupt) a higher priority process becomes runnable? Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 9 21:30: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 5A4E7153B1 for ; Thu, 9 Dec 1999 21:30: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 GAA14555 for ; Fri, 10 Dec 1999 06:30:50 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA33704 for freebsd-arch@freebsd.org; Fri, 10 Dec 1999 06:30:49 +0100 (MET) Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 40E9E1537E for ; Thu, 9 Dec 1999 21:30:25 -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 AAA08943; Fri, 10 Dec 1999 00:28:17 -0500 (EST) (envelope-from chuckr@picnic.mat.net) Date: Fri, 10 Dec 1999 00:28:17 -0500 (EST) From: Chuck Robey To: Peter Jeremy Cc: freebsd-arch@freebsd.org Subject: Re: Thread scheduling In-Reply-To: <99Dec10.155600est.40337@border.alcanet.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 10 Dec 1999, Peter Jeremy wrote: > On 1999-Dec-10 15:40:40 +1100, Chuck Robey wrote: > >That is, is it important at all that all processors be doing the same > >multithreading task (if it's multithreaded, and wants it) at exactly the > >same time? > > I don't think this is guaranteed anywhere. In any case, IMHO it would > be virtually impossible for a system to provide such a guarantee - > consider a system which provided such a guarantee and currently has > two threads executing on two CPUs. An interrupt then occurs on one > CPU - what happens to the thread on the other CPU (which hasn't seen > the interrupt)? What happens if (as a result of the interrupt) a > higher priority process becomes runnable? I can think of several ways for it to be done, so lets concentrate on whether it's needed or desireable. I think all the caching is done per processor, so that wouldn't be an issue, right? Hiw about memory usage? ---------------------------------------------------------------------------- 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 Thu Dec 9 22:41:19 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 0A11915120 for ; Thu, 9 Dec 1999 22:41: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 HAA14922 for ; Fri, 10 Dec 1999 07:41:10 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id HAA33897 for freebsd-arch@freebsd.org; Fri, 10 Dec 1999 07:41:09 +0100 (MET) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by hub.freebsd.org (Postfix) with ESMTP id 5C28A15176 for ; Thu, 9 Dec 1999 22:40:56 -0800 (PST) (envelope-from michael.schuster@germany.sun.com) Received: from emuc05-home.Germany.Sun.COM ([129.157.51.10]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA03424; Thu, 9 Dec 1999 22:40:43 -0800 (PST) Received: from germany.sun.com (hacker [129.157.167.97]) by emuc05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with ESMTP id HAA13305; Fri, 10 Dec 1999 07:40:41 +0100 (MET) Message-ID: <3850A077.CE3560A4@germany.sun.com> Date: Fri, 10 Dec 1999 07:40:55 +0100 From: Michael Schuster - TSC SunOS Germany Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Chuck Robey Cc: freebsd-arch@freebsd.org Subject: Re: Thread scheduling References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Chuck Robey wrote: > > In scheduling multiple threads on a FreeBSD SMP system, is it just > important that if a thread asks for multiple processors, then it can > contend for multiple processors, or is it in any way important that these > multiple instances of execution from the same memory space actually occur > at the same point in time. > > That is, is it important at all that all processors be doing the same > multithreading task (if it's multithreaded, and wants it) at exactly the > same time? The alternative would give it a multiple of the execution > time, but not be constrained at all to make those execution windows > overlap in time. two questions: a) what exactly would be the benefit of such an execution model, compared to what is done "normally" (i.e. explicit synchronisation of threads) b) how would you ever guarantee(sp?) anything like this? > Chuck Robey cheers Michael -- Michael Schuster / Michael.Schuster@germany.sun.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 10 12:38: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 69CA415D85 for ; Fri, 10 Dec 1999 12:17:50 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA26360 for ; Fri, 10 Dec 1999 21:17:36 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA38148 for freebsd-arch@freebsd.org; Fri, 10 Dec 1999 21:17:36 +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 A0F9C15AE2 for ; Fri, 10 Dec 1999 11:43:17 -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 LAA03390; Fri, 10 Dec 1999 11:43:04 -0800 Date: Fri, 10 Dec 1999 11:43:04 -0800 From: Arun Sharma To: Chuck Robey Cc: freebsd-arch@freebsd.org Subject: Re: Thread scheduling Message-ID: <19991210114304.A3372@sharmas.dhs.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: ; from Chuck Robey on Thu, Dec 09, 1999 at 11:40:40PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Dec 09, 1999 at 11:40:40PM -0500, Chuck Robey wrote: > In scheduling multiple threads on a FreeBSD SMP system, is it just > important that if a thread asks for multiple processors, then it can > contend for multiple processors, or is it in any way important that these > multiple instances of execution from the same memory space actually occur > at the same point in time. A thread can't be scheduled on more than one processor simultaneously. Multiple threads in the same process can be. Assuming that this is what you meant... Is it desirable ? Yes. Can it be guaranteed ? Not easily. If you have a SMP machine dedicated to a particular task like web serving, the optimal use of the system would be to run multiple threads in the same address space on multiple processors. -Arun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 10 13: 6:34 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 388491519B for ; Fri, 10 Dec 1999 13:06: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 WAA26970 for ; Fri, 10 Dec 1999 22:06:00 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA38526 for freebsd-arch@freebsd.org; Fri, 10 Dec 1999 22:05:59 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 853E314BC3 for ; Fri, 10 Dec 1999 13:05:14 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id OAA26233; Fri, 10 Dec 1999 14:04:08 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id OAA21584; Fri, 10 Dec 1999 14:04:06 -0700 Date: Fri, 10 Dec 1999 14:04:06 -0700 Message-Id: <199912102104.OAA21584@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Chuck Robey Cc: Peter Jeremy , freebsd-arch@freebsd.org Subject: Re: Thread scheduling In-Reply-To: References: <99Dec10.155600est.40337@border.alcanet.com.au> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > >That is, is it important at all that all processors be doing the same > > >multithreading task (if it's multithreaded, and wants it) at exactly the > > >same time? > > > > I don't think this is guaranteed anywhere. In any case, IMHO it would > > be virtually impossible for a system to provide such a guarantee - > > consider a system which provided such a guarantee and currently has > > two threads executing on two CPUs. An interrupt then occurs on one > > CPU - what happens to the thread on the other CPU (which hasn't seen > > the interrupt)? What happens if (as a result of the interrupt) a > > higher priority process becomes runnable? > > I can think of several ways for it to be done, so lets concentrate on > whether it's needed or desireable. No and no. If any software relies on it, it's completely broken for Uniprocessor machines, since they can't make any such guarantees. Having multiple threads occuring simultaneous is an effeciency issue, but should never be relied on for correct operation of the algorithms in a general purpose computing platform. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 10 17:24: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 96B1E14EA7 for ; Fri, 10 Dec 1999 17:24:50 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id CAA01352 for ; Sat, 11 Dec 1999 02:24:47 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA39728 for freebsd-arch@freebsd.org; Sat, 11 Dec 1999 02:24:46 +0100 (MET) Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id B474A14DBD for ; Fri, 10 Dec 1999 17:24:22 -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 UAA36336; Fri, 10 Dec 1999 20:23:17 -0500 (EST) (envelope-from chuckr@picnic.mat.net) Date: Fri, 10 Dec 1999 20:23:17 -0500 (EST) From: Chuck Robey To: Arun Sharma Cc: freebsd-arch@freebsd.org Subject: Re: Thread scheduling In-Reply-To: <19991210114304.A3372@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 Fri, 10 Dec 1999, Arun Sharma wrote: > On Thu, Dec 09, 1999 at 11:40:40PM -0500, Chuck Robey wrote: > > In scheduling multiple threads on a FreeBSD SMP system, is it just > > important that if a thread asks for multiple processors, then it can > > contend for multiple processors, or is it in any way important that these > > multiple instances of execution from the same memory space actually occur > > at the same point in time. > > A thread can't be scheduled on more than one processor simultaneously. > Multiple threads in the same process can be. Assuming that this is > what you meant... > > Is it desirable ? Yes. Can it be guaranteed ? Not easily. If you have a > SMP machine dedicated to a particular task like web serving, the > optimal use of the system would be to run multiple threads in the same > address space on multiple processors. I note that Nate disagreed with you ... dropping the subject of if it can be done as premature, your blank statement of "Yes" isn't enough; can you offer some reason why it's desireable? If the task is reasonably active, it'll stay in memory, so extra time won't be spent swapping. I think that all caching is done per processor, not per memory space, and (if I'm right on that) then there wouldn't be a caching reason, right? Why is it desireable? > > -Arun > > ---------------------------------------------------------------------------- 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 Fri Dec 10 17:35: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 DF58E14DA4 for ; Fri, 10 Dec 1999 17:35: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 CAA05053 for ; Sat, 11 Dec 1999 02:35:39 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA39845 for freebsd-arch@freebsd.org; Sat, 11 Dec 1999 02:35:39 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 03BCE14D10 for ; Fri, 10 Dec 1999 17:35:27 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id SAA29086; Fri, 10 Dec 1999 18:35:23 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id SAA23495; Fri, 10 Dec 1999 18:35:22 -0700 Date: Fri, 10 Dec 1999 18:35:22 -0700 Message-Id: <199912110135.SAA23495@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Chuck Robey Cc: Arun Sharma , freebsd-arch@freebsd.org Subject: Re: Thread scheduling In-Reply-To: References: <19991210114304.A3372@sharmas.dhs.org> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > In scheduling multiple threads on a FreeBSD SMP system, is it just > > > important that if a thread asks for multiple processors, then it can > > > contend for multiple processors, or is it in any way important that these > > > multiple instances of execution from the same memory space actually occur > > > at the same point in time. > > > > A thread can't be scheduled on more than one processor simultaneously. > > Multiple threads in the same process can be. Assuming that this is > > what you meant... > > > > Is it desirable ? Yes. Can it be guaranteed ? Not easily. If you have a > > SMP machine dedicated to a particular task like web serving, the > > optimal use of the system would be to run multiple threads in the same > > address space on multiple processors. > > I note that Nate disagreed with you ... I actually think we're in agreement, but our definitions differ. > dropping the subject of if it can > be done as premature, your blank statement of "Yes" isn't enough; can you > offer some reason why it's desireable? If the task is reasonably active, > it'll stay in memory, so extra time won't be spent swapping. I think that > all caching is done per processor, not per memory space, and (if I'm right > on that) then there wouldn't be a caching reason, right? > > Why is it desireable? It is desirable for effeciency reasons (if two threads are running on seperate CPU's, then twice as much work will get done), as well as the cache issues. But, is making it a requirement desirable? Not in my book. (I may have misunderstood your 'desirable' statement previously by reading that making assuming that you were wondering if is desirable to make it a requirement, which is silly now that I think about it.) However, is it desirable to have multiple threads in a single process executing on multiple CPUs? Of course, if the benefits don't outweight the costs in terms of complexity and such. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 10 18:15: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 053F114E50 for ; Fri, 10 Dec 1999 18:15:45 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id DAA09081 for ; Sat, 11 Dec 1999 03:15:43 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA39989 for freebsd-arch@freebsd.org; Sat, 11 Dec 1999 03:15:43 +0100 (MET) Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 478BB1537D for ; Fri, 10 Dec 1999 18:15:27 -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 VAA36755; Fri, 10 Dec 1999 21:14:11 -0500 (EST) (envelope-from chuckr@picnic.mat.net) Date: Fri, 10 Dec 1999 21:14:11 -0500 (EST) From: Chuck Robey To: Nate Williams Cc: Arun Sharma , freebsd-arch@freebsd.org Subject: Re: Thread scheduling In-Reply-To: <199912110135.SAA23495@mt.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 10 Dec 1999, Nate Williams wrote: > > Why is it desireable? > > It is desirable for effeciency reasons (if two threads are running on > seperate CPU's, then twice as much work will get done), as well as the > cache issues. But, is making it a requirement desirable? Not in my > book. (I may have misunderstood your 'desirable' statement previously > by reading that making assuming that you were wondering if is desirable > to make it a requirement, which is silly now that I think about it.) 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. 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. Not a guarantee, but would it be a good thing to have them "co-scheduled" (or a bias towards that likelihood). 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? > > However, is it desirable to have multiple threads in a single process > executing on multiple CPUs? Of course, if the benefits don't outweight > the costs in terms of complexity and such. It's the simultaneity I am asking about. ---------------------------------------------------------------------------- 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 Fri Dec 10 20:15: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 3B82914DA7 for ; Fri, 10 Dec 1999 20:15: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 FAA11646 for ; Sat, 11 Dec 1999 05:15:50 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA43534 for freebsd-arch@freebsd.org; Sat, 11 Dec 1999 05:15:48 +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 AD29014EB6 for ; Fri, 10 Dec 1999 20:15:41 -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 UAA04630; Fri, 10 Dec 1999 20:15:22 -0800 Date: Fri, 10 Dec 1999 20:15:22 -0800 From: Arun Sharma To: Chuck Robey Cc: Nate Williams , freebsd-arch@freebsd.org Subject: Re: Thread scheduling Message-ID: <19991210201522.A4535@sharmas.dhs.org> References: <199912110135.SAA23495@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: ; from Chuck Robey on Fri, Dec 10, 1999 at 09:14:11PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Dec 10, 1999 at 09:14:11PM -0500, Chuck Robey wrote: > > 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 - 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. 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. 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. -Arun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 10 20:55: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 3D62514EEB for ; Fri, 10 Dec 1999 20:55: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 FAA11824 for ; Sat, 11 Dec 1999 05:55:43 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA43603 for freebsd-arch@freebsd.org; Sat, 11 Dec 1999 05:55:42 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id B9B5414E08 for ; Fri, 10 Dec 1999 20:55:34 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id VAA00713; Fri, 10 Dec 1999 21:55:30 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id VAA24095; Fri, 10 Dec 1999 21:55:29 -0700 Date: Fri, 10 Dec 1999 21:55:29 -0700 Message-Id: <199912110455.VAA24095@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Chuck Robey Cc: Nate Williams , Arun Sharma , freebsd-arch@freebsd.org Subject: Re: Thread scheduling In-Reply-To: References: <199912110135.SAA23495@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > It is desirable for effeciency reasons (if two threads are running on > > seperate CPU's, then twice as much work will get done), as well as the > > cache issues. But, is making it a requirement desirable? Not in my > > book. (I may have misunderstood your 'desirable' statement previously > > by reading that making assuming that you were wondering if is desirable > > to make it a requirement, which is silly now that I think about it.) > > 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. It depends on the application. > 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). > 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. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 10 23: 6: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 D5AB414EFE for ; Fri, 10 Dec 1999 23:06: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 IAA12559 for ; Sat, 11 Dec 1999 08:06:49 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA43942 for freebsd-arch@freebsd.org; Sat, 11 Dec 1999 08:06:48 +0100 (MET) Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id DB2D914D2C for ; Fri, 10 Dec 1999 23:06:40 -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 11wgc3-0004Vd-00; Sat, 11 Dec 1999 00:06:39 -0700 Message-ID: <3851B782.1A651689@softweyr.com> Date: Fri, 10 Dec 1999 19:31:30 -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: Nate Williams Cc: Chuck Robey , Arun Sharma , freebsd-arch@freebsd.org Subject: Re: Thread scheduling References: <19991210114304.A3372@sharmas.dhs.org> <199912110135.SAA23495@mt.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nate Williams wrote: > > However, is it desirable to have multiple threads in a single process > executing on multiple CPUs? Of course, if the benefits don't outweight > the costs in terms of complexity and such. A reasonable point of view. The end goal must be to enable this, but not at the expense of getting *some* kernel-supported threads in 4.{0,1,2}. -- "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 Sat Dec 11 9:38: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 1554614F50 for ; Sat, 11 Dec 1999 09:38: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 SAA15584 for ; Sat, 11 Dec 1999 18:38:49 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA45611 for freebsd-arch@freebsd.org; Sat, 11 Dec 1999 18:38:48 +0100 (MET) Received: from smtp-out2.bellatlantic.net (smtp-out2.bellatlantic.net [199.45.39.157]) by hub.freebsd.org (Postfix) with ESMTP id 0C83E14EEF for ; Sat, 11 Dec 1999 09:38:13 -0800 (PST) (envelope-from todd@lugaru.com) Received: from desktop (adsl-151-201-20-102.bellatlantic.net [151.201.20.102]) by smtp-out2.bellatlantic.net (8.9.1/8.9.1) with SMTP id MAA26536; Sat, 11 Dec 1999 12:44:00 -0500 (EST) Message-Id: <3.0.5.32.19991211123651.008abcb0@216.147.58.10> X-Sender: todd@216.147.58.10 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Sat, 11 Dec 1999 12:36:51 -0500 To: arch@freebsd.org From: Todd Doucet Subject: rzsz port Cc: steven@lugaru.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm sending you this email because you're listed as the maintainer of the rzsz port for my FreeBSD 3.3 system. When I try to make the port, I get an error that says that there is a checksum mismatch for rzsz.zip. I could override the checksum, but that seems bad. These checksums are a good idea, and shouldn't be casually tossed aside. If I'm wrong and they should be casually tossed aside, please explain. The ftp site, again specified in the makefile, is ftp://ftp.cs.pdx.edu/pub/zmodem. I have looked on usenet, and have found nothing but confusion related to this. As the maintainer of the port, can you give me some guidance? Thanks, Todd Doucet To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 11 11: 5:48 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3F81815121 for ; Sat, 11 Dec 1999 11:05:45 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA15993 for ; Sat, 11 Dec 1999 20:05:43 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA45862 for freebsd-arch@freebsd.org; Sat, 11 Dec 1999 20:05:43 +0100 (MET) Received: from fgwmail7.fujitsu.co.jp (fgwmail7.fujitsu.co.jp [192.51.44.37]) by hub.freebsd.org (Postfix) with ESMTP id 4CD9415121; Sat, 11 Dec 1999 11:05:15 -0800 (PST) (envelope-from shin@nd.net.fujitsu.co.jp) Received: from m1.gw.fujitsu.co.jp by fgwmail7.fujitsu.co.jp (8.9.3/3.7W-MX9911-Fujitsu Gateway) id EAA10586; Sun, 12 Dec 1999 04:05:13 +0900 (JST) Received: from incapgw.fujitsu.co.jp by m1.gw.fujitsu.co.jp (8.9.3/3.7W-9912-Fujitsu Domain Master) id EAA11599; Sun, 12 Dec 1999 04:05:13 +0900 (JST) Received: from localhost ([192.168.245.7]) by incapgw.fujitsu.co.jp (8.9.3/3.7W-9912) id EAA00511; Sun, 12 Dec 1999 04:05:11 +0900 (JST) To: freebsd-arch@freebsd.org, cvs-committers@freebsd.org Subject: [Solicite review for KAME 5th 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: <19991212040532I.shin@nd.net.fujitsu.co.jp> Date: Sun, 12 Dec 1999 04:05:32 +0900 From: Yoshinobu Inoue X-Dispatcher: imput version 990905(IM130) Lines: 31 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG People should be busy, but this is 5th KAME patches. Please give me any comments if someone have time to check it. http://paradise.kame.net/v6proxy/diana2/shin/work/freebsd/kernel-ipsec.19991212 This is IPsec related kernel extensions and IPv6 Firewall addition. There are several points, -ip_output() part ipsec extension is not yet, because KAME ipsec uses m_pkthdr.rcvif, and ipfw also use it. I am investigating how they can smoothly coexist. -IPv6 multicast routing and tcp for ipv6 is not yet. -ipprotosw.h is added to change pr_input() routines prototype under sys/netinet. The change is necessary to treat chained protocol headers which easily happens when IPsec is introduced. An alternative is to change sys/sys/protosw.h, but then other protocol stacks' pr_input() routines are also need to be changed. -sys/netkey files are almost completely replaced as pfkey version2 support. But filenames are same so their diffs are complicated. Also, src/usr.sbin/keyadmin will become not compilable as the change. 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 Yoshinobu Inoue To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 11 11:29: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 1218414A2A for ; Sat, 11 Dec 1999 11:29: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 UAA16064 for ; Sat, 11 Dec 1999 20:28:56 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA45911 for freebsd-arch@freebsd.org; Sat, 11 Dec 1999 20:28:56 +0100 (MET) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 9766714D16 for ; Sat, 11 Dec 1999 11:28:47 -0800 (PST) (envelope-from rcarter@pinyon.org) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id MAA06031; Sat, 11 Dec 1999 12:28:31 -0700 (MST) Received: from ip-83-008.prc.primenet.com(207.218.83.8), claiming to be "pinyon.org" via SMTP by smtp01.primenet.com, id smtpdAAA2faGJl; Sat Dec 11 12:28:23 1999 Received: from chomsky.Pinyon.ORG (localhost [127.0.0.1]) by pinyon.org (Postfix) with ESMTP id 4C7504A; Sat, 11 Dec 1999 12:27:42 -0700 (MST) X-Mailer: exmh version 2.1.0 09/18/1999 To: nate@mt.sri.com (Nate Williams) Cc: Chuck Robey , Arun Sharma , freebsd-arch@freebsd.org, rcarter@pinyon.org Subject: Re: Thread scheduling In-Reply-To: Message from Nate Williams of "Fri, 10 Dec 1999 21:55:29 MST." <199912110455.VAA24095@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 11 Dec 1999 12:27:42 -0700 From: "Russell L. Carter" Message-Id: <19991211192742.4C7504A@pinyon.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG %> 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. :-) Russell % % % %Nate % To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 11 12:48: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 0AE2015008 for ; Sat, 11 Dec 1999 12:48: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 VAA16493 for ; Sat, 11 Dec 1999 21:48:38 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA46217 for freebsd-arch@freebsd.org; Sat, 11 Dec 1999 21:48:38 +0100 (MET) Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 9437615008 for ; Sat, 11 Dec 1999 12:48:32 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (root@d60-025.leach.ucdavis.edu [169.237.60.25]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id MAA96728; Sat, 11 Dec 1999 12:48:29 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id MAA68919; Sat, 11 Dec 1999 12:48:29 -0800 (PST) (envelope-from obrien) Date: Sat, 11 Dec 1999 12:48:28 -0800 From: "David O'Brien" To: Todd Doucet Cc: arch@freebsd.org, steven@lugaru.com Subject: Re: rzsz port Message-ID: <19991211124828.A14998@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <3.0.5.32.19991211123651.008abcb0@216.147.58.10> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3.0.5.32.19991211123651.008abcb0@216.147.58.10>; from todd@lugaru.com on Sat, Dec 11, 1999 at 12:36:51PM -0500 X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Dec 11, 1999 at 12:36:51PM -0500, Todd Doucet wrote: > I'm sending you this email because you're listed as the maintainer > of the rzsz port for my FreeBSD 3.3 system. arch@freebsd.org is the list the farthest from the correct one to send this report. The arch list is for architectural discussions. A port issue hardly fits this. Please repost this to "ports@freebsd.org", and/or use send-pr (either command line or from the www.freebsd.org homepage) to send a problem report. -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 11 18:12: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 0EDD6150E9 for ; Sat, 11 Dec 1999 18:12: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 DAA18727 for ; Sun, 12 Dec 1999 03:12:16 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA47430 for freebsd-arch@freebsd.org; Sun, 12 Dec 1999 03:12:15 +0100 (MET) Received: from green.dyndns.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 6AF5D14BD0; Sat, 11 Dec 1999 18:12:02 -0800 (PST) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost [127.0.0.1]) by green.dyndns.org (8.9.3/8.9.3) with ESMTP id VAA29354; Sat, 11 Dec 1999 21:07:08 -0500 (EST) (envelope-from green@FreeBSD.org) Date: Sat, 11 Dec 1999 21:07:06 -0500 (EST) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: Yoshinobu Inoue Cc: freebsd-arch@freebsd.org, cvs-committers@freebsd.org Subject: Re: [Solicite review for KAME 5th patch] In-Reply-To: <19991212040532I.shin@nd.net.fujitsu.co.jp> 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 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... -- 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 Sat Dec 11 22:45: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 E988A15149 for ; Sat, 11 Dec 1999 22:45:02 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id HAA20215 for ; Sun, 12 Dec 1999 07:44:59 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id HAA48076 for freebsd-arch@freebsd.org; Sun, 12 Dec 1999 07:44:59 +0100 (MET) Received: from poboxer.pobox.com (ferg5200-1-11.cpinternet.com [208.149.16.11]) by hub.freebsd.org (Postfix) with ESMTP id 2DD21150EE for ; Sat, 11 Dec 1999 22:44:52 -0800 (PST) (envelope-from alk@poboxer.pobox.com) Received: (from alk@localhost) by poboxer.pobox.com (8.9.3/8.9.1) id AAA33157; Sun, 12 Dec 1999 00:44:40 -0600 (CST) (envelope-from alk) From: Anthony Kimball MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 12 Dec 1999 00:44:40 -0600 (CST) X-Face: \h9Jg:Cuivl4S*UP-)gO.6O=T]]@ncM*tn4zG);)lk#4|lqEx=*talx?.Gk,dMQU2)ptPC17cpBzm(l'M|H8BUF1&]dDCxZ.c~Wy6-j,^V1E(NtX$FpkkdnJixsJHE95JlhO 5\M3jh'YiO7KPCn0~W`Ro44_TB@&JuuqRqgPL'0/{):7rU-%.*@/>q?1&Ed Reply-To: alk@pobox.com To: nate@mt.sri.com Cc: chuckr@picnic.mat.net, peter.jeremy@alcatel.com.au, freebsd-arch@freebsd.org Subject: Re: Thread scheduling References: <99Dec10.155600est.40337@border.alcanet.com.au> <199912102104.OAA21584@mt.sri.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14419.17281.862403.198050@avalon.east> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Quoth Nate Williams on Fri, 10 December: : > : > I can think of several ways for it to be done, so lets concentrate on : > whether it's needed or desireable. : : No and no. If any software relies on it, it's completely broken for : Uniprocessor machines, since they can't make any such guarantees. : Having multiple threads occuring simultaneous is an effeciency issue, : but should never be relied on for correct operation of the algorithms in : a general purpose computing platform. That doesn't mean that it isn't needed or desirable. Efficiency is needed and desirable, in general. (When efficiency hits zero, nothing ever gets done!) Of the three bids I know about for the ASCI 30 Teraflop machine, two are Linux bids. I can guarantee that the winning bid will coschedule threads. Doesn't the idea of the fastest single integrated computing system in the world running FreeBSD instead of Linux seem appealling? It's too late for the 30 Teraflop, but the 100 Teraflop follow-on... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message