From owner-freebsd-arch@FreeBSD.ORG Mon Oct 3 10:05:01 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8841316A41F for ; Mon, 3 Oct 2005 10:05:01 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2E9943D46 for ; Mon, 3 Oct 2005 10:05:00 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 5B0CA52CFF; Mon, 3 Oct 2005 12:04:59 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id AE4A052CA9; Mon, 3 Oct 2005 12:04:51 +0200 (CEST) Date: Mon, 3 Oct 2005 12:04:41 +0200 From: Pawel Jakub Dawidek To: freebsd-arch@FreeBSD.org Message-ID: <20051003100440.GB3794@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng devel (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: Tomasz =?iso-8859-2?Q?Pi=B3at?= Subject: Moving /usr/sbin/setkey to /sbin/setkey. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2005 10:05:01 -0000 --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. I'd like to move setkey from /usr/sbin/ to /sbin/. Currently, rc.d/mountcritremote is called before rc.d/ipsec, because someone which want to use setkey(8) can have /usr/ NFS-mounted. Because of this, one cannot protect NFS mounts with IPsec. Moving setkey(8) (like NetBSD did, AFAIK) to /sbin/ and changing the order of rc.d/mountcritremote and rc.d/setkey should solve this chicken-and-egg problem. Any objections? PRs: conf/58832 conf/72135 --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --XsQoSWH+UP9D9v3l Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFDQQI4ForvXbEpPzQRAv6TAJ9xtwIOxFAnjIZvoeTTKh/1JA9nmwCdGFEW 29iE9tuA3Ya/YVGOXmQCGv4= =fAT8 -----END PGP SIGNATURE----- --XsQoSWH+UP9D9v3l-- From owner-freebsd-arch@FreeBSD.ORG Mon Oct 3 10:31:29 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26BE316A41F for ; Mon, 3 Oct 2005 10:31:29 +0000 (GMT) (envelope-from ceri@submonkey.net) Received: from shrike.submonkey.net (cpc2-cdif2-3-1-cust208.cdif.cable.ntl.com [82.31.78.208]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D41043D4C for ; Mon, 3 Oct 2005 10:31:28 +0000 (GMT) (envelope-from ceri@submonkey.net) Received: from ceri by shrike.submonkey.net with local (Exim 4.53 (FreeBSD)) id 1EMNbQ-0005aG-UW; Mon, 03 Oct 2005 11:31:24 +0100 Date: Mon, 3 Oct 2005 11:31:24 +0100 From: Ceri Davies To: Brooks Davis Message-ID: <20051003103124.GB56760@submonkey.net> Mail-Followup-To: Ceri Davies , Brooks Davis , arch@freebsd.org References: <20051001093550.GA32354@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline In-Reply-To: <20051001093550.GA32354@odin.ac.hmc.edu> X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.11 Sender: Ceri Davies Cc: arch@freebsd.org Subject: Re: error in trimdomain(3) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2005 10:31:29 -0000 --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 01, 2005 at 02:35:50AM -0700, Brooks Davis wrote: > I discovered today that the trimdomain() implementation in libutil deviat= es > slightly from the manpage. The manpage says: >=20 > The function trimdomain() removes the current domain name from the p= assed > fullhost name by writing a NUL character over the first period of the > ^^^^^^^^^^^^ > passed name. The current domain name is determined by calling > gethostname(3) and removing everything up to the first period. >=20 > which clearly indicates that trimdomain() should return either the > unmodified string or a host name with no domain. In reality it will > remove the domain name even if the result is not a host name. This > means that if the host b.com calls trimdomain with "a.b.com" as the > input string, the result is "a.b". That's actually what the excerpt above says will happen. gethostname returns "b.com", removing everything up to the first period yields ".com", and that removed from "a.b.com" gives you "a.b". I don't care if it needs to be changed, but that does exactly what it says on the tin so far as I can see. Ceri --=20 Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. -- Einstein (attrib.) --UlVJffcvxoiEqYs2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDQQh8ocfcwTS3JF8RAtK+AJ9YjN2KjZmoMesWmHKS3qD+5WkGMQCgs1VO dUe2NAsrjlRKnaICsxjCdC0= =F4fV -----END PGP SIGNATURE----- --UlVJffcvxoiEqYs2-- From owner-freebsd-arch@FreeBSD.ORG Mon Oct 3 11:24:56 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9358616A41F; Mon, 3 Oct 2005 11:24:56 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0307143D48; Mon, 3 Oct 2005 11:24:53 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:yOjf9xyGwCSRXhYjqbKoJegWENNcnpfqgl4UMtCC4P8aAG5LDxbUv8ctqKxR53Bt@kasuga-iwi.mahoroba.org [IPv6:3ffe:501:185b:8010:212:f0ff:fe52:6ac]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.4/8.13.4) with ESMTP/inet6 id j93BOTLF088293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Oct 2005 20:24:31 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Mon, 03 Oct 2005 20:24:28 +0900 Message-ID: From: Hajimu UMEMOTO To: Pawel Jakub Dawidek In-Reply-To: <20051003100440.GB3794@garage.freebsd.pl> References: <20051003100440.GB3794@garage.freebsd.pl> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd6.0) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.0-BETA5 X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0 (ameno.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Mon, 03 Oct 2005 20:24:35 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on ameno.mahoroba.org Cc: Tomasz =?ISO-8859-2?Q?Pi=B3at?= , freebsd-arch@FreeBSD.org Subject: Re: Moving /usr/sbin/setkey to /sbin/setkey. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2005 11:24:56 -0000 Hi, >>>>> On Mon, 3 Oct 2005 12:04:41 +0200 >>>>> Pawel Jakub Dawidek said: pjd> I'd like to move setkey from /usr/sbin/ to /sbin/. pjd> Currently, rc.d/mountcritremote is called before rc.d/ipsec, because pjd> someone which want to use setkey(8) can have /usr/ NFS-mounted. pjd> Because of this, one cannot protect NFS mounts with IPsec. pjd> Moving setkey(8) (like NetBSD did, AFAIK) to /sbin/ and changing the pjd> order of rc.d/mountcritremote and rc.d/setkey should solve this pjd> chicken-and-egg problem. pjd> Any objections? pjd> PRs: conf/58832 conf/72135 Yes, it should be done. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-arch@FreeBSD.ORG Mon Oct 3 16:44:55 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 919DE16A41F; Mon, 3 Oct 2005 16:44:55 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA98743D46; Mon, 3 Oct 2005 16:44:54 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.233] (Not Verified[10.50.41.233]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Mon, 03 Oct 2005 13:01:00 -0400 From: John Baldwin To: arch@FreeBSD.org Date: Mon, 3 Oct 2005 12:46:13 -0400 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510031246.14835.jhb@FreeBSD.org> Cc: ru@FreeBSD.org, M.@WarnerLosh Subject: Ethernet driver teardown X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2005 16:44:55 -0000 So, I was thinking about the problem with ethernet driver detach races this morning and had an idea. What if the sequence for detach() was altered such that we called ether_ifdetach() before the driver's stop() routine? Thus, you would end up with something like this: foo_detach() { ether_ifdetach(sc->foo_ifp); FOO_LOCK(sc); foo_stop(sc); FOO_UNLOCK(sc); callout_drain(...); bus_teardown_intr(...); if_free(sc->foo_ifp); bus_release_resources(...); ... } Would that solve the various races including letting BPF turn off promiscuous mode cleanly without requiring detaching flags in each driver to bail out of foo_ioctl()? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Mon Oct 3 17:24:45 2005 Return-Path: X-Original-To: arch@FreeBSD.ORG Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C4AB16A41F; Mon, 3 Oct 2005 17:24:45 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id F198E43D46; Mon, 3 Oct 2005 17:24:44 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j93HOb0r093316; Mon, 3 Oct 2005 11:24:37 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 03 Oct 2005 11:25:26 -0600 (MDT) Message-Id: <20051003.112526.102577313.imp@bsdimp.com> To: jhb@FreeBSD.ORG From: "M. Warner Losh" In-Reply-To: <200510031246.14835.jhb@FreeBSD.org> References: <200510031246.14835.jhb@FreeBSD.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 03 Oct 2005 11:24:37 -0600 (MDT) Cc: arch@FreeBSD.ORG, ru@FreeBSD.ORG Subject: Re: Ethernet driver teardown X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2005 17:24:45 -0000 In message: <200510031246.14835.jhb@FreeBSD.org> John Baldwin writes: : So, I was thinking about the problem with ethernet driver detach races this : morning and had an idea. What if the sequence for detach() was altered such : that we called ether_ifdetach() before the driver's stop() routine? Thus, : you would end up with something like this: : : foo_detach() : { : : ether_ifdetach(sc->foo_ifp); : FOO_LOCK(sc); : foo_stop(sc); ifp->if_drv_flags &= ~IFF_DRV_RUNNING; /* or does foo_stop do this? */ : FOO_UNLOCK(sc); : callout_drain(...); : bus_teardown_intr(...); : if_free(sc->foo_ifp); : bus_release_resources(...); : ... : } : : Would that solve the various races including letting BPF turn off promiscuous : mode cleanly without requiring detaching flags in each driver to bail out of : foo_ioctl()? I'm unusure. I'm prettys sure that the promisc mode would be turned off correctly, but see below. This does represent an improvement over the current method. I have a couple of concerns. (1) What happens to the packets received when the device is detached. We'll have to make sure that the ifp is in a state that can allow for the input routine to still be called w/o leaking memory. (2) Does this solve the problems that I originally suggested a if_dead() routine for? (3) How do we know that we're out of all the ifp callbacks when ether_ifdetach() returns? If we forced a lock/unlock pair for all ioctl functions, then we could know for sure when we acquire the lock. I'm unsure what to do about if_output, if_start and if_watchdog. Warner From owner-freebsd-arch@FreeBSD.ORG Mon Oct 3 18:03:47 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6EFA716A41F for ; Mon, 3 Oct 2005 18:03:47 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1823543D45 for ; Mon, 3 Oct 2005 18:03:44 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j93I3i8l001306; Mon, 3 Oct 2005 11:03:44 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j93I3i31001305; Mon, 3 Oct 2005 11:03:44 -0700 Date: Mon, 3 Oct 2005 11:03:44 -0700 From: Brooks Davis To: Ceri Davies , Brooks Davis , arch@freebsd.org Message-ID: <20051003180344.GA31888@odin.ac.hmc.edu> References: <20051001093550.GA32354@odin.ac.hmc.edu> <20051003103124.GB56760@submonkey.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline In-Reply-To: <20051003103124.GB56760@submonkey.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: Subject: Re: error in trimdomain(3) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2005 18:03:47 -0000 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 03, 2005 at 11:31:24AM +0100, Ceri Davies wrote: > On Sat, Oct 01, 2005 at 02:35:50AM -0700, Brooks Davis wrote: > > I discovered today that the trimdomain() implementation in libutil devi= ates > > slightly from the manpage. The manpage says: > >=20 > > The function trimdomain() removes the current domain name from the= passed > > fullhost name by writing a NUL character over the first period of = the > > ^^^^^^^^^^^^ > > passed name. The current domain name is determined by calling > > gethostname(3) and removing everything up to the first period. > >=20 > > which clearly indicates that trimdomain() should return either the > > unmodified string or a host name with no domain. In reality it will > > remove the domain name even if the result is not a host name. This > > means that if the host b.com calls trimdomain with "a.b.com" as the > > input string, the result is "a.b". >=20 > That's actually what the excerpt above says will happen. >=20 > gethostname returns "b.com", removing everything up to the first period > yields ".com", and that removed from "a.b.com" gives you "a.b". >=20 > I don't care if it needs to be changed, but that does exactly what it > says on the tin so far as I can see. There are two refrences to "first period". You are correct that the domain name of b.com is .com, but the refrence I highlighted states that the only allowable modification to the host name is writing a NUL to the first period in the string (it's actually messier than this because trimdomain also supports X11 DISPLAY strings and thus does a memmove and reterminates if there is a :0 or :0.0 type string after domain.) -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --AhhlLboLdkugWU4S Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDQXJ/XY6L6fI4GtQRAmYjAKCIey3y5h+rQE4o748OBjdgP0W07ACeKnRu d2CQjPwEVv5sKBTedxVIYsY= =IxmP -----END PGP SIGNATURE----- --AhhlLboLdkugWU4S-- From owner-freebsd-arch@FreeBSD.ORG Mon Oct 3 18:18:16 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74C5816A41F for ; Mon, 3 Oct 2005 18:18:16 +0000 (GMT) (envelope-from ceri@submonkey.net) Received: from shrike.submonkey.net (cpc2-cdif2-3-1-cust208.cdif.cable.ntl.com [82.31.78.208]) by mx1.FreeBSD.org (Postfix) with ESMTP id D76CD43D49 for ; Mon, 3 Oct 2005 18:18:15 +0000 (GMT) (envelope-from ceri@submonkey.net) Received: from ceri by shrike.submonkey.net with local (Exim 4.53 (FreeBSD)) id 1EMUt6-000Nx0-Ps; Mon, 03 Oct 2005 19:18:08 +0100 Date: Mon, 3 Oct 2005 19:18:08 +0100 From: Ceri Davies To: Brooks Davis Message-ID: <20051003181808.GI56760@submonkey.net> Mail-Followup-To: Ceri Davies , Brooks Davis , arch@freebsd.org References: <20051001093550.GA32354@odin.ac.hmc.edu> <20051003103124.GB56760@submonkey.net> <20051003180344.GA31888@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0z5c7mBtSy1wdr4F" Content-Disposition: inline In-Reply-To: <20051003180344.GA31888@odin.ac.hmc.edu> X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.11 Sender: Ceri Davies Cc: arch@freebsd.org Subject: Re: error in trimdomain(3) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2005 18:18:16 -0000 --0z5c7mBtSy1wdr4F Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 03, 2005 at 11:03:44AM -0700, Brooks Davis wrote: > On Mon, Oct 03, 2005 at 11:31:24AM +0100, Ceri Davies wrote: > > On Sat, Oct 01, 2005 at 02:35:50AM -0700, Brooks Davis wrote: > > > I discovered today that the trimdomain() implementation in libutil de= viates > > > slightly from the manpage. The manpage says: > > >=20 > > > The function trimdomain() removes the current domain name from t= he passed > > > fullhost name by writing a NUL character over the first period o= f the > > > ^^^^^^^^^^^^ > > > passed name. The current domain name is determined by calling > > > gethostname(3) and removing everything up to the first period. > > >=20 > > > which clearly indicates that trimdomain() should return either the > > > unmodified string or a host name with no domain. In reality it will > > > remove the domain name even if the result is not a host name. This > > > means that if the host b.com calls trimdomain with "a.b.com" as the > > > input string, the result is "a.b". > >=20 > > That's actually what the excerpt above says will happen. > >=20 > > gethostname returns "b.com", removing everything up to the first period > > yields ".com", and that removed from "a.b.com" gives you "a.b". > >=20 > > I don't care if it needs to be changed, but that does exactly what it > > says on the tin so far as I can see. >=20 > There are two refrences to "first period". You are correct that the > domain name of b.com is .com, but the refrence I highlighted states that > the only allowable modification to the host name is writing a NUL to > the first period in the string (it's actually messier than this because > trimdomain also supports X11 DISPLAY strings and thus does a memmove and > reterminates if there is a :0 or :0.0 type string after domain.) I agree that the documentation gives that impressions but the fact that it bothers to call gethostname at all makes me wonder; if it's just going to replace the first period with a NUL then I don't see why that call is necessary, unless the intention is to achieve the current behaviour. Ceri --=20 Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. -- Einstein (attrib.) --0z5c7mBtSy1wdr4F Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDQXXgocfcwTS3JF8RAmJHAJ9u4yAyax8AtVgp9VxYFU02flYgRgCghzPX E9v1sNqo9Z6OmeDIojPSEKU= =APzW -----END PGP SIGNATURE----- --0z5c7mBtSy1wdr4F-- From owner-freebsd-arch@FreeBSD.ORG Mon Oct 3 18:24:07 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 725AB16A41F for ; Mon, 3 Oct 2005 18:24:07 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1783F43D48 for ; Mon, 3 Oct 2005 18:24:06 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j93IO6K4004199; Mon, 3 Oct 2005 11:24:06 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j93IO6nc004198; Mon, 3 Oct 2005 11:24:06 -0700 Date: Mon, 3 Oct 2005 11:24:06 -0700 From: Brooks Davis To: Ceri Davies , Brooks Davis , arch@freebsd.org Message-ID: <20051003182406.GA3629@odin.ac.hmc.edu> References: <20051001093550.GA32354@odin.ac.hmc.edu> <20051003103124.GB56760@submonkey.net> <20051003180344.GA31888@odin.ac.hmc.edu> <20051003181808.GI56760@submonkey.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline In-Reply-To: <20051003181808.GI56760@submonkey.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: Subject: Re: error in trimdomain(3) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2005 18:24:07 -0000 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 03, 2005 at 07:18:08PM +0100, Ceri Davies wrote: > On Mon, Oct 03, 2005 at 11:03:44AM -0700, Brooks Davis wrote: > > On Mon, Oct 03, 2005 at 11:31:24AM +0100, Ceri Davies wrote: > > > On Sat, Oct 01, 2005 at 02:35:50AM -0700, Brooks Davis wrote: > > > > I discovered today that the trimdomain() implementation in libutil = deviates > > > > slightly from the manpage. The manpage says: > > > >=20 > > > > The function trimdomain() removes the current domain name from= the passed > > > > fullhost name by writing a NUL character over the first period= of the > > > > ^^^^^^^^^^^^ > > > > passed name. The current domain name is determined by calling > > > > gethostname(3) and removing everything up to the first period. > > > >=20 > > > > which clearly indicates that trimdomain() should return either the > > > > unmodified string or a host name with no domain. In reality it will > > > > remove the domain name even if the result is not a host name. This > > > > means that if the host b.com calls trimdomain with "a.b.com" as the > > > > input string, the result is "a.b". > > >=20 > > > That's actually what the excerpt above says will happen. > > >=20 > > > gethostname returns "b.com", removing everything up to the first peri= od > > > yields ".com", and that removed from "a.b.com" gives you "a.b". > > >=20 > > > I don't care if it needs to be changed, but that does exactly what it > > > says on the tin so far as I can see. > >=20 > > There are two refrences to "first period". You are correct that the > > domain name of b.com is .com, but the refrence I highlighted states that > > the only allowable modification to the host name is writing a NUL to > > the first period in the string (it's actually messier than this because > > trimdomain also supports X11 DISPLAY strings and thus does a memmove and > > reterminates if there is a :0 or :0.0 type string after domain.) >=20 > I agree that the documentation gives that impressions but the fact that > it bothers to call gethostname at all makes me wonder; if it's just going > to replace the first period with a NUL then I don't see why that call is > necessary, unless the intention is to achieve the current behaviour. My interpretation is that the function is intended to remove the domain only if it is the local domain and thus implicit. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --+HP7ph2BbKc20aGI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDQXdFXY6L6fI4GtQRAulVAJ9fYV3Nckx+X/DU25m+FhrIPieCigCcDgvr 8205z7fRsH5DnjEQF/NPdXI= =WcSO -----END PGP SIGNATURE----- --+HP7ph2BbKc20aGI-- From owner-freebsd-arch@FreeBSD.ORG Mon Oct 3 18:44:10 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4773516A420 for ; Mon, 3 Oct 2005 18:44:10 +0000 (GMT) (envelope-from ceri@submonkey.net) Received: from shrike.submonkey.net (cpc2-cdif2-3-1-cust208.cdif.cable.ntl.com [82.31.78.208]) by mx1.FreeBSD.org (Postfix) with ESMTP id B005443D53 for ; Mon, 3 Oct 2005 18:44:08 +0000 (GMT) (envelope-from ceri@submonkey.net) Received: from ceri by shrike.submonkey.net with local (Exim 4.53 (FreeBSD)) id 1EMVIF-000Pwl-Qo; Mon, 03 Oct 2005 19:44:07 +0100 Date: Mon, 3 Oct 2005 19:44:07 +0100 From: Ceri Davies To: Brooks Davis Message-ID: <20051003184407.GJ56760@submonkey.net> Mail-Followup-To: Ceri Davies , Brooks Davis , arch@freebsd.org References: <20051001093550.GA32354@odin.ac.hmc.edu> <20051003103124.GB56760@submonkey.net> <20051003180344.GA31888@odin.ac.hmc.edu> <20051003181808.GI56760@submonkey.net> <20051003182406.GA3629@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WRT3RXLOp/bBMgTI" Content-Disposition: inline In-Reply-To: <20051003182406.GA3629@odin.ac.hmc.edu> X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.11 Sender: Ceri Davies Cc: arch@freebsd.org Subject: Re: error in trimdomain(3) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2005 18:44:10 -0000 --WRT3RXLOp/bBMgTI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 03, 2005 at 11:24:06AM -0700, Brooks Davis wrote: > On Mon, Oct 03, 2005 at 07:18:08PM +0100, Ceri Davies wrote: > > On Mon, Oct 03, 2005 at 11:03:44AM -0700, Brooks Davis wrote: > > > On Mon, Oct 03, 2005 at 11:31:24AM +0100, Ceri Davies wrote: > > > > On Sat, Oct 01, 2005 at 02:35:50AM -0700, Brooks Davis wrote: > > > > > I discovered today that the trimdomain() implementation in libuti= l deviates > > > > > slightly from the manpage. The manpage says: > > > > >=20 > > > > > The function trimdomain() removes the current domain name fr= om the passed > > > > > fullhost name by writing a NUL character over the first peri= od of the > > > > > ^^^^^^^^^^= ^^ > > > > > passed name. The current domain name is determined by calli= ng > > > > > gethostname(3) and removing everything up to the first perio= d. > > > > >=20 > > > > > which clearly indicates that trimdomain() should return either the > > > > > unmodified string or a host name with no domain. In reality it w= ill > > > > > remove the domain name even if the result is not a host name. Th= is > > > > > means that if the host b.com calls trimdomain with "a.b.com" as t= he > > > > > input string, the result is "a.b". > > > >=20 > > > > That's actually what the excerpt above says will happen. > > > >=20 > > > > gethostname returns "b.com", removing everything up to the first pe= riod > > > > yields ".com", and that removed from "a.b.com" gives you "a.b". > > > >=20 > > > > I don't care if it needs to be changed, but that does exactly what = it > > > > says on the tin so far as I can see. > > >=20 > > > There are two refrences to "first period". You are correct that the > > > domain name of b.com is .com, but the refrence I highlighted states t= hat > > > the only allowable modification to the host name is writing a NUL to > > > the first period in the string (it's actually messier than this becau= se > > > trimdomain also supports X11 DISPLAY strings and thus does a memmove = and > > > reterminates if there is a :0 or :0.0 type string after domain.) > >=20 > > I agree that the documentation gives that impressions but the fact that > > it bothers to call gethostname at all makes me wonder; if it's just goi= ng > > to replace the first period with a NUL then I don't see why that call is > > necessary, unless the intention is to achieve the current behaviour. >=20 > My interpretation is that the function is intended to remove the domain > only if it is the local domain and thus implicit. Ah, now I see it; yes, I'm with you. Ceri --=20 Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. -- Einstein (attrib.) --WRT3RXLOp/bBMgTI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDQXv3ocfcwTS3JF8RAtcdAJ942llczaTBFXnzbJMDnHV9y9c1PgCgqAzv cqQgllQ/FDho4l5kTHreb5A= =anH9 -----END PGP SIGNATURE----- --WRT3RXLOp/bBMgTI-- From owner-freebsd-arch@FreeBSD.ORG Tue Oct 4 19:09:46 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAC8716A41F for ; Tue, 4 Oct 2005 19:09:46 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F3A643D45 for ; Tue, 4 Oct 2005 19:09:46 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by mail.ambrisko.com with ESMTP; 04 Oct 2005 12:09:46 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.12.11/8.12.9) with ESMTP id j94J9kxp093233; Tue, 4 Oct 2005 12:09:46 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.12.11/8.12.11/Submit) id j94J9jvd093228; Tue, 4 Oct 2005 12:09:45 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200510041909.j94J9jvd093228@ambrisko.com> In-Reply-To: <20050925002212.GA77857@heff.fud.org.nz> To: PeterJeremy@optushome.com.au Date: Tue, 4 Oct 2005 12:09:45 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-arch@freebsd.org Subject: Re: Bridges X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2005 19:09:47 -0000 On Sun, Sep 25, 2005 at 05:22:38AM +1000, Peter Jeremy wrote: > On Sat, 2005-Sep-24 15:25:06 +0200, Max Laier wrote: > >for some time now, we have three bridge implementations in the tree: > > - net/bridge.c - the "old" bridge > > - net/if_bridge.c - the "new" bridge from Net/OpenBSD > > - netgraph/ng_bridge.c - the netgraph version [1] > > > >The new code has several advantages over the old version: > > - Spanning Tree Protocol (802.1D) > > - better firewall support (IPv6, stateful filtering, ...) > > - easy ifconfig(8) configuration > > Since I've recently needed it, neither bridge.c nor if_bridge.c allow > you to bridge VLAN trunks (you can bridge individual VLANs but that > becomes unwieldly when you have dozens of VLANs). I have code to do > this in bridge.c. I think I ran into the related problem. The vlan device calls IFQ_HANDOFF directly versus the "normal" output bits so you can't use netgraph etc. I broke up ether_output so that I could call the stuff that ether_output does so it would go through netgraph hooks if configured. Doug A. From owner-freebsd-arch@FreeBSD.ORG Wed Oct 5 07:40:09 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB39516A41F for ; Wed, 5 Oct 2005 07:40:09 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vbook.fbsd.ru (swsoft-mipt-nat.sw.ru [195.214.233.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F5D243D46 for ; Wed, 5 Oct 2005 07:40:09 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.53 (FreeBSD)) id 1EN3sk-0000jz-D1; Wed, 05 Oct 2005 11:40:06 +0400 From: Vladimir Grebenschikov To: Max Laier In-Reply-To: <200509241525.16173.max@love2party.net> References: <200509241525.16173.max@love2party.net> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Wed, 05 Oct 2005 11:40:05 +0400 Message-Id: <1128498005.2404.14.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.4.0 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: freebsd-arch@freebsd.org Subject: Re: Bridges X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2005 07:40:09 -0000 =F7 =D3=C2, 24/09/2005 =D7 15:25 +0200, Max Laier =D0=C9=DB=C5=D4: > All, > Objections against soon retirement of bridge.c in HEAD? There is minor build issue, if_bridge.ko kan't be loaded if kernel built without IPv6 support: # kldload /boot/kernel/if_bridge.ko kldload: can't load /boot/kernel/if_bridge.ko: No such file or directory # dmesg | tail -n 1 link_elf: symbol ip6stat undefined # --=20 Vladimir B. Grebenschikov vova@fbsd.ru From owner-freebsd-arch@FreeBSD.ORG Wed Oct 5 10:15:57 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CFD816A41F for ; Wed, 5 Oct 2005 10:15:57 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEB6643D48 for ; Wed, 5 Oct 2005 10:15:56 +0000 (GMT) (envelope-from max@love2party.net) Received: from p54A3C7CF.dip.t-dialin.net [84.163.199.207] (helo=donor.laier.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0MKwtQ-1EN6JL1NQz-0008Vv; Wed, 05 Oct 2005 12:15:43 +0200 From: Max Laier To: freebsd-arch@freebsd.org, vova@fbsd.ru Date: Wed, 5 Oct 2005 12:16:45 +0200 User-Agent: KMail/1.8.2 References: <200509241525.16173.max@love2party.net> <1128498005.2404.14.camel@localhost> In-Reply-To: <1128498005.2404.14.camel@localhost> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1203826.G0qHZVbdyl"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200510051216.58096.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Subject: Re: Bridges X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2005 10:15:57 -0000 --nextPart1203826.G0qHZVbdyl Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 05 October 2005 09:40, Vladimir Grebenschikov wrote: > =F7 =D3=C2, 24/09/2005 =D7 15:25 +0200, Max Laier =D0=C9=DB=C5=D4: > > All, > > > > Objections against soon retirement of bridge.c in HEAD? > > There is minor build issue, if_bridge.ko kan't be loaded if kernel built > without IPv6 support: > > # kldload /boot/kernel/if_bridge.ko > kldload: can't load /boot/kernel/if_bridge.ko: No such file or directory > # dmesg | tail -n 1 > link_elf: symbol ip6stat undefined > # Define NO_INET6 in make.conf and rebuild the module. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1203826.G0qHZVbdyl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDQ6gaXyyEoT62BG0RArhwAJ9hDstHNpEFB7Q2yrsewu59LkUr2wCdH+tp 6ljSzFSaNJRGQMAm3rnNv9s= =ViyY -----END PGP SIGNATURE----- --nextPart1203826.G0qHZVbdyl-- From owner-freebsd-arch@FreeBSD.ORG Thu Oct 6 08:44:39 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 442D316A41F for ; Thu, 6 Oct 2005 08:44:39 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id A422243D49 for ; Thu, 6 Oct 2005 08:44:35 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j968hrfW068479; Thu, 6 Oct 2005 12:43:53 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j968hqmA068478; Thu, 6 Oct 2005 12:43:52 +0400 (MSD) (envelope-from yar) Date: Thu, 6 Oct 2005 12:43:52 +0400 From: Yar Tikhiy To: Max Laier Message-ID: <20051006084352.GA66584@comp.chem.msu.su> References: <200509241525.16173.max@love2party.net> <1128498005.2404.14.camel@localhost> <200510051216.58096.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200510051216.58096.max@love2party.net> User-Agent: Mutt/1.5.9i Cc: vova@fbsd.ru, freebsd-arch@freebsd.org Subject: Re: Bridges X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2005 08:44:39 -0000 On Wed, Oct 05, 2005 at 12:16:45PM +0200, Max Laier wrote: > On Wednesday 05 October 2005 09:40, Vladimir Grebenschikov wrote: > > > > There is minor build issue, if_bridge.ko kan't be loaded if kernel built > > without IPv6 support: > > > > # kldload /boot/kernel/if_bridge.ko > > kldload: can't load /boot/kernel/if_bridge.ko: No such file or directory > > # dmesg | tail -n 1 > > link_elf: symbol ip6stat undefined > > # > > Define NO_INET6 in make.conf and rebuild the module. In fact, this behavior is an ill side-effect from MODULES_WITH_WORLD stuff. ru@ and yours truly are working on fixing this side-effect (and then removing the evil stuff ;-) When our fix is in the tree, all modules will be able to pick up kernel options from the current set of kernel's opt_*.h files instead of rolling their own versions. This possibility has been there for a while, but modules' Makefiles just ignored it. Of course, one'll need to build modules along with the kernel, not separately. -- Yar From owner-freebsd-arch@FreeBSD.ORG Thu Oct 6 08:57:25 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A277916A41F for ; Thu, 6 Oct 2005 08:57:25 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63C3143D58 for ; Thu, 6 Oct 2005 08:57:21 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j968vHWa068982 for ; Thu, 6 Oct 2005 12:57:17 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j968vH3C068977 for arch@freebsd.org; Thu, 6 Oct 2005 12:57:17 +0400 (MSD) (envelope-from yar) Date: Thu, 6 Oct 2005 12:57:17 +0400 From: Yar Tikhiy To: arch@freebsd.org Message-ID: <20051006085716.GB66584@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Cc: Subject: Any reason for no ostrip? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2005 08:57:25 -0000 All, I've been missing the ostrip terminal option for quite a while. Frankly, it is of use mostly to Cyrillic users because our main Unix encoding, KOI8, has a funny property: It can be readable if mapped to US-ASCII by stripping the high bit, so if you happen to land at a terminal w/o Cyrillic support, you still can read your mail if you manage to strip the 8th bit off. Unfortunately, far from all terminals, hardware as well as software, have an option to strip the 8th bit. Since we have istrip already, adding ostrip would be just complementary. Any objections? -- Yar From owner-freebsd-arch@FreeBSD.ORG Thu Oct 6 10:32:07 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A6F616A41F for ; Thu, 6 Oct 2005 10:32:07 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20DAF43D45 for ; Thu, 6 Oct 2005 10:32:07 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 7CF3DBC74; Thu, 6 Oct 2005 10:32:05 +0000 (UTC) To: Yar Tikhiy From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 06 Oct 2005 12:57:17 +0400." <20051006085716.GB66584@comp.chem.msu.su> Date: Thu, 06 Oct 2005 12:32:05 +0200 Message-ID: <10436.1128594725@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@freebsd.org Subject: Re: Any reason for no ostrip? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2005 10:32:07 -0000 In message <20051006085716.GB66584@comp.chem.msu.su>, Yar Tikhiy writes: >All, > >I've been missing the ostrip terminal option for quite a while. >Frankly, it is of use mostly to Cyrillic users because our main >Unix encoding, KOI8, has a funny property: It can be readable if >mapped to US-ASCII by stripping the high bit, so if you happen to >land at a terminal w/o Cyrillic support, you still can read your >mail if you manage to strip the 8th bit off. Unfortunately, far >from all terminals, hardware as well as software, have an option >to strip the 8th bit. Since we have istrip already, adding ostrip >would be just complementary. Any objections? Couldn't you get the same result with cs7 and space parity ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Thu Oct 6 11:21:10 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8B6416A41F for ; Thu, 6 Oct 2005 11:21:10 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81F9243D45 for ; Thu, 6 Oct 2005 11:21:09 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j96BL6hE077036; Thu, 6 Oct 2005 15:21:06 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j96BL56P077035; Thu, 6 Oct 2005 15:21:05 +0400 (MSD) (envelope-from yar) Date: Thu, 6 Oct 2005 15:21:05 +0400 From: Yar Tikhiy To: Poul-Henning Kamp Message-ID: <20051006112105.GA76625@comp.chem.msu.su> References: <20051006085716.GB66584@comp.chem.msu.su> <10436.1128594725@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10436.1128594725@critter.freebsd.dk> User-Agent: Mutt/1.5.9i Cc: arch@freebsd.org Subject: Re: Any reason for no ostrip? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2005 11:21:10 -0000 On Thu, Oct 06, 2005 at 12:32:05PM +0200, Poul-Henning Kamp wrote: > In message <20051006085716.GB66584@comp.chem.msu.su>, Yar Tikhiy writes: > >All, > > > >I've been missing the ostrip terminal option for quite a while. > >Frankly, it is of use mostly to Cyrillic users because our main > >Unix encoding, KOI8, has a funny property: It can be readable if > >mapped to US-ASCII by stripping the high bit, so if you happen to > >land at a terminal w/o Cyrillic support, you still can read your > >mail if you manage to strip the 8th bit off. Unfortunately, far > >from all terminals, hardware as well as software, have an option > >to strip the 8th bit. Since we have istrip already, adding ostrip > >would be just complementary. Any objections? > > Couldn't you get the same result with cs7 and space parity ? I failed to find how to set space parity with stty or termios, but cs7 and cstopb seem just ignored when working over pty (ssh) --I still get 8-bit chars on my end of the connection. I've had no chance to check this with a serial connection yet, but pty is most interesting today anyway. -- Yar From owner-freebsd-arch@FreeBSD.ORG Thu Oct 6 11:29:49 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04C7316A41F for ; Thu, 6 Oct 2005 11:29:49 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id A28A843D48 for ; Thu, 6 Oct 2005 11:29:48 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id EFACFBC6D; Thu, 6 Oct 2005 11:29:46 +0000 (UTC) To: Yar Tikhiy From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 06 Oct 2005 15:21:05 +0400." <20051006112105.GA76625@comp.chem.msu.su> Date: Thu, 06 Oct 2005 13:29:46 +0200 Message-ID: <10734.1128598186@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@freebsd.org Subject: Re: Any reason for no ostrip? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2005 11:29:49 -0000 In message <20051006112105.GA76625@comp.chem.msu.su>, Yar Tikhiy writes: >On Thu, Oct 06, 2005 at 12:32:05PM +0200, Poul-Henning Kamp wrote: Ohh right, ptys don't implement all of that. Well, if you can find a free bit somewhere which does not conflict with POSIX, Linux and other desirable emuluation targets, I don't see why not. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Thu Oct 6 16:17:20 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9A7716A41F; Thu, 6 Oct 2005 16:17:20 +0000 (GMT) (envelope-from _pppp@mail.ru) Received: from f49.mail.ru (f49.mail.ru [194.67.57.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DA1343D6A; Thu, 6 Oct 2005 16:17:19 +0000 (GMT) (envelope-from _pppp@mail.ru) Received: from mail by f49.mail.ru with local id 1ENYQn-000AAm-00; Thu, 06 Oct 2005 20:17:17 +0400 Received: from [212.5.170.174] by win.mail.ru with HTTP; Thu, 06 Oct 2005 20:17:17 +0400 From: dima <_pppp@mail.ru> To: Gleb Smirnoff Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [212.5.170.174] Date: Thu, 06 Oct 2005 20:17:17 +0400 In-Reply-To: <20050930211716.GP45345@cell.sick.ru> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: Cc: arch@FreeBSD.org Subject: Re[2]: [REVIEW/TEST] polling(4) changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dima <_pppp@mail.ru> List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2005 16:17:21 -0000 Seems to be a first considerable step regarding the ideas discussed in March :) But, my idea about the separate locking of each interface dissappeared from this implementation. mtx_poll is good to protect the pollrec array and other sensitive variables. But we could get advantage of SMP machines writing polling loops like this: for( i = 0; i < poll_handlers; ++i ) { mtx_lock( &iface_lock[i] ); pr[i].handler(pr[i].ifp, POLL_ONLY, count); mtx_unlock( &iface_lock[i] ); } From owner-freebsd-arch@FreeBSD.ORG Thu Oct 6 18:34:17 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E10916A41F for ; Thu, 6 Oct 2005 18:34:17 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 814A043D48 for ; Thu, 6 Oct 2005 18:34:16 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id j96IYDIG029007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Oct 2005 22:34:14 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id j96IYDii029006; Thu, 6 Oct 2005 22:34:13 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 6 Oct 2005 22:34:13 +0400 From: Gleb Smirnoff To: dima <_pppp@mail.ru> Message-ID: <20051006183413.GH14542@cell.sick.ru> References: <20050930211716.GP45345@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Cc: arch@FreeBSD.org Subject: Re: [REVIEW/TEST] polling(4) changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2005 18:34:17 -0000 On Thu, Oct 06, 2005 at 08:17:17PM +0400, dima wrote: d> Seems to be a first considerable step regarding the ideas discussed in March :) d> But, my idea about the separate locking of each interface dissappeared from this implementation. mtx_poll is good to protect the pollrec array and other sensitive variables. But we could get advantage of SMP machines writing polling loops like this: d> d> for( i = 0; i < poll_handlers; ++i ) { d> mtx_lock( &iface_lock[i] ); d> pr[i].handler(pr[i].ifp, POLL_ONLY, count); d> mtx_unlock( &iface_lock[i] ); d> } What is the benefit here? The driver must have its own lock. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-arch@FreeBSD.ORG Fri Oct 7 09:29:02 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38F2016A420; Fri, 7 Oct 2005 09:29:02 +0000 (GMT) (envelope-from _pppp@mail.ru) Received: from f44.mail.ru (f44.mail.ru [194.67.57.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2294343D66; Fri, 7 Oct 2005 09:28:59 +0000 (GMT) (envelope-from _pppp@mail.ru) Received: from mail by f44.mail.ru with local id 1ENoXC-000CxD-00; Fri, 07 Oct 2005 13:28:58 +0400 Received: from [212.5.170.174] by win.mail.ru with HTTP; Fri, 07 Oct 2005 13:28:58 +0400 From: dima <_pppp@mail.ru> To: Gleb Smirnoff Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [212.5.170.174] Date: Fri, 07 Oct 2005 13:28:58 +0400 In-Reply-To: <20051006183413.GH14542@cell.sick.ru> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: Cc: arch@FreeBSD.org Subject: Re[2]: [REVIEW/TEST] polling(4) changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dima <_pppp@mail.ru> List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2005 09:29:02 -0000 > d> Seems to be a first considerable step regarding the ideas discussed in March :) > d> But, my idea about the separate locking of each interface dissappeared from this implementation. mtx_poll is good to protect the pollrec array and other sensitive variables. But we could get advantage of SMP machines writing polling loops like this: > d> > d> for( i = 0; i < poll_handlers; ++i ) { > d> mtx_lock( &iface_lock[i] ); > d> pr[i].handler(pr[i].ifp, POLL_ONLY, count); > d> mtx_unlock( &iface_lock[i] ); > d> } > > What is the benefit here? The driver must have its own lock. Well, consider the absense of the mtx_poll lock: - mtx_lock( &mtx_poll ); for( i = 0; i < poll_handlers; ++i ) { + mtx_lock( &iface_lock[i] ); pr[i].handler( pr[i].ifp, POLL_ONLY, count ); + mtx_unlock( &iface_lock[i] ); } - mtx_unlock( &mtx_poll ); So, several kernel threads in an SMP machine can poll different interfaces simultaneously. And mtx_lock should only be used in ether_poll_[de]register(). From owner-freebsd-arch@FreeBSD.ORG Fri Oct 7 09:35:40 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4701116A41F; Fri, 7 Oct 2005 09:35:40 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C06943D48; Fri, 7 Oct 2005 09:35:40 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id j979ZdwL005325; Fri, 7 Oct 2005 02:35:39 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j979ZdRt005324; Fri, 7 Oct 2005 02:35:39 -0700 (PDT) (envelope-from rizzo) Date: Fri, 7 Oct 2005 02:35:39 -0700 From: Luigi Rizzo To: dima <_pppp@mail.ru> Message-ID: <20051007023539.B5081@xorpc.icir.org> References: <20051006183413.GH14542@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from _pppp@mail.ru on Fri, Oct 07, 2005 at 01:28:58PM +0400 Cc: arch@freebsd.org, Gleb Smirnoff Subject: Re: [REVIEW/TEST] polling(4) changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2005 09:35:40 -0000 On Fri, Oct 07, 2005 at 01:28:58PM +0400, dima wrote: > > d> Seems to be a first considerable step regarding the ideas discussed in March :) > > d> But, my idea about the separate locking of each interface dissappeared from this implementation. mtx_poll is good to protect the pollrec array and other sensitive variables. But we could get advantage of SMP machines writing polling loops like this: > > d> > > d> for( i = 0; i < poll_handlers; ++i ) { > > d> mtx_lock( &iface_lock[i] ); > > d> pr[i].handler(pr[i].ifp, POLL_ONLY, count); > > d> mtx_unlock( &iface_lock[i] ); > > d> } > > > > What is the benefit here? The driver must have its own lock. > > Well, consider the absense of the mtx_poll lock: > > - mtx_lock( &mtx_poll ); > for( i = 0; i < poll_handlers; ++i ) { > + mtx_lock( &iface_lock[i] ); > pr[i].handler( pr[i].ifp, POLL_ONLY, count ); > + mtx_unlock( &iface_lock[i] ); > } > - mtx_unlock( &mtx_poll ); > > So, several kernel threads in an SMP machine can poll different interfaces simultaneously. And mtx_lock should only be used in ether_poll_[de]register(). and spend their time fighting for the locks. The "ideas discussed in march" tried to point out exactly that problem. cheers luigi > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Fri Oct 7 09:47:15 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E97A16A41F for ; Fri, 7 Oct 2005 09:47:15 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E52843D46 for ; Fri, 7 Oct 2005 09:47:14 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id j979lCJS038501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Oct 2005 13:47:13 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id j979lCuh038500; Fri, 7 Oct 2005 13:47:12 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 7 Oct 2005 13:47:12 +0400 From: Gleb Smirnoff To: dima <_pppp@mail.ru> Message-ID: <20051007094712.GK14542@cell.sick.ru> References: <20051006183413.GH14542@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Cc: arch@FreeBSD.org Subject: Re: [REVIEW/TEST] polling(4) changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2005 09:47:15 -0000 dima, On Fri, Oct 07, 2005 at 01:28:58PM +0400, dima wrote: d> > d> Seems to be a first considerable step regarding the ideas discussed in March :) d> > d> But, my idea about the separate locking of each interface dissappeared from this implementation. mtx_poll is good to protect the pollrec array and other sensitive variables. But we could get advantage of SMP machines writing polling loops like this: d> > d> d> > d> for( i = 0; i < poll_handlers; ++i ) { d> > d> mtx_lock( &iface_lock[i] ); d> > d> pr[i].handler(pr[i].ifp, POLL_ONLY, count); d> > d> mtx_unlock( &iface_lock[i] ); d> > d> } d> > d> > What is the benefit here? The driver must have its own lock. d> d> Well, consider the absense of the mtx_poll lock: d> d> - mtx_lock( &mtx_poll ); d> for( i = 0; i < poll_handlers; ++i ) { d> + mtx_lock( &iface_lock[i] ); d> pr[i].handler( pr[i].ifp, POLL_ONLY, count ); d> + mtx_unlock( &iface_lock[i] ); d> } d> - mtx_unlock( &mtx_poll ); d> d> So, several kernel threads in an SMP machine can poll different interfaces simultaneously. And mtx_lock should only be used in ether_poll_[de]register(). Imagining that we will have several polling threads in future, the above design has some disadvantages, I think: First, we still need to protect the array pr[], with some mutex while traversing it, and while editing it in ether_poll_[de]register. May be like it was done in kern_poll.c, rev 1.21. Second, the approach above won't give a nice parallelization. Imagine two threads, both working in a cycle shown above. They will contest on the lock of each interface: - t1 starts - t1 locks iface_lock[1] - t2 starts - t1 polls pr[1]... - t2 blocks on iface_lock[1] - t1 polls pr[1]... - t1 polls pr[1]... - t1 polls pr[1]... - t1 polls pr[1]... - t1 unlocks iface_lock[1] - t2 locks iface_lock[1] - t1 locks iface_lock[2] - t2 polls empty pr[1], quickly returns - t1 polls pr[2]... - t2 unlocks iface_lock[1] - t1 polls pr[2]... - t2 blocks on iface_lock[2] - t1 polls pr[2]... - t1 polls pr[2]... - t1 polls pr[2]... - t1 polls pr[2]... - t1 unlocks iface_lock[2] - t2 locks iface_lock[2] - t1 locks iface_lock[3] - t2 polls empty pr[2], quickly returns - t1 polls pr[3]... - t2 unlocks iface_lock[2] So, one thread works, and other just goes after the first one, and picks only a small number of packets, or even just wastes CPU cycles. Really we do not have several kernel threads in polling. netisr_poll() is always run by one thread - swi1:net. Well, we have also idle_poll thread, but it is very special case. Frankly speaking, it can't work without help from netisr_poll(). The current polling is designed for a single threaded kernel, for RELENG_4. We can't achieve parallelization with strong redesign. The future plans are to create per-interface CPU bound threads. The plans can change. You are welcome to help. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-arch@FreeBSD.ORG Fri Oct 7 10:18:44 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4808416A41F; Fri, 7 Oct 2005 10:18:44 +0000 (GMT) (envelope-from _pppp@mail.ru) Received: from f7.mail.ru (f7.mail.ru [194.67.57.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9C4E43D45; Fri, 7 Oct 2005 10:18:43 +0000 (GMT) (envelope-from _pppp@mail.ru) Received: from mail by f7.mail.ru with local id 1ENpJK-000Gys-00; Fri, 07 Oct 2005 14:18:42 +0400 Received: from [212.5.170.174] by win.mail.ru with HTTP; Fri, 07 Oct 2005 14:18:42 +0400 From: dima <_pppp@mail.ru> To: Gleb Smirnoff Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [212.5.170.174] Date: Fri, 07 Oct 2005 14:18:42 +0400 In-Reply-To: <20051007094712.GK14542@cell.sick.ru> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: Cc: arch@FreeBSD.org Subject: Re[2]: [REVIEW/TEST] polling(4) changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dima <_pppp@mail.ru> List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2005 10:18:44 -0000 > d> > d> Seems to be a first considerable step regarding the ideas discussed in March :) > d> > d> But, my idea about the separate locking of each interface dissappeared from this implementation. mtx_poll is good to protect the pollrec array and other sensitive variables. But we could get advantage of SMP machines writing polling loops like this: > d> > d> > d> > d> for( i = 0; i < poll_handlers; ++i ) { > d> > d> mtx_lock( &iface_lock[i] ); > d> > d> pr[i].handler(pr[i].ifp, POLL_ONLY, count); > d> > d> mtx_unlock( &iface_lock[i] ); > d> > d> } > d> > > d> > What is the benefit here? The driver must have its own lock. > d> > d> Well, consider the absense of the mtx_poll lock: > d> > d> - mtx_lock( &mtx_poll ); > d> for( i = 0; i < poll_handlers; ++i ) { > d> + mtx_lock( &iface_lock[i] ); > d> pr[i].handler( pr[i].ifp, POLL_ONLY, count ); > d> + mtx_unlock( &iface_lock[i] ); > d> } > d> - mtx_unlock( &mtx_poll ); > d> > d> So, several kernel threads in an SMP machine can poll different interfaces simultaneously. And mtx_lock should only be used in ether_poll_[de]register(). > > Imagining that we will have several polling threads in future, the above design > has some disadvantages, I think: > > First, we still need to protect the array pr[], with some mutex while traversing > it, and while editing it in ether_poll_[de]register. May be like it was done in > kern_poll.c, rev 1.21. > > Second, the approach above won't give a nice parallelization. Imagine two threads, > both working in a cycle shown above. They will contest on the lock of each interface: > > - t1 starts > - t1 locks iface_lock[1] - t2 starts > - t1 polls pr[1]... - t2 blocks on iface_lock[1] > - t1 polls pr[1]... > - t1 polls pr[1]... > - t1 polls pr[1]... > - t1 polls pr[1]... > - t1 unlocks iface_lock[1] - t2 locks iface_lock[1] > - t1 locks iface_lock[2] - t2 polls empty pr[1], quickly returns > - t1 polls pr[2]... - t2 unlocks iface_lock[1] > - t1 polls pr[2]... - t2 blocks on iface_lock[2] > - t1 polls pr[2]... > - t1 polls pr[2]... > - t1 polls pr[2]... > - t1 polls pr[2]... > - t1 unlocks iface_lock[2] - t2 locks iface_lock[2] > - t1 locks iface_lock[3] - t2 polls empty pr[2], quickly returns > - t1 polls pr[3]... - t2 unlocks iface_lock[2] > > So, one thread works, and other just goes after the first one, and picks > only a small number of packets, or even just wastes CPU cycles. The loop body should really look like if( mtx_try_lock( &iface_lock[i] ) ) { pr[i].handler( pr[i].ifp, POLL_ONLY, count ); mtx_unlock( &iface_lock[i] ); } I skipped this first to make the idea clearer. > Really we do not have several kernel threads in polling. netisr_poll() is always > run by one thread - swi1:net. Well, we have also idle_poll thread, but it is > very special case. Frankly speaking, it can't work without help from netisr_poll(). > The current polling is designed for a single threaded kernel, for RELENG_4. We > can't achieve parallelization with strong redesign. The future plans are to create > per-interface CPU bound threads. The plans can change. You are welcome to help. idle_poll can significantly increase network response time. I'd suggest per-CPU (not per-interface) threads. This would keep user_frac code much simpler. Not sure about the coding help in the next weeks. My current project is on the pre-release stage and the kid is going to be born soon. I can join a bit later though. From owner-freebsd-arch@FreeBSD.ORG Fri Oct 7 10:22:33 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF08316A41F for ; Fri, 7 Oct 2005 10:22:33 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEF0F43D49 for ; Fri, 7 Oct 2005 10:22:32 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id j97AMUSl039077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Oct 2005 14:22:31 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id j97AMUEc039076; Fri, 7 Oct 2005 14:22:30 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 7 Oct 2005 14:22:29 +0400 From: Gleb Smirnoff To: dima <_pppp@mail.ru> Message-ID: <20051007102229.GL14542@cell.sick.ru> References: <20051007094712.GK14542@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Cc: arch@FreeBSD.org Subject: Re: [REVIEW/TEST] polling(4) changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2005 10:22:33 -0000 On Fri, Oct 07, 2005 at 02:18:42PM +0400, dima wrote: d> The loop body should really look like d> if( mtx_try_lock( &iface_lock[i] ) ) { d> pr[i].handler( pr[i].ifp, POLL_ONLY, count ); d> mtx_unlock( &iface_lock[i] ); d> } d> I skipped this first to make the idea clearer. Yes, this approach should be better. d> > Really we do not have several kernel threads in polling. netisr_poll() is always d> > run by one thread - swi1:net. Well, we have also idle_poll thread, but it is d> > very special case. Frankly speaking, it can't work without help from netisr_poll(). d> > The current polling is designed for a single threaded kernel, for RELENG_4. We d> > can't achieve parallelization with strong redesign. The future plans are to create d> > per-interface CPU bound threads. The plans can change. You are welcome to help. d> d> idle_poll can significantly increase network response time. I'd suggest per-CPU (not per-interface) threads. This would keep user_frac code much simpler. No, please don't spawn more idle_poll threads! :) As said, the idle_poll thread can't work on its own. idle_poll needs netisr_poll() to push it sometimes out of the priority pit. It is described in first mail of this thread. d> Not sure about the coding help in the next weeks. My current project is on the pre-release stage and the kid is going to be born soon. I can join a bit later though. There is no promises in the free project. Join when you can. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-arch@FreeBSD.ORG Fri Oct 7 11:38:38 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A27816A423; Fri, 7 Oct 2005 11:38:38 +0000 (GMT) (envelope-from _pppp@mail.ru) Received: from f19.mail.ru (f19.mail.ru [194.67.57.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEA3E43D46; Fri, 7 Oct 2005 11:38:37 +0000 (GMT) (envelope-from _pppp@mail.ru) Received: from mail by f19.mail.ru with local id 1ENqYe-0006Z2-00; Fri, 07 Oct 2005 15:38:36 +0400 Received: from [212.5.170.174] by win.mail.ru with HTTP; Fri, 07 Oct 2005 15:38:36 +0400 From: dima <_pppp@mail.ru> To: Gleb Smirnoff Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [212.5.170.174] Date: Fri, 07 Oct 2005 15:38:36 +0400 In-Reply-To: <20051007102229.GL14542@cell.sick.ru> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: Cc: arch@FreeBSD.org Subject: Re[2]: [REVIEW/TEST] polling(4) changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dima <_pppp@mail.ru> List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2005 11:38:38 -0000 > d> The loop body should really look like > d> if( mtx_try_lock( &iface_lock[i] ) ) { > d> pr[i].handler( pr[i].ifp, POLL_ONLY, count ); > d> mtx_unlock( &iface_lock[i] ); > d> } > d> I skipped this first to make the idea clearer. > > Yes, this approach should be better. > > d> > Really we do not have several kernel threads in polling. netisr_poll() is always > d> > run by one thread - swi1:net. Well, we have also idle_poll thread, but it is > d> > very special case. Frankly speaking, it can't work without help from netisr_poll(). > d> > The current polling is designed for a single threaded kernel, for RELENG_4. We > d> > can't achieve parallelization with strong redesign. The future plans are to create > d> > per-interface CPU bound threads. The plans can change. You are welcome to help. > d> > d> idle_poll can significantly increase network response time. I'd suggest per-CPU (not per-interface) threads. This would keep user_frac code much simpler. > > No, please don't spawn more idle_poll threads! :) Not idle_poll but swi threads actually. Btw, the loop discussed is just the same in ether_poll() and netisr_poll(). It could be splitted as a separate (inline?) function. Such complex macros aren't any good ;) > As said, the idle_poll thread can't work on its own. idle_poll needs netisr_poll() > to push it sometimes out of the priority pit. It is described in first mail of > this thread. idle_poll should surely remain a single entity. > > d> Not sure about the coding help in the next weeks. My current project is on the pre-release stage and the kid is going to be born soon. I can join a bit later though. > > There is no promises in the free project. Join when you can. From owner-freebsd-arch@FreeBSD.ORG Fri Oct 7 14:22:57 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD31416A41F for ; Fri, 7 Oct 2005 14:22:57 +0000 (GMT) (envelope-from lovelorn@brekke.com) Received: from dky118.neoplus.adsl.tpnet.pl (dky118.neoplus.adsl.tpnet.pl [83.24.28.118]) by mx1.FreeBSD.org (Postfix) with SMTP id 30D8643D48 for ; Fri, 7 Oct 2005 14:22:46 +0000 (GMT) (envelope-from lovelorn@brekke.com) Received: from unknown (HELO rifled) (192.168.76.240) by dky118.neoplus.adsl.tpnet.pl with SMTP; Fri, 7 Oct 2005 02:41:24 +0200 Content-Transfer-Encoding: 7bit Message-Id: <5677105625.12372129640@dky118.neoplus.adsl.tpnet.pl> Content-Type: text/plain; charset=us-ascii To: freebsd-arch@freebsd.org From: Fidelia Bonilla Date: Fri, 7 Oct 2005 14:22:46 +0000 (GMT) Subject: Millions of people do it daily to save their privacy and money X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2005 14:22:57 -0000 New and unique way to take care of medical needs at an afordable price online. http://ywcyma.ji6co96sobp91jjvo11doj1j.spinousdl.com/?lscb Too much of a good thing is wonderful. No one can make you feel inferior without your consent. Do not remove a fly from your friend's forehead with a hatchet. The world is a prison in which solitary confinement is preferable. Adultery is the application of democracy to love. Life is meant to be enjoyed, not endured. I don't like that man. I must get to know him better. From owner-freebsd-arch@FreeBSD.ORG Sat Oct 8 02:46:20 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57DB416A41F for ; Sat, 8 Oct 2005 02:46:20 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [63.240.76.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDC2F43D46 for ; Sat, 8 Oct 2005 02:46:19 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from c-66-30-112-178.hsd1.ma.comcast.net ([66.30.112.178]) by comcast.net (sccrmhc11) with ESMTP id <20051008024618011009d731e>; Sat, 8 Oct 2005 02:46:18 +0000 Received: from c-66-30-112-178.hsd1.ma.comcast.net (localhost.127.in-addr.arpa [127.0.0.1]) by c-66-30-112-178.hsd1.ma.comcast.net (8.13.4/8.13.1) with ESMTP id j982kKLW029944 for ; Fri, 7 Oct 2005 22:46:20 -0400 (EDT) (envelope-from rodrigc@c-66-30-112-178.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-30-112-178.hsd1.ma.comcast.net (8.13.4/8.13.1/Submit) id j982kKPX029943 for freebsd-arch@freebsd.org; Fri, 7 Oct 2005 22:46:20 -0400 (EDT) (envelope-from rodrigc) Date: Fri, 7 Oct 2005 22:46:20 -0400 From: Craig Rodrigues To: freebsd-arch@freebsd.org Message-ID: <20051008024620.GA29824@crodrigues.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: [RFC] Teaching mount(8) to use nmount() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2005 02:46:20 -0000 --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, The mount(8) command-line program that is used in FreeBSD behaves more or less as follows: The mount program will process the command-line arguments, and then fork() and do one of the following: -> The filesystem to mount is UFS, either by specifying "-t ufs" or omitting the -t flag entirely. An internal function mount_ufs() which in turn calls the "old-style" mount() syscall to actually mount the filesystem -> If you specify some other filesystem, "-t myfoofs", then the mount program will exec() a copy of "mount_myfoofs", passing the command-line parameters that are necessary to mount the FS. If someone comes along with a new filesystem, they then need to create a new mount_mynewfs binary, in order to mount the filesystem with mount -t mynewfs. This is OK, but leads to a plethora of mount_* binaries which are probably unnecessary. I think that the mount program should eventually do the following: -> for most filesystems (including UFS), the mount program should parse command-line arguments, and invoke the new nmount() syscall -> for very exceptional cases (not to be encouraged), like NFS, SMBFS, etc., instead of calling nmount() directly, we can fork() a new mount_nfs, mount_smbfs, etc. binary and do the mount Since I don't know how all the existing mount programs work, and I don't know the dependencies on how UFS mounting works, I propose an interim behavior for mount: if (filesystem_to_mount == "ufs" ) { call special mount_ufs() function } else if (filesystem_to_mount == something that needs an external binary) { fork() and exec("mount_somefoofs"); } else { call nmount() } When things get cleaned up, we can eliminate the special mount_ufs() function, and just have everything call nmount(), except for the special cases which need their own mount program. In the list of filesystems which need an external binary, I put all the mount_* binaries I could find on my FreeBSD box except the ones for mount_std, mount_devfs, mount_fdescfs, mount_linprocfs, mount_procfs because: -> all these binaries are copies of mount_std, mount_std checks argv[0] to see how it was invoked. if argv[0] == "mount_std" it is an error else { strip out the mount_ part of argv[0], and nmount() that filesystem } -> so mount_std and friends are basically thin wrappers around nmount I would appreciate any comments on the attached patch. -- Craig Rodrigues rodrigc@crodrigues.org --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mount.txt" ? ktrace.out ? mount ? mount.8.gz Index: Makefile =================================================================== RCS file: /home/ncvs/src/sbin/mount/Makefile,v retrieving revision 1.16 diff -u -u -r1.16 Makefile --- Makefile 7 Oct 2005 02:22:48 -0000 1.16 +++ Makefile 8 Oct 2005 02:23:29 -0000 @@ -2,7 +2,7 @@ # $FreeBSD: src/sbin/mount/Makefile,v 1.16 2005/10/07 02:22:48 rodrigc Exp $ PROG= mount -SRCS= mount.c mount_ufs.c getmntopts.c vfslist.c +SRCS= mount.c mount_fs.c mount_ufs.c getmntopts.c vfslist.c WARNS?= 3 MAN= mount.8 # We do NOT install the getmntopts.3 man page. Index: extern.h =================================================================== RCS file: /home/ncvs/src/sbin/mount/extern.h,v retrieving revision 1.5 diff -u -u -r1.5 extern.h --- extern.h 7 Oct 2005 02:18:20 -0000 1.5 +++ extern.h 8 Oct 2005 02:23:29 -0000 @@ -32,3 +32,4 @@ /* mount_ufs.c */ int mount_ufs(int, char * const []); +int mount_fs(const char *, int, char * const []); Index: mount.c =================================================================== RCS file: /home/ncvs/src/sbin/mount/mount.c,v retrieving revision 1.71 diff -u -u -r1.71 mount.c --- mount.c 7 Oct 2005 02:22:04 -0000 1.71 +++ mount.c 8 Oct 2005 02:23:29 -0000 @@ -120,6 +120,67 @@ 0 }; +static int +use_mountprog(const char *vfstype) +{ + /* XXX: We need to get away from implementing external mount + * programs for every filesystem, and move towards having + * each filesystem properly implement the nmount() system call. + */ + unsigned int i; + const char *fs[] = { + "cd9660", "ext2fs", "mfs", "msdosfs", "nfs", "nfs4", "ntfs", + "nwfs", "nullfs", "portalfs", "reiserfs", "smbfs", "udf", "umapfs", + "unionfs", + NULL + }; + + for (i=0; fs[i] != NULL; ++i) { + if (strcmp(vfstype, fs[i]) == 0) + return 1; + } + + return 0; +} + +static int +exec_mountprog(const char *vfstype, const char *name, const char *execname, + char *const argv[]) +{ + pid_t pid; + int status; + + switch (pid = fork()) { + case -1: /* Error. */ + warn("fork"); + exit (1); + case 0: /* Child. */ + /* Go find an executable. */ + execvP(execname, _PATH_SYSPATH, argv); + if (errno == ENOENT) { + warn("exec %s not found in %s", execname, + _PATH_SYSPATH); + } + exit(1); + default: /* Parent. */ + if (waitpid(pid, &status, 0) < 0) { + warn("waitpid"); + return (1); + } + + if (WIFEXITED(status)) { + if (WEXITSTATUS(status) != 0) + return (WEXITSTATUS(status)); + } else if (WIFSIGNALED(status)) { + warnx("%s: %s", name, sys_siglist[WTERMSIG(status)]); + return (1); + } + break; + } + + return (0); +} + int main(int argc, char *argv[]) { @@ -385,8 +446,7 @@ { const char *argv[100]; struct statfs sf; - pid_t pid; - int argc, i, status; + int argc, i, ret; char *optbuf, execname[PATH_MAX], mntpath[PATH_MAX]; #if __GNUC__ @@ -447,50 +507,26 @@ return (0); } - switch (pid = fork()) { - case -1: /* Error. */ - warn("fork"); - free(optbuf); - return (1); - case 0: /* Child. */ - if (strcmp(vfstype, "ufs") == 0) - exit(mount_ufs(argc, (char * const *) argv)); - - /* Go find an executable. */ - execvP(execname, _PATH_SYSPATH, (char * const *)argv); - if (errno == ENOENT) { - warn("exec mount_%s not found in %s", vfstype, - _PATH_SYSPATH); - } - exit(1); - /* NOTREACHED */ - default: /* Parent. */ - free(optbuf); + if (strcmp(vfstype, "ufs")==0) { + ret = mount_ufs(argc, (char * const *) argv); + } else if (use_mountprog(vfstype)) { + ret = exec_mountprog(vfstype, name, execname, + (char * const *)argv); + } else { + ret = mount_fs(vfstype, argc,(char * const *)argv); + } - if (waitpid(pid, &status, 0) < 0) { - warn("waitpid"); - return (1); - } + free(optbuf); - if (WIFEXITED(status)) { - if (WEXITSTATUS(status) != 0) - return (WEXITSTATUS(status)); - } else if (WIFSIGNALED(status)) { - warnx("%s: %s", name, sys_siglist[WTERMSIG(status)]); + if (verbose) { + if (statfs(name, &sf) < 0) { + warn("statfs %s", name); return (1); } - - if (verbose) { - if (statfs(name, &sf) < 0) { - warn("statfs %s", name); - return (1); - } - if (fstab_style) - putfsent(&sf); - else - prmount(&sf); - } - break; + if (fstab_style) + putfsent(&sf); + else + prmount(&sf); } return (0); Index: mount_fs.c =================================================================== RCS file: mount_fs.c diff -N mount_fs.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ mount_fs.c 8 Oct 2005 02:23:29 -0000 @@ -0,0 +1,139 @@ +/* + * Copyright (c) 1992, 1993, 1994 + * The Regents of the University of California. All rights reserved. + * + * This code is derived from software donated to Berkeley by + * Jan-Simon Pendry. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by the University of + * California, Berkeley and its contributors. + * 4. Neither the name of the University nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#ifndef lint +static const char copyright[] = +"@(#) Copyright (c) 1992, 1993, 1994\n\ + The Regents of the University of California. All rights reserved.\n"; +#endif /* not lint */ + +#ifndef lint +#if 0 +static char sccsid[] = "@(#)mount_fs.c 8.6 (Berkeley) 4/26/95"; +#endif +static const char rcsid[] = + "$Id$"; +#endif /* not lint */ + +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +#include "extern.h" +#include "mntopts.h" + +struct mntopt mopts[] = { + MOPT_STDOPTS, + MOPT_END +}; + +extern int getmnt_silent; + +static void +usage(void) +{ + (void)fprintf(stderr, + "usage: mount_xfs [-t fstype] [-o options] target_fs mount_point\n"); + exit(1); +} + +int +mount_fs(const char *vfstype, int argc, char * const argv[]) +{ + struct iovec *iov; + int iovlen; + int mntflags = 0; + int ch; + char *dev, *dir, mntpath[MAXPATHLEN]; + char fstype[32]; + char *p, *val; + int ret; + int i; + printf("argc is: %d\n", argc); for (i=0; i < argc; ++i) { printf("%d: %s\n", argc, argv[i]); } + strncpy(fstype, vfstype, sizeof(fstype)); + + getmnt_silent = 1; + iov = NULL; + iovlen = 0; + + optind = optreset = 1; /* Reset for parse of new argv. */ + while ((ch = getopt(argc, argv, "o:")) != -1) { + switch(ch) { + case 'o': + getmntopts(optarg, mopts, &mntflags, 0); + p = strchr(optarg, '='); + val = ""; + if (p != NULL) { + *p = '\0'; + val = p + 1; + } + build_iovec(&iov, &iovlen, optarg, val, -1); + break; + case '?': + default: + usage(); + } + } + + argc -= optind; + argv += optind; + printf("argc is: %d\n", argc); + if (argc != 2) + usage(); + + dev = argv[0]; + dir = argv[1]; + + (void)checkpath(dir, mntpath); + (void)rmslashes(dev, dev); + + build_iovec(&iov, &iovlen, "fstype", fstype, -1); + build_iovec(&iov, &iovlen, "fspath", mntpath, -1); + build_iovec(&iov, &iovlen, "from", dev, -1); + + ret = nmount(iov, iovlen, mntflags); + if (ret < 0) + err(1, "%s", dev); + + return (ret); +} --EeQfGwPcQSOJBaQU-- From owner-freebsd-arch@FreeBSD.ORG Sat Oct 8 03:43:40 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3D8316A41F for ; Sat, 8 Oct 2005 03:43:39 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 995EB43D46 for ; Sat, 8 Oct 2005 03:43:39 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by xproxy.gmail.com with SMTP id t15so586164wxc for ; Fri, 07 Oct 2005 20:43:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=HoVrmUvoT/5PKKpyG+DleJWFVBcFJzZ8Yd2Pdg8QK1Ux0d5iSbxuaHC+Rtb2qHKBfibJNceZStRJ4cOro5t34f1JccBtyGcG2XN+BsYeBDqv7wneCeQYoSg9BEzzcQ+cDB9kT0Dpt0td4WRrDaTr6pdWE/MS7LGUx6gIiWTCk3E= Received: by 10.70.103.14 with SMTP id a14mr2704105wxc; Fri, 07 Oct 2005 20:43:35 -0700 (PDT) Received: by 10.70.115.15 with HTTP; Fri, 7 Oct 2005 20:43:35 -0700 (PDT) Message-ID: <84dead720510072043x45a2181ch5eea8cbfe9ea50cb@mail.gmail.com> Date: Sat, 8 Oct 2005 09:13:35 +0530 From: Joseph Koshy To: freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Determining CPU topology on multi-core CPUs X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joseph Koshy List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2005 03:43:40 -0000 On multi-core P4/HTT CPU packages I need to distinguish between physically distinct CPUs in separate cores from HT CPU (a.k.a., 'threads') pairs. What is the best way a driver can obtain the CPU topology of a system? The bits in 'logical_cpus_mask' do not distinguish between multi-core and HT cpus. -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-arch@FreeBSD.ORG Sat Oct 8 08:31:22 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A52E16A41F for ; Sat, 8 Oct 2005 08:31:22 +0000 (GMT) (envelope-from ps@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D58943D45 for ; Sat, 8 Oct 2005 08:31:21 +0000 (GMT) (envelope-from ps@freebsd.org) Received: from [192.168.1.88] (64-142-76-135.dsl.static.sonic.net [64.142.76.135]) by elvis.mu.org (Postfix) with ESMTP id 6D76F1A3C1B; Sat, 8 Oct 2005 01:31:21 -0700 (PDT) Message-ID: <434783D7.4030701@freebsd.org> Date: Sat, 08 Oct 2005 01:31:19 -0700 From: Paul Saab User-Agent: Thunderbird 1.0+ (Macintosh/20050810) MIME-Version: 1.0 To: Joseph Koshy , arch@freebsd.org References: <84dead720510072043x45a2181ch5eea8cbfe9ea50cb@mail.gmail.com> In-Reply-To: <84dead720510072043x45a2181ch5eea8cbfe9ea50cb@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Determining CPU topology on multi-core CPUs X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2005 08:31:22 -0000 you want hyperthreading_cpus_mask Joseph Koshy wrote: > On multi-core P4/HTT CPU packages I need to distinguish between > physically distinct CPUs in separate cores from HT CPU > (a.k.a., 'threads') pairs. > > What is the best way a driver can obtain the CPU topology > of a system? > > The bits in 'logical_cpus_mask' do not distinguish between > multi-core and HT cpus. > > -- > FreeBSD Volunteer, http://people.freebsd.org/~jkoshy > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > From owner-freebsd-arch@FreeBSD.ORG Sat Oct 8 13:39:27 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA02516A41F for ; Sat, 8 Oct 2005 13:39:27 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0666643D49 for ; Sat, 8 Oct 2005 13:39:27 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 9F41546BA6 for ; Sat, 8 Oct 2005 09:39:26 -0400 (EDT) Date: Sat, 8 Oct 2005 14:39:26 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: arch@FreeBSD.org Message-ID: <20051008143854.B84936@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Call for performance evaluation: net.isr.direct (fwd) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2005 13:39:27 -0000 FYI, as this is a general architectural issue. Please follow up to performance@/net@. Thanks, Robert N M Watson ---------- Forwarded message ---------- Date: Wed, 5 Oct 2005 17:12:14 +0100 (BST) From: Robert Watson To: performance@FreeBSD.org Cc: net@FreeBSD.org Subject: Call for performance evaluation: net.isr.direct In 2003, Jonathan Lemon added initial support for direct dispatch of netisr handlers from the calling thread, as part of his DARPA/NAI Labs contract in the DARPA CHATS research program. Over the last two years since then, Sam Leffler and I have worked to refine this implementation, removing a number of ordering related issues, opportunities for excessive parallelism, recursion issues, and testing with a broad range of network components. There has also been a significant effort to complete MPSAFE locking work throughout the network stack. Combined with the earlier move to ithreads and a functional direct dispatch ("process to completion" implementation), there are a number of exciting possible benefits. - Possible parallelism by packet source -- ithreads can dispatch simultaenously into the higher level network stack layers. Since ithreads can execute in parallel on different CPU, so can code they invoke directly. - Elimination of context switches in the network receive path -- rather than context switching to the netisr thread from the ithread, we can now directly execute netisr code from the ithread. - A CPU-bound netisr thread on a multi-processor system will no longer rate limit traffic to the available resources on one CPU. - Eliminating the additional queueing in the handoff reduces the opportunity for queues to overfill as a result of scheduling delays. There are, however, some possible downsides and/or trade-offs: - Higher level network processing will now compete with the interrupt handler for CPU resources available to the ithread. This means less time for the interrupt code to execute in the thread if the thread is CPU-bound. - Lower levels of parallelism between portions of the inbound packet processing path. Without direct dispatch, there is possible parallelism between receive network driver execution and higher level stack layers, whereas with direct dispatch they can no longer execute in parallel. - Re-queued packets from tunnel and encapsulation processing will now require a context switch to process, since they will be processed in the netisr proper rather than in the ithread, whereas before the netisr thread would pick them up immediately after completing the current processing without a context switch. - Code that previously ran in the SWI at a SWI priority now runs in the ithread at an ithread priority, elevating the general priority at which network processing takes place. And there are a few mixed things, that can offer good and bad elements: - Less queueing takes place in the network stack in in-bound processing: packets are taken directly from the driver and processed to completion one by one, rather than queued for batch processing. Packets will be dropped before the link layer, rather than on the boundary between the link and protocol layers. This is good in that we invest less work in packets we were going to drop anyway, but bad in that less queueing means less room for scheduling delays. In previous FreeBSD releases, such as several 5.x series releases, net.isr.enable could not be turned on by default because there was insufficient synchronization in the network stack. As of 5.5 and 6.0, I believe there is sufficient synchronization, especially given that we force non-MPSAFE protocol handlers to run in the netisr without direct dispatch. As such, there has been a gradual conversation going on about making direct dispatch the default behavior in the 7.x development series, and more publically documenting and supporting the use of direct dispatch in the 6.x release engineering series. Obviously, this is about two things: performance, and stability. Many of us have been running with direct dispatch on by default for quite some time, so it passes some of the basic "does it run" tests. However, since it significantly increases the opportunity for parallelism in the receive path of the network stack, it likely will trigger otherwise latent or infrequent races and bugs to occur more frequently. The second aspect is performance: many results suggest that direct dispatch has a significant performance benefit. However, evaluating the impact on a broad range of results is required in order for us to go ahead with what is effectively a significant architectural change in how we perform network stack processing. To give you a sense of some of the performance effect I've measured recently, using the netperf measurement tool (with -DHISTOGRAM removed from the FreeBSD port build), here are some results. In each case, I've put parenthesis around host or router to indicate which is the host where the configuration change is being tested. These tests were performed using dual Xeon systems, and using back-to-back gigabit ethernet cards and the if_em driver: TCP round trip benchmark (TCP_RR), host-(host): 7.x UP: 0.9% performance improvement 7.x SMP: 0.7% performance improvement TCP round trip benchmark (TCP_RR), host-(router)-host: 7.x UP: 2.4% performance improvement 7.x SMP: 2.9% performance improvement UDP round trip benchmark (UDP_RR), host-(host): 7.x UP: 0.7% performance improvement 7.x SMP: 0.6% performance improvement UDP round trip benchmark (UDP_RR), host-(router)-host: 7.x UP: 2.2% performance improvement 7.x SMP: 3.0% performance improvement TCP stream banchmark (TCP_STREAM), host-(host): 7.x UP: 0.8% performance improvement 7.x SMP: 1.8% performance improvement TCP stream benchmark (TCP_STREAM), host-(router)-host: 7.x UP: 13.6% performance improvement 7.x SMP: 15.7% performance improvement UDP stream benchmark (UDP_STREAM), host-(host): 7.x UP: none 7.x SMP: none UDP stream benchmark (UDP_STREAM), host-(router)-host: 7.x UP: none 7.x SMP: none TCP connect benchmark (src/tools/tools/netrate/tcpconnect) 7.x UP: 7.90383% +/- 0.553773% 7.x SMP: 12.2391% +/- 0.500561% So in some cases, the impact is negligible -- in other places, it is quite significant. So far, I've not measured a case where performance has gotten worse, but that's probably because I've only been measuring a limited number of cases, and with a fairly limited scope of configurations, especially given that the hardware I have is pushing the limits of what the wire supports, so minor changes in latency are possible, but not large changes in throughput. So other than a summary of the status quo, this is also a call to action. I would like to get more widespread benchmarking of the impact of direct dispatch on network-related workloads. This means a variety of things: (1) Performance of low level network services, such as routing, bridging, and filtering. (2) Performance of high level application servces, such as web and database. (3) Performance of integrated kernel network services, such as the NFS client and server. (4) Performance of user space distributed file systems, such as Samba and AFS. All you need to do to switch to direct dispatch mode is set the sysctl or tunable "net.isr.dispatch" to 1. To disable it again, remove the setting, or set it to 0. It can be modified at run-time, although during the transition from one mode to the other, there may be a small quantity of packet misordering, so benchmarking over the transition is discouraged. FYI: as of 6.0-RC1 and recent 7.0, net.isr.dispatch is the name of the variable. In earlier releases, the name of this variable was net.isr.enable. Some important details: - Only non-local protocol traffic is affected: loopback traffic still goes via the netisr to avoid issues of recursion and lock order. - In the general case, only in-bound traffic is directly affected by this change. As such, send-only benchmarks may reveal little change. They are still interesting, however. - However, the send path is indirectly affected due to changes in scheduling, workload, interrupt handling, and so on. - Because network benchmarks, especially micro-benchmarks, are especially sensitive to minor perturbations, I highly recommend running in a minimal multi-user or ideally single-user environment, and suggest isolating undesired sources of network traffic from segments where testing is occuring. For macro-benchmarks this can be less important, but should be paid attention to. - Please make sure debugging features are turned off when running tests -- especially WITNESS, INVARIANTS, INVARIANT_SUPPORT, and user space malloc debugging. These can have a significant impact on performance, both potentially overshadowing changes, and in some cases, actually reversing results (due to higher overhead under locks, for example). - Do not use net.isr.enable in the 5.x line unless you know what you are doing. While it is reasonably safe with 5.4 forwards, it is not a supported configuration, and may cause stability issues with specific workloads. - What we're particularly interested in is a statistically meaningful comparison of the "before" and "after" case. When doing measurements, I like to run 10-12 samples, and usually discard the first one or two, depending on the details of the benchmark. I'll then use src/tools/tools/ministat to compare the data sets. Running a number of samples is quite important, because the variance in many tests can be significant, and if the two sample sets overlap, you can quite easily draw the entirely wrong conclusion about the results from a small number of measurements in a sample. Assuming you have a fixed width font, typicaly output from ministat looks something like the following and may be human readable: x 7SMP/tcpconnect_queue + 7SMP/tcpconnect_direct +--------------------------------------------------------------------------+ |x xx + +| |xxxxx xx ++ +++++ +| ||__A__| |___A__| | +--------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 10 5425 5503 5460 5456.3 26.284977 + 10 6074 6169 6126 6124.1 31.606785 Difference at 95.0% confidence 667.8 +/- 27.3121 12.2391% +/- 0.500561% (Student's t, pooled s = 29.0679) Of particular interest is if changing to direct dispatch hurts performance in your environment, and understanding why that is. Thanks, Robert N M Watson _______________________________________________ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Sat Oct 8 18:44:12 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CBE416A41F for ; Sat, 8 Oct 2005 18:44:12 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from pasmtp.tele.dk (pasmtp.tele.dk [193.162.159.95]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33C3E43D46 for ; Sat, 8 Oct 2005 18:44:12 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (0x535c0e2a.sgnxx1.adsl-dhcp.tele.dk [83.92.14.42]) by pasmtp.tele.dk (Postfix) with ESMTP id D05C11EC312 for ; Sat, 8 Oct 2005 20:44:08 +0200 (CEST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.4/8.13.4) with ESMTP id j98HcEJU004150; Sat, 8 Oct 2005 19:38:14 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Craig Rodrigues From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 07 Oct 2005 22:46:20 EDT." <20051008024620.GA29824@crodrigues.org> Date: Sat, 08 Oct 2005 19:36:59 +0200 Message-ID: <4128.1128793019@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-arch@freebsd.org Subject: Re: [RFC] Teaching mount(8) to use nmount() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2005 18:44:12 -0000 In message <20051008024620.GA29824@crodrigues.org>, Craig Rodrigues writes: >Since I don't know how all the existing mount programs work, and I >don't know the dependencies on how UFS mounting works, I propose >an interim behavior for mount: Good plan. >I would appreciate any comments on the attached patch. No obvious bogons spotted. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.