From owner-freebsd-arch Sun Jun 16 3:35:40 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by hub.freebsd.org (Postfix) with ESMTP id C5CF137B425 for ; Sun, 16 Jun 2002 03:35:37 -0700 (PDT) Received: from fwd08.sul.t-online.de by mailout11.sul.t-online.com with smtp id 17JXNd-0001B9-02; Sun, 16 Jun 2002 12:35:33 +0200 Received: from Magelan.Leidinger.net (520065502893-0001@[80.131.112.246]) by fmrl08.sul.t-online.com with esmtp id 17JXNX-08516mC; Sun, 16 Jun 2002 12:35:27 +0200 Received: from Leidinger.net (netchild@localhost [127.0.0.1]) by Magelan.Leidinger.net (8.12.3/8.12.3) with ESMTP id g5GAb76g000610; Sun, 16 Jun 2002 12:37:11 +0200 (CEST) (envelope-from netchild@Leidinger.net) Message-Id: <200206161037.g5GAb76g000610@Magelan.Leidinger.net> Date: Sun, 16 Jun 2002 12:37:07 +0200 (CEST) From: Alexander Leidinger Subject: Re: ACPI Daemon To: scott_long@btc.adaptec.com Cc: arch@FreeBSD.ORG In-Reply-To: <20020616045337.GA38313@hollin.btc.adaptec.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-Sender: 520065502893-0001@t-dialin.net Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 15 Jun, Scott Long wrote: > The daemon would provide the following services: [...] What about executing an user supplied command on specific key issues, e.g. on a specific temperature/battery level, fan speed, ...? Bye, Alexander. -- Where do you think you're going today? http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 16 7:17:38 2002 Delivered-To: freebsd-arch@freebsd.org Received: from cheer.mahoroba.org (flets19-004.kamome.or.jp [218.45.19.4]) by hub.freebsd.org (Postfix) with ESMTP id 67A5237B40A; Sun, 16 Jun 2002 07:17:32 -0700 (PDT) Received: from piano.mahoroba.org (IDENT:FUVs7K6oni7hjGEXeUooOOnA2YqxhnRwnRwUR5lDakwlvb9Hgf1To+AVzhmYLgTQ@piano.mahoroba.org [IPv6:2001:200:301:0:240:96ff:fe48:4ea8]) (user=ume mech=CRAM-MD5 bits=0) by cheer.mahoroba.org (8.12.4/8.12.4) with ESMTP/inet6 id g5GEHRAK003613 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 16 Jun 2002 23:17:28 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sun, 16 Jun 2002 23:17:27 +0900 Message-ID: From: Hajimu UMEMOTO To: arch@FreeBSD.org, hackers@FreeBSD.org Subject: [CFR] max-child-per-ip restriction for inetd User-Agent: Wanderlust/2.9.13 (Unchained Melody) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) X-Operating-System: FreeBSD 4.6-RELEASE MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, I wish to add max-child-per-ip option to inetd. This enables us to restrict maximum number of simultaneous invocations of each service from a single IP address. The proposed patch can be found from: http://www.imasy.or.jp/~ume/FreeBSD/inetd-perip-5c.diff (for 5-CURRENT) http://www.imasy.or.jp/~ume/FreeBSD/inetd-perip-4s.diff (for 4-STABLE) If there is no objection, I'll commit it at next weekend. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 16 7:35:30 2002 Delivered-To: freebsd-arch@freebsd.org Received: from castle.jp.FreeBSD.org (castle.jp.FreeBSD.org [210.226.20.15]) by hub.freebsd.org (Postfix) with ESMTP id 94D2337B407; Sun, 16 Jun 2002 07:35:26 -0700 (PDT) Received: from localhost (localhost [::1]) by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) with ESMTP/inet6 id g5GEZOc53917; Sun, 16 Jun 2002 23:35:24 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) In-Reply-To: References: X-User-Agent: Mew/1.94.2 XEmacs/21.5 (bamboo) X-FaceAnim: (-O_O-)(O_O- )(_O- )(O- )(- -)( -O)( -O_)( -O_O)(-O_O-) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 10 From: Makoto Matsushita To: arch@FreeBSD.org, hackers@FreeBSD.org Subject: Re: [CFR] max-child-per-ip restriction for inetd Date: Sun, 16 Jun 2002 23:35:21 +0900 Message-Id: <20020616233521G.matusita@jp.FreeBSD.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ume> I wish to add max-child-per-ip option to inetd. This enables us to ume> restrict maximum number of simultaneous invocations of each service ume> from a single IP address. FYI: This patch is already tested at snapshots.jp.FreeBSD.org, and it seems fine to me. Thank you, ume-san! -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 16 9:59:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns2.gnf.org (ns2.gnf.org [63.196.132.68]) by hub.freebsd.org (Postfix) with ESMTP id C880C37B404; Sun, 16 Jun 2002 09:59:25 -0700 (PDT) Received: from mail.gnf.org (smtp.gnf.org [172.25.11.11]) by ns2.gnf.org (8.11.6/8.11.6) with ESMTP id g5GGkCO58155; Sun, 16 Jun 2002 09:46:12 -0700 (PDT) (envelope-from gordon@FreeBSD.org) Received: by mail.gnf.org (Postfix, from userid 888) id DDEFE11E515; Sun, 16 Jun 2002 09:59:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.gnf.org (Postfix) with ESMTP id DCD6011A572; Sun, 16 Jun 2002 09:59:21 -0700 (PDT) Date: Sun, 16 Jun 2002 09:59:21 -0700 (PDT) From: Gordon Tetlow X-X-Sender: gordont@smtp.gnf.org To: Doug Barton Cc: Nik Clayton , Brian Somers , Subject: Re: MFC of rcNG? In-Reply-To: <3D0B9246.75D2AA45@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 15 Jun 2002, Doug Barton wrote: > [Moved to -arch, since the cvs-* lists have suffered enough recently.] > > Nik Clayton wrote: > > > > And is this something that can be MFC'd? I realise it's quite a > > fundamental change to the startup system, but if it made it in to 4.7 as > > an alternative (so the default remains the same) it would give people > > the chance to try it out without needing to run -current. It also makes > > it more likely to be covered in the Handbook. . . > > I vigorously oppose making it the default in 4.x at any time... we > already did one major overhaul of /etc/rc* in RELENG_4, and I don't > think we should put them through that again. However, if we can get it > polished sufficiently I wouldn't object necessarily to having it in > there as an option; BUT, I seriously doubt it'd get to that point in > time to be useful. The only MFC candidate I'd like to see is /etc/rc.subr. This would allow the ports collection to use the facilities provided by rcng while not making everything dependent on whether you are using CURRENT or STABLE. Is a version bump a good idea? -gordon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 16 10:38: 3 2002 Delivered-To: freebsd-arch@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id D21E837B40F; Sun, 16 Jun 2002 10:37:50 -0700 (PDT) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.6/8.11.6) id g5GHaSO33687; Sun, 16 Jun 2002 19:36:28 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200206161736.g5GHaSO33687@zibbi.icomtek.csir.co.za> Subject: Re: [CFR] max-child-per-ip restriction for inetd In-Reply-To: from Hajimu UMEMOTO at "Jun 16, 2002 11:17:27 pm" To: ume@mahoroba.org (Hajimu UMEMOTO) Date: Sun, 16 Jun 2002 19:36:28 +0200 (SAT) Cc: arch@FreeBSD.ORG, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Hi, > > I wish to add max-child-per-ip option to inetd. This enables us to > restrict maximum number of simultaneous invocations of each service > from a single IP address. The proposed patch can be found from: > > http://www.imasy.or.jp/~ume/FreeBSD/inetd-perip-5c.diff (for 5-CURRENT) > http://www.imasy.or.jp/~ume/FreeBSD/inetd-perip-4s.diff (for 4-STABLE) Both the patches needs a colon (:) after the s on the getopt() line, otherwise you just get a nasty coredump if you try to use the "-s num" commandline option. John -- John Hay -- John.Hay@icomtek.csir.co.za / jhay@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 16 10:49:43 2002 Delivered-To: freebsd-arch@freebsd.org Received: from cheer.mahoroba.org (flets19-004.kamome.or.jp [218.45.19.4]) by hub.freebsd.org (Postfix) with ESMTP id 67C3437B401; Sun, 16 Jun 2002 10:49:34 -0700 (PDT) Received: from piano.mahoroba.org (IDENT:wH+5/SAOEYYoDSIiUVbeI3L73nh3xvZzPUk1mkVn9VRhRXBlrNGQHrsnPoVF/8PD@piano.mahoroba.org [IPv6:2001:200:301:0:240:96ff:fe48:4ea8]) (user=ume mech=CRAM-MD5 bits=0) by cheer.mahoroba.org (8.12.4/8.12.4) with ESMTP/inet6 id g5GHnTAK062078 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 17 Jun 2002 02:49:29 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Mon, 17 Jun 2002 02:49:29 +0900 Message-ID: From: Hajimu UMEMOTO To: John Hay Cc: arch@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: [CFR] max-child-per-ip restriction for inetd In-Reply-To: <200206161736.g5GHaSO33687@zibbi.icomtek.csir.co.za> References: <200206161736.g5GHaSO33687@zibbi.icomtek.csir.co.za> User-Agent: xcite1.38> Wanderlust/2.9.13 (Unchained Melody) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) X-Operating-System: FreeBSD 4.6-RELEASE MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, >>>>> On Sun, 16 Jun 2002 19:36:28 +0200 (SAT) >>>>> John Hay said: jhay> Both the patches needs a colon (:) after the s on the getopt() line, jhay> otherwise you just get a nasty coredump if you try to use the "-s num" jhay> commandline option. Oops, thanks. I just fix it and re-put it. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 16 11: 1:53 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay1.yahoo.com (mail-relay1.yahoo.com [216.145.48.34]) by hub.freebsd.org (Postfix) with ESMTP id 0531C37B400; Sun, 16 Jun 2002 11:01:48 -0700 (PDT) Received: from FreeBSD.org (12-234-90-219.client.attbi.com [12.234.90.219]) by mail-relay1.yahoo.com (Postfix) with ESMTP id 183178B5C0; Sun, 16 Jun 2002 11:01:44 -0700 (PDT) Message-ID: <3D0CD287.CC5CAEB8@FreeBSD.org> Date: Sun, 16 Jun 2002 11:01:43 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.79 [en] (X11; U; FreeBSD 4.5-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gordon Tetlow Cc: Nik Clayton , Brian Somers , arch@FreeBSD.org Subject: Re: MFC of rcNG? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Gordon Tetlow wrote: > > On Sat, 15 Jun 2002, Doug Barton wrote: > > > [Moved to -arch, since the cvs-* lists have suffered enough recently.] > > > > Nik Clayton wrote: > > > > > > And is this something that can be MFC'd? I realise it's quite a > > > fundamental change to the startup system, but if it made it in to 4.7 as > > > an alternative (so the default remains the same) it would give people > > > the chance to try it out without needing to run -current. It also makes > > > it more likely to be covered in the Handbook. . . > > > > I vigorously oppose making it the default in 4.x at any time... we > > already did one major overhaul of /etc/rc* in RELENG_4, and I don't > > think we should put them through that again. However, if we can get it > > polished sufficiently I wouldn't object necessarily to having it in > > there as an option; BUT, I seriously doubt it'd get to that point in > > time to be useful. > > The only MFC candidate I'd like to see is /etc/rc.subr. This would allow > the ports collection to use the facilities provided by rcng while not > making everything dependent on whether you are using CURRENT or STABLE. Agreed on that point, we'll blow up the rest of the bridges when we get to them. > Is a version bump a good idea? Version of what? -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 16 13:40:15 2002 Delivered-To: freebsd-arch@freebsd.org Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by hub.freebsd.org (Postfix) with ESMTP id 67AE937B425; Sun, 16 Jun 2002 13:40:10 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc03.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020616204009.WQFO20219.sccrmhc03.attbi.com@InterJet.elischer.org>; Sun, 16 Jun 2002 20:40:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA10855; Sun, 16 Jun 2002 13:24:48 -0700 (PDT) Date: Sun, 16 Jun 2002 13:24:46 -0700 (PDT) From: Julian Elischer To: Gordon Tetlow Cc: Doug Barton , Nik Clayton , Brian Somers , arch@FreeBSD.org Subject: 4.x compatibilty.. Was: MFC of rcNG? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 16 Jun 2002, Gordon Tetlow wrote: > On Sat, 15 Jun 2002, Doug Barton wrote: > > > [Moved to -arch, since the cvs-* lists have suffered enough recently.] > > > > The only MFC candidate I'd like to see is /etc/rc.subr. This would allow > the ports collection to use the facilities provided by rcng while not > making everything dependent on whether you are using CURRENT or STABLE. > The reason for having 4.x branch is for 'backwards compaitible' changes to be made available to users of 4.x FreeBSD. The only features fo rcNG that can be MFC'd are those that are pure additions. For example I know companies that have changes that rely very heavily on the current rc layout. These are national and international banks so please do NOT break this if you want to be able to get jobs at these places as FreeBSD admins, or even use them as FreeBSD references, because the reason they use BSD is stability. If we start pissing them off they might as well go elsewhere. As of this writing, They are (some have) transitioning from 4.1.1+SAs to 4.4p13. they will continue to sit on 4.4pxx until about June to October 2003 when they will transition to 4.8 (at least this is the plan they have indicated at this time (they don't like upgrading more than once every two years because they need to do a complete system retest before thay will accept a new release from us)). Some were so happy with 4.1.1 that they have hung back there longer than anticipated.. The plan I am suggesting to them at the moment is to migrate to 5.4 or later in about 2005. By then hopefully the need for the SNA cards we have in them at the moment with proprietary drivers (binary only) will have subsided so we won't need to get those drivers rewritten for us... (So binary compatibility from 4.1.1 to 4.8 is a big deal for us for drivers.. including mbuf layout,, ISA interface, ifnet layout etc.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 16 13:50:54 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay1.yahoo.com (mail-relay1.yahoo.com [216.145.48.34]) by hub.freebsd.org (Postfix) with ESMTP id 5CA9937B407; Sun, 16 Jun 2002 13:50:50 -0700 (PDT) Received: from FreeBSD.org (12-234-90-219.client.attbi.com [12.234.90.219]) by mail-relay1.yahoo.com (Postfix) with ESMTP id CAB5B8B5D6; Sun, 16 Jun 2002 13:50:49 -0700 (PDT) Message-ID: <3D0CFA29.C680120F@FreeBSD.org> Date: Sun, 16 Jun 2002 13:50:49 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.79 [en] (X11; U; FreeBSD 4.5-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Gordon Tetlow , Nik Clayton , Brian Somers , arch@FreeBSD.org Subject: Re: 4.x compatibilty.. Was: MFC of rcNG? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer wrote: > > On Sun, 16 Jun 2002, Gordon Tetlow wrote: > > > On Sat, 15 Jun 2002, Doug Barton wrote: > > > > > [Moved to -arch, since the cvs-* lists have suffered enough recently.] > > > > > > > The only MFC candidate I'd like to see is /etc/rc.subr. This would allow > > the ports collection to use the facilities provided by rcng while not > > making everything dependent on whether you are using CURRENT or STABLE. > > > > The reason for having 4.x branch is for 'backwards compaitible' changes > to be made available to users of 4.x FreeBSD. > > The only features fo rcNG that can be MFC'd are those that are pure > additions. Agreed. The current way that the stuff is layed out is that there is a knob in rc.conf that basically means, "Use the old stuff, or use the new stuff." Anything that is mfc'ed will still depend on that knob. The reason for mfc'ing /etc/rc.subr (which just sits there harmlessly until you use it explicitly) is so that ports authors CAN (note, not MUST) modify their startup scripts to take advantage of it. I'm very sensitive to the need to keep RELENG_4 non-POLA-wanking, so you can rest easy, at least as far as /etc stuff goes. Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 16 14:40:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: from nothing-going-on.demon.co.uk (pc-62-31-42-140-hy.blueyonder.co.uk [62.31.42.140]) by hub.freebsd.org (Postfix) with ESMTP id DE05837B423; Sun, 16 Jun 2002 14:39:55 -0700 (PDT) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.11.3/8.11.3) id g5GLeHa53451; Sun, 16 Jun 2002 22:40:17 +0100 (BST) (envelope-from nik) Date: Sun, 16 Jun 2002 22:40:17 +0100 From: Nik Clayton To: Julian Elischer Cc: Gordon Tetlow , Doug Barton , Nik Clayton , Brian Somers , arch@FreeBSD.org Subject: Re: 4.x compatibilty.. Was: MFC of rcNG? Message-ID: <20020616224017.A52976@canyon.nothing-going-on.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from julian@elischer.org on Sun, Jun 16, 2002 at 01:24:46PM -0700 Organization: FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Julian, On Sun, Jun 16, 2002 at 01:24:46PM -0700, Julian Elischer wrote: > The reason for having 4.x branch is for 'backwards compaitible' changes > to be made available to users of 4.x FreeBSD. >=20 > The only features fo rcNG that can be MFC'd are those that are pure > additions.=20 Not to pick on you specifically, but have people forgotten how to read? In my original message I explicitly said: I realise it's quite a fundamental change to the startup system, but if it made it in to 4.7 as an alternative (so the default remains the same) . . . In other words, all these people with mission critical systems running stable see zero change. It would only be those of who did the equivalent of rcng_enable=3D"YES" (or whatever the variable is) that would get the new functionality. Giving us the chance to try it out, and test it in production environments, without needing to learn another way of doing things as part of the 'cut over to 5.x' process. Hmm. When is the existing /etc/rc* system going to be officially deprecated? Has anyone thought about that? At the moment it sounds like 5.x is going to ship with the new system, and without the old one. Shouldn't we be doing something like? 4.7 -- Announce the new system, with the old system as default 5.0 -- Use the new system as default, keep the old system 6.0 -- Remove the old system I'm sure we can bike shed the version numbers at which these events happen. N --=20 FreeBSD: The Power to Serve http://www.freebsd.org/ (__) FreeBSD Documentation Project http://www.freebsd.org/docproj/ \\\'',) \/ \= ^ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- .\._/= _) --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9DQXBk6gHZCw343URAmHeAJ9IGW5r+gbmePd1R62/o0frxUmeBgCgk5My XvE8KHebKF/MljOKQbElJ6M= =rwPm -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 16 15: 8:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay1.yahoo.com (mail-relay1.yahoo.com [216.145.48.34]) by hub.freebsd.org (Postfix) with ESMTP id 9DBCD37B403; Sun, 16 Jun 2002 15:08:10 -0700 (PDT) Received: from FreeBSD.org (12-234-90-219.client.attbi.com [12.234.90.219]) by mail-relay1.yahoo.com (Postfix) with ESMTP id 5B2228B5C7; Sun, 16 Jun 2002 15:08:10 -0700 (PDT) Message-ID: <3D0D0C4A.2B1B3102@FreeBSD.org> Date: Sun, 16 Jun 2002 15:08:10 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.79 [en] (X11; U; FreeBSD 4.5-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nik Clayton Cc: Julian Elischer , Gordon Tetlow , Brian Somers , arch@freebsd.org Subject: rcNG rollout in -current References: <20020616224017.A52976@canyon.nothing-going-on.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nik Clayton wrote: > Hmm. When is the existing /etc/rc* system going to be officially > deprecated? Has anyone thought about that? At the moment it sounds > like 5.x is going to ship with the new system, and without the old one. Yes, the reasoning is that since the goal is to have the new stuff doing exactly what the old stuff does, there's no reason not to just get it over with. Our current goal is the following: By DP2: Make rc_ng="YES" the default By 5.0-RELEASE: Complete cutover Our feeling is that the leap to 5.0 will already have a sufficiently large number of things to worry about that adding one more shouldn't be a problem. :) Or at least, this problem should be lost in the noise since rc.conf[.local] won't be any more incompatible due to the rcng stuff than it would have been in -current anyway. Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 16 15:47:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id D5C8037B405 for ; Sun, 16 Jun 2002 15:47:19 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g5GMk8Y29481 for ; Sun, 16 Jun 2002 16:46:08 -0600 (MDT) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g5GMk7G64631 for ; Sun, 16 Jun 2002 16:46:07 -0600 (MDT) (envelope-from imp@village.org) Date: Sun, 16 Jun 2002 16:44:37 -0600 (MDT) Message-Id: <20020616.164437.20405847.imp@village.org> To: arch@freebsd.org Subject: foo_if.m -> standard in files? From: "M. Warner Losh" X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I'd love to make foo_if.m files in the tree standard, to the extent that it is possible. I've been running with this in my tree for months and months. So far only the sound files pose any kind of problem at all, and even that might have been fixed in the last 9 months that I've been doing this. I've just included the interface glue, but nothing else, so the cost is relatively small. This makes loadable drivers much easier. For example, if you wanted to kldload if_ep.ko, but didn't have any pccard in your tree it would fail due to the 'card' interface not being available. Making if_ep.ko (and all drivers that have pccard attachments) dependent on pccard isn't quite the right thing to do, since you don't want to load that driver also load pccard code that isn't used at all in the system just to satisfy the interface requirements. The cost: About 1.5k bytes. This seems quite insignificant to the convenience that it buys. Comments? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 16 15:54:52 2002 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 4A49737B436; Sun, 16 Jun 2002 15:54:48 -0700 (PDT) Received: from pool0202.cvx40-bradley.dialup.earthlink.net ([216.244.42.202] helo=mindspring.com) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17JisT-0000mp-00; Sun, 16 Jun 2002 15:52:09 -0700 Message-ID: <3D0D1673.632F2386@mindspring.com> Date: Sun, 16 Jun 2002 15:51:31 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Hajimu UMEMOTO Cc: arch@FreeBSD.org, hackers@FreeBSD.org Subject: Re: [CFR] max-child-per-ip restriction for inetd References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hajimu UMEMOTO wrote: > I wish to add max-child-per-ip option to inetd. This enables us to > restrict maximum number of simultaneous invocations of each service > from a single IP address. The proposed patch can be found from: > > http://www.imasy.or.jp/~ume/FreeBSD/inetd-perip-5c.diff (for 5-CURRENT) > http://www.imasy.or.jp/~ume/FreeBSD/inetd-perip-4s.diff (for 4-STABLE) > > If there is no objection, I'll commit it at next weekend. Your search_ip() function is a linear list traversal, which makes a lookup O(N). Is there any change you could use a hash or a btree or a skiplist or a trie or some other data structure *other* than a linear list traversal? It seems to me that this will make things incredibly slow for everyone, if you have one IP address that's abusive enough that it approaches the limit you set. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 16 22:36:48 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (dhcp45-24.dis.org [216.240.45.24]) by hub.freebsd.org (Postfix) with ESMTP id BFD1E37B406; Sun, 16 Jun 2002 22:36:44 -0700 (PDT) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.12.3/8.12.3) with ESMTP id g5EMcQhv000828; Fri, 14 Jun 2002 15:38:27 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200206142238.g5EMcQhv000828@mass.dis.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Terry Lambert Cc: Giorgos Keramidas , Mario Sergio Fujikawa Ferreira , Garance A Drosihn , FreeBSD-arch@FreeBSD.org, msmith@FreeBSD.org Subject: Re: Adding SO_NOSIGPIPE to -STABLE/-CURRENT In-reply-to: Your message of "Fri, 14 Jun 2002 15:10:38 PDT." <3D0A69DE.F2214A69@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Jun 2002 15:38:26 -0700 From: Michael Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > This SO_SIGPIPE discussion seems bent on trying to make the signal > facility more able than it is, when in fact signals were (and are) > a bad idea in the first place. Actually, this has nothing to do with it. The issue revolves around the seperation of resource ownership between a program and the frameworks that it links with. In many cases, the program has no idea that the framework has a pipe/socket open, and is thus surprised by the signal. In other cases, it will install its own handler and be confused. > Why are you getting SIGPIPE in the first place, rather than > some other indicator? Isn't it because you are using the wrong > system call to send data down a socket? No, it's because the socket's closed and the signal mask is process-wide. > If you are going to provide this facility, at *least* make it > general, and not socket specific. Make it an fcntl, not a > setsockopt. There aren't any file option bits left. And when was the last time you got SIGPIPE from a file being closed? Sorry Terry, this one's already been solved. The single issue here is whether FreeBSD actually wants to take something back from Darwin, or whether you're all just too stubborn and stuck up yourselves to take what is, in reality, a trivial and entirely worthwhile change. So much for "are Apple going to give anything back"? Try "is FreeBSD too arrogant to accept anything from Apple"? = Mike -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 16 23: 9: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 0C8B537B403; Sun, 16 Jun 2002 23:08:52 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id CB736AE03F; Sun, 16 Jun 2002 23:08:51 -0700 (PDT) Date: Sun, 16 Jun 2002 23:08:51 -0700 From: Alfred Perlstein To: Michael Smith Cc: Terry Lambert , Giorgos Keramidas , Mario Sergio Fujikawa Ferreira , Garance A Drosihn , FreeBSD-arch@FreeBSD.org, msmith@FreeBSD.org Subject: Re: Adding SO_NOSIGPIPE to -STABLE/-CURRENT Message-ID: <20020617060851.GE67925@elvis.mu.org> References: <3D0A69DE.F2214A69@mindspring.com> <200206142238.g5EMcQhv000828@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200206142238.g5EMcQhv000828@mass.dis.org> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Michael Smith [020616 22:37] wrote: > > There aren't any file option bits left. > > And when was the last time you got SIGPIPE from a file being closed? > > Sorry Terry, this one's already been solved. The single issue here is > whether FreeBSD actually wants to take something back from Darwin, or > whether you're all just too stubborn and stuck up yourselves to take > what is, in reality, a trivial and entirely worthwhile change. > > So much for "are Apple going to give anything back"? Try "is FreeBSD too > arrogant to accept anything from Apple"? Whoa, whoa whoa.... :) Since when does Terry have any input as to what the project is doing and where it is going? Mike, if you haven't removed yourself from avail, then commit it yourself under SO_whatever, otherwise point me at a handy delta and I'll do it. If it's just an idea and not in delta form then I can take a crack at it. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 17 0:33:12 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 1745337B403; Mon, 17 Jun 2002 00:33:08 -0700 (PDT) Received: from pool0032.cvx21-bradley.dialup.earthlink.net ([209.179.192.32] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17Jr05-0003Vb-00; Mon, 17 Jun 2002 00:32:34 -0700 Message-ID: <3D0D904D.4752ADD4@mindspring.com> Date: Mon, 17 Jun 2002 00:31:25 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Smith Cc: Giorgos Keramidas , Mario Sergio Fujikawa Ferreira , Garance A Drosihn , FreeBSD-arch@FreeBSD.org, msmith@FreeBSD.org Subject: Re: Adding SO_NOSIGPIPE to -STABLE/-CURRENT References: <200206142238.g5EMcQhv000828@mass.dis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Michael Smith wrote: > > This SO_SIGPIPE discussion seems bent on trying to make the signal > > facility more able than it is, when in fact signals were (and are) > > a bad idea in the first place. > > Actually, this has nothing to do with it. > > The issue revolves around the seperation of resource ownership between a > program and the frameworks that it links with. In many cases, the > program has no idea that the framework has a pipe/socket open, and is > thus surprised by the signal. In other cases, it will install its own > handler and be confused. Shouldn't the framework install its own handler? And then, since the old handler is returned in the set call, it should daisy-chain call the signal handlers, until the default handler, and not call that one, if other handler are installed. Basically, if I have an encapsulation framework, I pretty much expect it to encapsulate. The problem with SIGPIPE is the same as the problem with SIGCHLD; it's not really a notification on a descriptor, and if you have a set of descriptors that might have it on them, then you have to poll them. This is one of the reasons it doesn't make sense. You'd have to be very careful to track which ones had it enabled and disabled, so that you only polled the ones with it enabled, when you saw it; even so, you'd have to poll them all, since, like SIGCHLD, getting the signal doesn't mean that there's only one even that caused the signal to be raised. The whole thing is really predicated on either the signals being queued for delivery (e.g. per POSIX RT signal queueing and Linux these days), or otherwise being able to treat signals as if they were real events, rather than just persistant conditions. If you don't assume queueing (FreeBSD doesn't support it, unless you capture the signals via kqueue()), then a signal isn't really an event, and there's really no correspondance with the fd for the socket for which the signal was raised in th first place. It's probably beeter to resolve whatever problem with something other than signals. > > Why are you getting SIGPIPE in the first place, rather than > > some other indicator? Isn't it because you are using the wrong > > system call to send data down a socket? > > No, it's because the socket's closed and the signal mask is process-wide. The only place I see this happening in the write path is in non-AF_INET sockets. It looks like the psignal(SIGPIPE) only ever happens if underlying code returns EPIPE, which none of the code in /sys/net or /sys/netinet does (there is one ECONNRESET in tcp_usrreq.c that is commented with an "/* XXX EPIPE> */"). I see the sosend case, but is the generic version of the routine used in any of the "struct pr_usrreqs" for anything other than real pipes (i.e. uipc_usrreqs declaration in uipc_usrreq.c)? > > If you are going to provide this facility, at *least* make it > > general, and not socket specific. Make it an fcntl, not a > > setsockopt. > > There aren't any file option bits left. > > And when was the last time you got SIGPIPE from a file being closed? Mostly, I get "EPIPE" being set in errno on write returning -1, and that's for command line things where I've actually used pipes when building the command. > Sorry Terry, this one's already been solved. The single issue here is > whether FreeBSD actually wants to take something back from Darwin, or > whether you're all just too stubborn and stuck up yourselves to take > what is, in reality, a trivial and entirely worthwhile change. I'm all for taking stuff back from Darwin; I'd desperately like FreeBSD to take Darwin's UDF implementation, for example, but the lack of block devices makes that one impossible. 8-(. > So much for "are Apple going to give anything back"? Try "is FreeBSD too > arrogant to accept anything from Apple"? I don't think this is representative of a declaration of war on "all things Apple". I guess I missed some of the side discussions you guys had at the recent Usenix conference. My base assumption, which could be wrong, is that no one would design new code to rely on signals if they didn't have to, so the reason for this was to support porting code from a system that supported the option to FreeBSD. My question was really pointed at "Is this the only way that supporting the porting of this code could be safely handled?". If this is just a feature to have because Linux has it, then it's a no-brainer (IMO) to say "no", unless someone is using it, then the answer should be "yes", for ABI compatability. If there's an application software reason to have it, though, then the answer *should* be "yes, for API compatability"... because it's exactly the same argument I've made in the past in favor of cloning devices being supported in FreeBSD, even if no one can come up with a problem that absolutely can't be solved without them. I guess I'm wondering what software FreeBSD will be able to run/problems will FreeBSD be able to solve, with this option present, that it couldn't without the option present? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 17 0:38:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 5BE7537B408; Mon, 17 Jun 2002 00:38:23 -0700 (PDT) Received: from pool0032.cvx21-bradley.dialup.earthlink.net ([209.179.192.32] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17Jr5b-0006Ut-00; Mon, 17 Jun 2002 00:38:16 -0700 Message-ID: <3D0D91C1.66436705@mindspring.com> Date: Mon, 17 Jun 2002 00:37:37 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: Michael Smith , Giorgos Keramidas , Mario Sergio Fujikawa Ferreira , Garance A Drosihn , FreeBSD-arch@FreeBSD.org, msmith@FreeBSD.org Subject: Re: Adding SO_NOSIGPIPE to -STABLE/-CURRENT References: <3D0A69DE.F2214A69@mindspring.com> <200206142238.g5EMcQhv000828@mass.dis.org> <20020617060851.GE67925@elvis.mu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > Whoa, whoa whoa.... :) > > Since when does Terry have any input as to what the project is > doing and where it is going? Ditto. If I were Project Dictator, then the next generation threads would be implemented with an async call gate, not scheduler activations. Instead, it uses activations to avoid changing the ABI, even though the current plan is to add a new call gate in 5.x for the 64 bit switchover, which is exactly the sort of ABI change that the use of scheduler activations was trying to avoid. IMO, if it's a new call gate, it may as well be async... and magically solve a lot of the hard problems that activations introduced. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 17 0:50:59 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (dhcp45-24.dis.org [216.240.45.24]) by hub.freebsd.org (Postfix) with ESMTP id C591937B412; Mon, 17 Jun 2002 00:50:47 -0700 (PDT) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.12.3/8.12.3) with ESMTP id g5H7l3uJ001188; Mon, 17 Jun 2002 00:47:03 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200206170747.g5H7l3uJ001188@mass.dis.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Terry Lambert Cc: Giorgos Keramidas , Mario Sergio Fujikawa Ferreira , Garance A Drosihn , FreeBSD-arch@freebsd.org, msmith@freebsd.org Subject: Re: Adding SO_NOSIGPIPE to -STABLE/-CURRENT In-reply-to: Your message of "Mon, 17 Jun 2002 00:31:25 PDT." <3D0D904D.4752ADD4@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Jun 2002 00:47:03 -0700 From: Michael Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Michael Smith wrote: > > > This SO_SIGPIPE discussion seems bent on trying to make the signal > > > facility more able than it is, when in fact signals were (and are) > > > a bad idea in the first place. > > > > Actually, this has nothing to do with it. > > > > The issue revolves around the seperation of resource ownership between a > > program and the frameworks that it links with. In many cases, the > > program has no idea that the framework has a pipe/socket open, and is > > thus surprised by the signal. In other cases, it will install its own > > handler and be confused. > > Shouldn't the framework install its own handler? How? > And then, since the old handler is returned in the set call, it > should daisy-chain call the signal handlers, until the default > handler, and not call that one, if other handler are installed. Oh, please. There's no convention for vector chaining for signal handlers; I cannot possibly imagine that you're so naive that you can't immediately see where this scheme falls down. > Basically, if I have an encapsulation framework, I pretty much > expect it to encapsulate. This isn't an encapsulation anything. It's just a library. And you clearly don't grasp the simple nature of either the problem or the solution. > I'm all for taking stuff back from Darwin; I'd desperately like > FreeBSD to take Darwin's UDF implementation, for example, but > the lack of block devices makes that one impossible. 8-(. That has entirely nothing do with it. > I guess I'm wondering what software FreeBSD will be able to > run/problems will FreeBSD be able to solve, with this option > present, that it couldn't without the option present? Have a library open a socket. Have the socket be closed by the remote end without the application linked with the library not receive a "surprise" SIGPIPE. That's it. = Mike -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 17 0:51:53 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (dhcp45-24.dis.org [216.240.45.24]) by hub.freebsd.org (Postfix) with ESMTP id 7821337B404; Mon, 17 Jun 2002 00:51:46 -0700 (PDT) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.12.3/8.12.3) with ESMTP id g5H7nJuJ001203; Mon, 17 Jun 2002 00:49:19 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200206170749.g5H7nJuJ001203@mass.dis.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Alfred Perlstein Cc: Terry Lambert , Giorgos Keramidas , Mario Sergio Fujikawa Ferreira , Garance A Drosihn , FreeBSD-arch@FreeBSD.org, msmith@FreeBSD.org Subject: Re: Adding SO_NOSIGPIPE to -STABLE/-CURRENT In-reply-to: Your message of "Sun, 16 Jun 2002 23:08:51 PDT." <20020617060851.GE67925@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Jun 2002 00:49:19 -0700 From: Michael Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Mike, if you haven't removed yourself from avail, then commit > it yourself under SO_whatever, otherwise point me at a handy > delta and I'll do it. If it's just an idea and not in delta > form then I can take a crack at it. Mario already has the diffs, and if they'd been committed last year when I asked them to be, none of this would be an issue. 8( = Mike -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 17 1:13:28 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id D5BF437B405; Mon, 17 Jun 2002 01:13:20 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id 86F16AE03F; Mon, 17 Jun 2002 01:13:20 -0700 (PDT) Date: Mon, 17 Jun 2002 01:13:20 -0700 From: Alfred Perlstein To: Michael Smith Cc: Terry Lambert , Giorgos Keramidas , Mario Sergio Fujikawa Ferreira , Garance A Drosihn , FreeBSD-arch@freebsd.org, msmith@freebsd.org Subject: Re: Adding SO_NOSIGPIPE to -STABLE/-CURRENT Message-ID: <20020617081320.GG67925@elvis.mu.org> References: <3D0D904D.4752ADD4@mindspring.com> <200206170747.g5H7l3uJ001188@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200206170747.g5H7l3uJ001188@mass.dis.org> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Michael Smith [020617 00:51] wrote: **snip*** Mike, what are you doing??? you should know better by now... Doesn't the fact that Terry just decided to respond to my post about SO_NOSIGPIPE (or whatever it's called) with another tirade about async call gates pretty much make it ABSOFUCKINGLUTLY OBVIOUS that he's trolling you, me and the rest of the entire project? Do us all a favor and don't let his trolling wear you down. In the future just use one of the following "get out a terry thread free" cards below. .------.------.------.------.------. | d | d | d | d | d < `------`------`------`------`------' ^ tear here -----------------/ then paste into mailer, relief should be immediate. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 17 1:21:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id 5688137B40C; Mon, 17 Jun 2002 01:21:46 -0700 (PDT) Received: from pool0032.cvx21-bradley.dialup.earthlink.net ([209.179.192.32] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17Jrld-0004He-00; Mon, 17 Jun 2002 01:21:41 -0700 Message-ID: <3D0D9BEE.BB8AE571@mindspring.com> Date: Mon, 17 Jun 2002 01:21:02 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Smith Cc: Giorgos Keramidas , Mario Sergio Fujikawa Ferreira , Garance A Drosihn , FreeBSD-arch@freebsd.org, msmith@freebsd.org Subject: Re: Adding SO_NOSIGPIPE to -STABLE/-CURRENT References: <200206170747.g5H7l3uJ001188@mass.dis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Michael Smith wrote: > > Shouldn't the framework install its own handler? > > How? Before the call, removing it after the call (worst case) or chaining it (best case). > Oh, please. There's no convention for vector chaining for signal > handlers; I cannot possibly imagine that you're so naive that you can't > immediately see where this scheme falls down. The use of the signals interface in the first place? 8-). Order of operation of setting of handlers becomes important; it's barely manageable to allow replacement of a handler by replacing a function called by the handler function, instead, and only ever installing -- never uninstalling -- the handler. Signals are not really appropriate for transparent use in libraries anyway. It's like making system calls directly via "syscall(2)" in threaded programs. I think that you have to be prepared to do a lot of work if you insist on using an interface in the wrong context. > > Basically, if I have an encapsulation framework, I pretty much > > expect it to encapsulate. > > This isn't an encapsulation anything. It's just a library. And you > clearly don't grasp the simple nature of either the problem or the > solution. The phrase "seperation of resource ownership" implied encapsulation for me; sorry for taking it that way, if that's not the way it was intended. > > I guess I'm wondering what software FreeBSD will be able to > > run/problems will FreeBSD be able to solve, with this option > > present, that it couldn't without the option present? > > Have a library open a socket. Have the socket be closed by the remote > end without the application linked with the library not receive a > "surprise" SIGPIPE. > > That's it. The SIGPIPE should only occur in the case of a bogus "write", correct? In that case, the library should check the writability before attempting to write, shouldn't it? Or install a SIGPIPE handler around the call? Or just mask it completely, once, at library startup (.ctors), and document it as a side effect? I can see the rationale of wanting to save the two extra system calls in the case that the library attempts writes without really caring if the socket still exists at the time of the attempt. I guess I'm still wondering what library expects the OS to have this feature. It seems like it's a really new feature, and that sofware that really depends on it doesn't exist yet. What protocol is this for, since TCP returns ECONNRESET, not EPIPE, anyway? Thanks, -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 17 2: 5:57 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by hub.freebsd.org (Postfix) with ESMTP id E8E3137B411; Mon, 17 Jun 2002 02:05:51 -0700 (PDT) Received: from kokeb.ambesa.net ([64.173.11.16]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GXU00IW1ELR9U@mta6.snfc21.pbi.net>; Mon, 17 Jun 2002 02:05:51 -0700 (PDT) Received: from kokeb.ambesa.net (tanstaafl@localhost [127.0.0.1]) by kokeb.ambesa.net (8.12.3/8.12.3) with ESMTP id g5H9B6Ma004554; Mon, 17 Jun 2002 02:11:06 -0700 (PDT envelope-from mikem@kokeb.ambesa.net) Received: (from mikem@localhost) by kokeb.ambesa.net (8.12.3/8.12.3/Submit) id g5H9B6QW004553; Mon, 17 Jun 2002 02:11:06 -0700 (PDT envelope-from mikem) Date: Mon, 17 Jun 2002 02:11:06 -0700 From: Mike Makonnen Subject: Re: rcNG rollout in -current In-reply-to: <3D0D0C4A.2B1B3102@FreeBSD.org> To: Doug Barton Cc: nik@FreeBSD.ORG, julian@elischer.org, gordon@FreeBSD.ORG, brian@Awfulhak.org, arch@FreeBSD.ORG Message-id: <20020617021106.7aa4ef86.makonnen@pacbell.net> MIME-version: 1.0 X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i386--freebsd5.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <20020616224017.A52976@canyon.nothing-going-on.org> <3D0D0C4A.2B1B3102@FreeBSD.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 16 Jun 2002 15:08:10 -0700 Doug Barton wrote: > Nik Clayton wrote: > > > Hmm. When is the existing /etc/rc* system going to be officially > > deprecated? Has anyone thought about that? At the moment it sounds > > like 5.x is going to ship with the new system, and without the old one. > > Yes, the reasoning is that since the goal is to have the new stuff doing > exactly what the old stuff does, there's no reason not to just get it > over with. Yes, this is why I've been dissapointed with the dearth of testers. I've tried to set it up so that when you switch on rcng, nothing will break. For that we need lots of testers (especially those that are opposed to rcng) so they can tell us if switching it on breaks something. There are a few compatibility knobs in rc.conf (like named_rcng) and scripts ( like /etc/rc.d/{othermta, local}) so that people can change over painlessly. The plan is to leave these compatibility knobs and scripts in 5.0, and mark the current knobs they're designed to work around as deprecated. That should give people enough time to fix local installations before they are removed in 6.0. Cheers, Mike Makonnen. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 17 2: 8:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id CE85937B42F; Mon, 17 Jun 2002 02:08:18 -0700 (PDT) Received: from pool0032.cvx21-bradley.dialup.earthlink.net ([209.179.192.32] helo=mindspring.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17JsUc-0001Qm-00; Mon, 17 Jun 2002 02:08:11 -0700 Message-ID: <3D0DA6D2.39A8C06F@mindspring.com> Date: Mon, 17 Jun 2002 02:07:30 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: Michael Smith , Giorgos Keramidas , Mario Sergio Fujikawa Ferreira , Garance A Drosihn , FreeBSD-arch@freebsd.org, msmith@freebsd.org Subject: Re: Adding SO_NOSIGPIPE to -STABLE/-CURRENT References: <3D0D904D.4752ADD4@mindspring.com> <200206170747.g5H7l3uJ001188@mass.dis.org> <20020617081320.GG67925@elvis.mu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Alfred Perlstein wrote: [ ... ] Excuse me. Are you in the same discussion I'm in? Please *read* Mario's patch; specifically: --- sys/kern/sys_generic.c.orig Mon Feb 25 19:22:18 2002 +++ sys/kern/sys_generic.c Mon Feb 25 19:22:55 2002 @@ -409,7 +409,8 @@ if (auio.uio_resid != cnt && (error == ERESTART || error == EINTR || error == EWOULDBLOCK)) error = 0; - if (error == EPIPE) + /* The socket layer handles SIGPIPE */ + if (error == EPIPE && fp->f_type != DTYPE_SOCKET) psignal(p, SIGPIPE); } cnt -= auio.uio_resid; Turns off *all* socket-related SIGPIPE as a result of write(2) and writev(2). The other part of the patch: --- sys/kern/uipc_syscalls.c.orig Mon Feb 25 19:59:54 2002 +++ sys/kern/uipc_syscalls.c Mon Feb 25 20:01:48 2002 @@ -586,7 +586,8 @@ if (auio.uio_resid != len && (error == ERESTART || error == EINTR || error == EWOULDBLOCK)) error = 0; - if (error == EPIPE) + /* Generation of SIGPIPE can be controlled per socket */ + if (error == EPIPE && !(so->so_options & SO_NOSIGPIPE)) psignal(p, SIGPIPE); } if (error == 0) Is *only* effective in the send(2), sendto(2), and sendmsg(2) cases. In other words, it turns the SIGPIPE off in a code path, makes it switchable in a second code path, and thereafter provides no mechanism whereby the SISGPIPE may be turned back on in the first code path. The /socket/ is not available in the write path, the /descriptor/ is; to convert it from a /descriptor/ to a /socket/, you would have to do a lot of tests and dereferencing (nominally OK, since it's an already expensive error path, but hard to do without dragging in most of the socket headers into kern/sys_generic.c). Therefore, my *initial* post in this thread suggested that, if it be done at all, it be done as a /descriptor/ option, via fcntl, rather than as a /socket/ option, via setsockopt(). I was not aware that people has used up all the available fcntl() commands. Unless you fix the CLEVERLY HIDDEN BREAKAGE it introduces in dofilewrite() on sockets in sys_generic.c, I think it's a BAD IDEA to commit the patch. I *also* think that if this option is set on a listening socket, that, if it is implemented in this way, it should be inheritted by each accepted socket. If the bad idea must go forward, it should at least be implemented correctly. The obvious reasoning for this is that there is not an fd available on which to set the option for the new connection until after the accept(2) is called to accept the connection. Since the *entire* point of this patch *must* be to save the system call to check to see if a descriptor is writeable, OR to save the two system calls that disabling and reenabling the SIGPIPE around a write to close the tiny check-then-write race window, saving additional system calls on each socket opened to set the option is also good. Looking at it from a general standpoint, I'd *still* like to see some code that people are going to be running on FreeBSD that won't run without it. IF the option is committed because of the "compatability" argument, I'd like to see it named the same thing as at least one other OS, to avoid "#ifdef FreeBSD"; if that's not going to happen, then you might as well put better code in the #ifdef FreeBSD", instead. If I seem to think that this promotes signal semantics that I think ought to be determined by the system, well, here's Mario's original rationale for the change in the first place: | For those that might find it useful, here go a | simple scenario not easily reproduceable without SO_NOSIGPIPE: | multi-threaded client, some threads want to handle SIGPIPE, | others not. ...in other words, to control the threads signal semantics more closely than is normally permitted by the POSIX definition of signals. If I sound like I think this is a slippery slope -- I DO. I can see *at least* wanting to so the same for any signal that could result from a "write" that has a default of "terminate process". I could also see wanting to set the same for SIGURG -- in case the user establishes a SIGURG handler outside the context of the library and/or threaded application under discussion. It is *not* just "terminate process" signal actions that you have to worry about, it's also any signal whose default action is "discard signal", and which might have been overridden by the user. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 17 2:32:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 0941937B40E; Mon, 17 Jun 2002 02:32:41 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 494BC5361; Mon, 17 Jun 2002 11:32:38 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Mike Makonnen Cc: Doug Barton , nik@FreeBSD.ORG, julian@elischer.org, gordon@FreeBSD.ORG, brian@Awfulhak.org, arch@FreeBSD.ORG Subject: Re: rcNG rollout in -current References: <20020616224017.A52976@canyon.nothing-going-on.org> <3D0D0C4A.2B1B3102@FreeBSD.org> <20020617021106.7aa4ef86.makonnen@pacbell.net> From: Dag-Erling Smorgrav Date: 17 Jun 2002 11:32:37 +0200 In-Reply-To: <20020617021106.7aa4ef86.makonnen@pacbell.net> Message-ID: Lines: 11 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Makonnen writes: > Yes, this is why I've been dissapointed with the dearth of testers. I'm using rcng on my Miata, no problems so far (named and postfix both work fine, all I did was add rc_ng="YES" to rc.conf). Not using it on any other systems yet, but I've used /etc/rc.d scripts to stop / restart individual services like sshd. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 17 2:44: 3 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 216DC37B413; Mon, 17 Jun 2002 02:44:01 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id EE2F1AE03F; Mon, 17 Jun 2002 02:44:00 -0700 (PDT) Date: Mon, 17 Jun 2002 02:44:00 -0700 From: Alfred Perlstein To: Mario Sergio Fujikawa Ferreira Cc: FreeBSD-arch@FreeBSD.org, msmith@FreeBSD.org Subject: Re: Adding SO_NOSIGPIPE to -STABLE/-CURRENT Message-ID: <20020617094400.GJ67925@elvis.mu.org> References: <20020614022304.94570.qmail@exxodus.fedaykin.here> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020614022304.94570.qmail@exxodus.fedaykin.here> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Mario Sergio Fujikawa Ferreira [020613 19:24] wrote: > Hi, > > I would like you to review this proposal to add > the socket option SO_NOSIGPIPE: "Do not issue SIGPIPE on EPIPE." > Therefore, we can disable SIGPIPE on a per socket basis instead of > completing ignoring it with either sigpromask(2) or signal(3) > handling. Thanks for taking the time to present this. I'm going to try to make it an fcntl option instead (so that it can be applied to most descriptor types.) I should have it committed within a couple of days. thanks, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 17 9: 1:39 2002 Delivered-To: freebsd-arch@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 9AEBE37B40C; Mon, 17 Jun 2002 09:01:34 -0700 (PDT) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.36 #1) id 17JyxK-000GBx-00; Mon, 17 Jun 2002 18:02:14 +0200 From: Sheldon Hearn To: Mike Makonnen Cc: Doug Barton , nik@FreeBSD.ORG, julian@elischer.org, gordon@FreeBSD.ORG, brian@Awfulhak.org, arch@FreeBSD.ORG Subject: Re: rcNG rollout in -current In-reply-to: Your message of "Mon, 17 Jun 2002 02:11:06 MST." <20020617021106.7aa4ef86.makonnen@pacbell.net> Date: Mon, 17 Jun 2002 18:02:14 +0200 Message-ID: <62244.1024329734@axl.seasidesoftware.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 17 Jun 2002 02:11:06 MST, Mike Makonnen wrote: > Yes, this is why I've been dissapointed with the dearth of testers. Hang in there. I suspect that, now that it's actually committed, you'll be getting a LOT more feedback. I've had a look at the stuff you've brought over from NetBSD and I'm _very_ excited about it. I'm particularly impressed with the degree to which you've tried to stay true to the NetBSD implementation, not to mention the fact that you've pressed on in spite of a lot of criticism from folks who hadn't really given rcNG much thought, and a lot of apathy from those of us who're just plain short on time. I'm about to try my first rcNG bootstrap. I'm confident that there are lots of people who, like me, are much more likely to test stuff if it's in the tree and just requires the flick of a switch to turn on and off. So hang in there! Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 17 9:20:59 2002 Delivered-To: freebsd-arch@freebsd.org Received: from cheer.mahoroba.org (flets19-004.kamome.or.jp [218.45.19.4]) by hub.freebsd.org (Postfix) with ESMTP id 0C73137B405; Mon, 17 Jun 2002 09:20:54 -0700 (PDT) Received: from piano.mahoroba.org (IDENT:psfEUXNs6ze5Tb/6LpMvyp1eEIUUquk+AdeyQzVhBqWyRVK04kx9dqfzIxJwgW9t@piano.mahoroba.org [IPv6:2001:200:301:0:240:96ff:fe48:4ea8]) (user=ume mech=CRAM-MD5 bits=0) by cheer.mahoroba.org (8.12.4/8.12.4) with ESMTP/inet6 id g5HGKmIk030480 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 18 Jun 2002 01:20:49 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 18 Jun 2002 01:20:47 +0900 Message-ID: From: Hajimu UMEMOTO To: Terry Lambert Cc: arch@FreeBSD.org, hackers@FreeBSD.org Subject: Re: [CFR] max-child-per-ip restriction for inetd In-Reply-To: <3D0D1673.632F2386@mindspring.com> References: <3D0D1673.632F2386@mindspring.com> User-Agent: xcite1.38> Wanderlust/2.9.13 (Unchained Melody) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) X-Operating-System: FreeBSD 4.6-RELEASE MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, >>>>> On Sun, 16 Jun 2002 15:51:31 -0700 >>>>> Terry Lambert said: tlambert2> Your search_ip() function is a linear list traversal, which tlambert2> makes a lookup O(N). Oh, yes. I'm thinking that at begining. tlambert2> Is there any change you could use a hash or a btree or a tlambert2> skiplist or a trie or some other data structure *other* tlambert2> than a linear list traversal? Yes, I have a plan to reimplement it to use maybe btree or something. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 17 11:48:59 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 1C88537B400; Mon, 17 Jun 2002 11:48:54 -0700 (PDT) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g5HImilO139340; Mon, 17 Jun 2002 14:48:44 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20020617021106.7aa4ef86.makonnen@pacbell.net> References: <20020616224017.A52976@canyon.nothing-going-on.org> <3D0D0C4A.2B1B3102@FreeBSD.org> <20020617021106.7aa4ef86.makonnen@pacbell.net> Date: Mon, 17 Jun 2002 14:48:43 -0400 To: Mike Makonnen , Doug Barton From: Garance A Drosihn Subject: Re: rcNG rollout in -current Cc: nik@FreeBSD.ORG, julian@elischer.org, gordon@FreeBSD.ORG, brian@Awfulhak.org, arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 2:11 AM -0700 6/17/02, Mike Makonnen wrote: >On Sun, 16 Jun 2002 15:08:10 -0700 >Doug Barton wrote: > > > Yes, the reasoning is that since the goal is to have the > > new stuff doing exactly what the old stuff does, there's > > no reason not to just get it over with. > >Yes, this is why I've been dissapointed with the dearth of >testers. I've tried to set it up so that when you switch on >rcng, nothing will break. For that we need lots of testers... Don't be too discouraged just yet. People don't necessarily track -current as frequently as they do -stable, or at least I don't. I have windows of time that I can work on freebsd, and if some change has broken current during that window then I have to skip it for another week. Between my own schedule and assorted temporary breakages in -current, I had gone more than a month without getting a successful buildworld. (I managed to get one last night) -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 17 16:46:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by hub.freebsd.org (Postfix) with ESMTP id C8C2A37B406 for ; Mon, 17 Jun 2002 16:46:21 -0700 (PDT) Received: from kokeb.ambesa.net ([66.122.214.26]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GXV003RIJD95E@mta7.pltn13.pbi.net> for arch@FreeBSD.ORG; Mon, 17 Jun 2002 16:46:21 -0700 (PDT) Received: from kokeb.ambesa.net (tanstaafl@localhost [127.0.0.1]) by kokeb.ambesa.net (8.12.3/8.12.3) with ESMTP id g5HNpd8S002684; Mon, 17 Jun 2002 16:51:39 -0700 (PDT envelope-from mikem@kokeb.ambesa.net) Received: (from mikem@localhost) by kokeb.ambesa.net (8.12.3/8.12.3/Submit) id g5HNpb4T002683; Mon, 17 Jun 2002 16:51:37 -0700 (PDT envelope-from mikem) Date: Mon, 17 Jun 2002 16:51:37 -0700 From: Mike Makonnen Subject: Re: rcNG rollout in -current In-reply-to: <62244.1024329734@axl.seasidesoftware.co.za> To: Sheldon Hearn Cc: arch@FreeBSD.ORG Message-id: <20020617165137.65962cff.makonnen@pacbell.net> MIME-version: 1.0 X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i386--freebsd5.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <20020617021106.7aa4ef86.makonnen@pacbell.net> <62244.1024329734@axl.seasidesoftware.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 17 Jun 2002 18:02:14 +0200 Sheldon Hearn wrote: > > I've had a look at the stuff you've brought over from NetBSD and I'm > _very_ excited about it. I'm particularly impressed with the degree to > which you've tried to stay true to the NetBSD implementation Initially, I wasn't going to, but some proding from David O'Brien convinced me otherwise. > > I'm about to try my first rcNG bootstrap. I'm confident that there are > lots of people who, like me, are much more likely to test stuff if it's > in the tree and just requires the flick of a switch to turn on and off. Cool, give us some feedback (positive or otherwise). Cheers, Mike Makonnen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 17 19:51:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by hub.freebsd.org (Postfix) with ESMTP id 0FAFE37B420 for ; Mon, 17 Jun 2002 19:51:02 -0700 (PDT) Received: from hades.hell.gr (patr530-a120.otenet.gr [212.205.215.120]) by mailsrv.otenet.gr (8.12.3/8.12.3) with ESMTP id g5I2oT03002324; Tue, 18 Jun 2002 05:50:46 +0300 (EEST) Received: from hades.hell.gr (hades [127.0.0.1]) by hades.hell.gr (8.12.3/8.12.3) with ESMTP id g5I2oOUw075011; Tue, 18 Jun 2002 05:50:24 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Received: (from charon@localhost) by hades.hell.gr (8.12.3/8.12.3/Submit) id g5I2nhqE074946; Tue, 18 Jun 2002 05:49:44 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Date: Tue, 18 Jun 2002 05:49:42 +0300 From: Giorgos Keramidas To: Mike Makonnen Cc: Sheldon Hearn , arch@FreeBSD.org Subject: Re: rcNG rollout in -current Message-ID: <20020618024942.GB72217@hades.hell.gr> References: <20020617021106.7aa4ef86.makonnen@pacbell.net> <62244.1024329734@axl.seasidesoftware.co.za> <20020617165137.65962cff.makonnen@pacbell.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline In-Reply-To: <20020617165137.65962cff.makonnen@pacbell.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On 2002-06-17 16:51 -0700, Mike Makonnen wrote: > On Mon, 17 Jun 2002 18:02:14 +0200 > Sheldon Hearn wrote: > > I'm about to try my first rcNG bootstrap. I'm confident that there are > > lots of people who, like me, are much more likely to test stuff if it's > > in the tree and just requires the flick of a switch to turn on and off. > > Cool, give us some feedback (positive or otherwise). For what's its worth, when things are committed in -CURRENT, I tend to try them out more often and more extensively than things that are patches maintained out of the tree. Building world now, I'll probably join the club of the testers by midday ;) I'm very glad you didn't stop working on this, and it has eventually been committed. Thanks for all the work you and others have put in making this happen. - Giorgos --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9Dp/F1g+UGjGGA7YRAowWAJ4hH0D63AMPPXBuq9v76nQuQY/G6gCgwoHS ykEthKiFoa/Nv8KX8pyfSQE= =uRWo -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 18 1:29:17 2002 Delivered-To: freebsd-arch@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 95EE537B40F for ; Tue, 18 Jun 2002 01:29:11 -0700 (PDT) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.36 #1) id 17KEMn-0000CN-00; Tue, 18 Jun 2002 10:29:33 +0200 From: Sheldon Hearn To: Mike Makonnen Cc: arch@FreeBSD.ORG Subject: Re: rcNG rollout in -current In-reply-to: Your message of "Mon, 17 Jun 2002 16:51:37 MST." <20020617165137.65962cff.makonnen@pacbell.net> Date: Tue, 18 Jun 2002 10:29:32 +0200 Message-ID: <766.1024388972@axl.seasidesoftware.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 17 Jun 2002 16:51:37 MST, Mike Makonnen wrote: > > I'm about to try my first rcNG bootstrap. I'm confident that there are > > lots of people who, like me, are much more likely to test stuff if it's > > in the tree and just requires the flick of a switch to turn on and off. > > Cool, give us some feedback (positive or otherwise). First the otherwise feedback. :-) | /etc/rc: INFO: mountd depends on rpcbind, which will be forced to start. | Starting rpcbind. | Starting mountd. | /etc/rc: WARNING: $portmap_enable is not set. Historically, we've been allowed to have portmap_enable="NO" (which is what I have) and rest assured that it would be started as a dependency. For this reason, the WARNING seems unnecessary. Regardless, $portmap_program (rpcbind) is started correctly and 'showmount -e' indicates that mountd is working. | /etc/rc: WARNING: $sendmail_enable is not set properly. I think you alreday know about this one, but I'm not sure. The WARNING appears harmless -- sendmail was not started, which is what I wanted with sendmail_enable="NONE". | Starting named. | can't open 'rc_flags' | Jun 18 09:57:42 axl named[269]: can't open 'rc_flags' This is with named_rcng="YES" added to my existing named_enable="YES" and named_flags="-u bind -g bind". Looks like a simple typo in etc/rc.d/named: Index: named =================================================================== RCS file: /home/ncvs/src/etc/rc.d/named,v retrieving revision 1.2 diff -u -d -r1.2 named --- named 13 Jun 2002 22:14:36 -0000 1.2 +++ named 18 Jun 2002 08:00:49 -0000 @@ -84,7 +84,7 @@ ! checkyesno named_rcng && return 0 # Is the user using a sandbox? if [ -z "$named_chrootdir" ]; then - rc_flags="-u $nuser -g $ngroup rc_flags" + rc_flags="-u $nuser -g $ngroup $rc_flags" return 0 fi I see that the way etc/rc.d/named works, named_flags="-u bind -g bind" is no longer required. So finally we have sane defaults there. Cool. With this patch applied, named starts. The next step is to add named_chrootdir="/etc/named/s", where /etc/named/s and the appropriate subdirectories exist. Then, at least one required file is not copied into the chrootdir, namely etc/namedb/named.conf. Others, like etc/resolv.conf should probably be copied in as well, but this gets tricky. What if there are zone files? So it looks like the named_chrootdir idea needs a bit more thought. Unfortunately, I can't do the thinking right now. And now for the positive feedback. :-) I'm _very_ impressed. I'm really glad you persevered, really glad you listened to David O'Brien and really excited about where you've brought us to, to say nothing of where this means we can go! Good job! Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 18 2: 7:37 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay1.yahoo.com (mail-relay1.yahoo.com [216.145.48.34]) by hub.freebsd.org (Postfix) with ESMTP id 9AAB637B41D for ; Tue, 18 Jun 2002 02:07:11 -0700 (PDT) Received: from FreeBSD.org (12-234-90-219.client.attbi.com [12.234.90.219]) by mail-relay1.yahoo.com (Postfix) with ESMTP id 5266C8B5FD; Tue, 18 Jun 2002 02:07:11 -0700 (PDT) Message-ID: <3D0EF83F.447BAA11@FreeBSD.org> Date: Tue, 18 Jun 2002 02:07:11 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.79 [en] (X11; U; FreeBSD 4.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Sheldon Hearn Cc: Mike Makonnen , arch@FreeBSD.ORG Subject: Re: rcNG rollout in -current References: <766.1024388972@axl.seasidesoftware.co.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Sheldon Hearn wrote: > > On Mon, 17 Jun 2002 16:51:37 MST, Mike Makonnen wrote: > > > > I'm about to try my first rcNG bootstrap. I'm confident that there are > > > lots of people who, like me, are much more likely to test stuff if it's > > > in the tree and just requires the flick of a switch to turn on and off. > > > > Cool, give us some feedback (positive or otherwise). > > First the otherwise feedback. :-) > > | /etc/rc: INFO: mountd depends on rpcbind, which will be forced to start. > | Starting rpcbind. > | Starting mountd. > | /etc/rc: WARNING: $portmap_enable is not set. > > Historically, we've been allowed to have portmap_enable="NO" (which is > what I have) and rest assured that it would be started as a dependency. > For this reason, the WARNING seems unnecessary. DEPENDENCY NOTE: portmap will be enabled to support amd That's what the current version prints in the same circumstance. I think the warning is reasonable, just in case the user did something wonky. > Index: named > =================================================================== > RCS file: /home/ncvs/src/etc/rc.d/named,v > retrieving revision 1.2 > diff -u -d -r1.2 named > --- named 13 Jun 2002 22:14:36 -0000 1.2 > +++ named 18 Jun 2002 08:00:49 -0000 > @@ -84,7 +84,7 @@ > ! checkyesno named_rcng && return 0 > # Is the user using a sandbox? > if [ -z "$named_chrootdir" ]; then > - rc_flags="-u $nuser -g $ngroup rc_flags" > + rc_flags="-u $nuser -g $ngroup $rc_flags" > return 0 > fi Go ahead and punch that one in. > I see that the way etc/rc.d/named works, named_flags="-u bind -g bind" > is no longer required. So finally we have sane defaults there. Cool. Actually -g bind is pretty useless. That's one of the reasons they dropped it in BIND 9. > With this patch applied, named starts. > > The next step is to add named_chrootdir="/etc/named/s", where > /etc/named/s and the appropriate subdirectories exist. Then, at > least one required file is not copied into the chrootdir, namely > etc/namedb/named.conf. Others, like etc/resolv.conf should probably be > copied in as well, but this gets tricky. What if there are zone files? > > So it looks like the named_chrootdir idea needs a bit more thought. Some of us are working on it... if I can ever get out from under the gnome complications with xscreensaver, I plan to work on my "replace the system BIND" patches to the ports, then work on the chroot stuff. Thanks for the feedback, Doug -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 18 5: 1:51 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by hub.freebsd.org (Postfix) with ESMTP id 5A69737B403 for ; Tue, 18 Jun 2002 05:01:46 -0700 (PDT) Received: from kokeb.ambesa.net ([64.166.85.39]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GXW000QLHCUKO@mta5.snfc21.pbi.net> for arch@FreeBSD.ORG; Tue, 18 Jun 2002 05:01:46 -0700 (PDT) Received: from kokeb.ambesa.net (tanstaafl@localhost [127.0.0.1]) by kokeb.ambesa.net (8.12.3/8.12.3) with ESMTP id g5IC5k8S008599 for ; Tue, 18 Jun 2002 05:05:46 -0700 (PDT envelope-from mikem@kokeb.ambesa.net) Received: (from mikem@localhost) by kokeb.ambesa.net (8.12.3/8.12.3/Submit) id g5IC4VV2008586; Tue, 18 Jun 2002 05:04:31 -0700 (PDT envelope-from mikem) Date: Tue, 18 Jun 2002 05:04:31 -0700 From: Mike Makonnen Subject: Re: rcNG rollout in -current In-reply-to: <766.1024388972@axl.seasidesoftware.co.za> To: Sheldon Hearn Cc: arch@FreeBSD.ORG Message-id: <20020618050431.66169292.makonnen@pacbell.net> MIME-version: 1.0 X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i386--freebsd5.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <20020617165137.65962cff.makonnen@pacbell.net> <766.1024388972@axl.seasidesoftware.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 18 Jun 2002 10:29:32 +0200 Sheldon Hearn wrote: > > > First the otherwise feedback. :-) > > | /etc/rc: INFO: mountd depends on rpcbind, which will be forced to start. > | Starting rpcbind. > | Starting mountd. > | /etc/rc: WARNING: $portmap_enable is not set. > > Historically, we've been allowed to have portmap_enable="NO" (which is > what I have) and rest assured that it would be started as a dependency. > For this reason, the WARNING seems unnecessary. Regardless, > $portmap_program (rpcbind) is started correctly and 'showmount -e' > indicates that mountd is working. hmm... The warning is not comming from the forced starting of rpcbind. If it were, it would appear before "starting rpcbind." I think its some other service, maybe one of the yp* daemons. They require $portmap_enable to be on, but they don't force rpcbind to start if its not. I think I will make a pass through the scripts and get rid of those required_variables and just force whatever it is they need to start. > > | /etc/rc: WARNING: $sendmail_enable is not set properly. > > I think you alreday know about this one, but I'm not sure. The WARNING > appears harmless -- sendmail was not started, which is what I wanted > with sendmail_enable="NONE". > Yeah, it'll be there untill I get together with Gregory, which will be soon. > > So it looks like the named_chrootdir idea needs a bit more thought. > Unfortunately, I can't do the thinking right now. yeah, a sandboxed bind server seems to do that to people. :-) I will make it less icky one of these days. Cheers, Mike Makonnen. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 18 5:21:42 2002 Delivered-To: freebsd-arch@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 6013B37B408 for ; Tue, 18 Jun 2002 05:21:38 -0700 (PDT) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.36 #1) id 17KHzx-00022R-00; Tue, 18 Jun 2002 14:22:13 +0200 From: Sheldon Hearn To: Mike Makonnen Cc: arch@FreeBSD.ORG Subject: Re: rcNG rollout in -current In-reply-to: Your message of "Tue, 18 Jun 2002 05:04:31 MST." <20020618050431.66169292.makonnen@pacbell.net> Date: Tue, 18 Jun 2002 14:22:13 +0200 Message-ID: <7838.1024402933@axl.seasidesoftware.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 18 Jun 2002 05:04:31 MST, Mike Makonnen wrote: > > So it looks like the named_chrootdir idea needs a bit more thought. > > Unfortunately, I can't do the thinking right now. > > yeah, a sandboxed bind server seems to do that to people. :-) > I will make it less icky one of these days. It's a pretty small wart, given the size of the toad, and it doesn't take us back from where we were before. I wouldn't let this discourage me if I were you. In fact, if I were you, I'd feel very pleased with my contribution of effort. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 18 6: 0:33 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by hub.freebsd.org (Postfix) with ESMTP id 23ADE37B40D for ; Tue, 18 Jun 2002 06:00:14 -0700 (PDT) Received: from kokeb.ambesa.net ([64.166.85.39]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GXW00IK2K49EY@mta6.snfc21.pbi.net> for arch@FreeBSD.ORG; Tue, 18 Jun 2002 06:00:09 -0700 (PDT) Received: from kokeb.ambesa.net (tanstaafl@localhost [127.0.0.1]) by kokeb.ambesa.net (8.12.3/8.12.3) with ESMTP id g5ID5O8S008916; Tue, 18 Jun 2002 06:05:24 -0700 (PDT envelope-from mikem@kokeb.ambesa.net) Received: (from mikem@localhost) by kokeb.ambesa.net (8.12.3/8.12.3/Submit) id g5ID5O4W008915; Tue, 18 Jun 2002 06:05:24 -0700 (PDT envelope-from mikem) Date: Tue, 18 Jun 2002 06:05:24 -0700 From: Mike Makonnen Subject: Re: rcNG rollout in -current In-reply-to: <7838.1024402933@axl.seasidesoftware.co.za> To: Sheldon Hearn Cc: arch@FreeBSD.ORG Message-id: <20020618060524.0e1f1238.makonnen@pacbell.net> MIME-version: 1.0 X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i386--freebsd5.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <20020618050431.66169292.makonnen@pacbell.net> <7838.1024402933@axl.seasidesoftware.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 18 Jun 2002 14:22:13 +0200 Sheldon Hearn wrote: > > > > So it looks like the named_chrootdir idea needs a bit more thought. > > > Unfortunately, I can't do the thinking right now. > > > > yeah, a sandboxed bind server seems to do that to people. :-) > > I will make it less icky one of these days. > > It's a pretty small wart, given the size of the toad, and it doesn't > take us back from where we were before. I wouldn't let this discourage > me if I were you. In fact, if I were you, I'd feel very pleased with my > contribution of effort. :-) Thanks. I wasn't complaining. Even though it is better than what we previously had it could still use some improvement. Which reminds me, could you put a note in UPDATING that: - setting rcng_named on means you have to remove "-u bind -g bind" from named_flags - while the boot scripts will start named jailed correctly it's up to the administrator to make sure that configuration and zone files are placed correctly - By default /var/run/named.pid will be symlinked to /var/run/named.pid and syslog will open a socket in /var/run Thanks, Mike. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 18 6: 5: 7 2002 Delivered-To: freebsd-arch@freebsd.org Received: from femme.listmistress.org (bgp01560565bgs.gambrl01.md.comcast.net [68.50.32.109]) by hub.freebsd.org (Postfix) with ESMTP id DCF8C37B407; Tue, 18 Jun 2002 06:05:01 -0700 (PDT) Received: from femme.listmistress.org (trish@localhost [127.0.0.1]) by femme.listmistress.org (8.12.3/8.12.1) with ESMTP id g5ID4xKB014787; Tue, 18 Jun 2002 09:05:00 -0400 (EDT) Received: from localhost (trish@localhost) by femme.listmistress.org (8.12.3/8.12.3/Submit) with ESMTP id g5ID4vr2014784; Tue, 18 Jun 2002 09:04:58 -0400 (EDT) X-Authentication-Warning: femme.listmistress.org: trish owned process doing -bs Date: Tue, 18 Jun 2002 09:04:57 -0400 (EDT) From: Trish Lynch X-X-Sender: To: Nik Clayton Cc: Subject: Re: 4.x compatibilty.. Was: MFC of rcNG? In-Reply-To: <20020616224017.A52976@canyon.nothing-going-on.org> Message-ID: <20020618090225.Y464-100000@femme.listmistress.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 16 Jun 2002, Nik Clayton wrote: > > 4.7 -- Announce the new system, with the old system as default > 5.0 -- Use the new system as default, keep the old system > 6.0 -- Remove the old system > for what its worth, I agree with this rather than the "2.2+rc is going away as soon as 5.0 comes out" People may have changes to the original rc system that they were using that they would be given time to migrate if we used rcng as the default in 5.0 but were able to use the old one as well, then in 6.0 it can toally go away. With as many irons in the fire as we all have right now, I think the 6.0 release will not be as far off as 5.0 was from 4.0 anyway. -Trish -- Trish Lynch trish@bsdunix.net FreeBSD The Power to Serve Ecartis Core Team trish@listmistress.org http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 18 6:12: 0 2002 Delivered-To: freebsd-arch@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 4DF9A37B410 for ; Tue, 18 Jun 2002 06:11:57 -0700 (PDT) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.36 #1) id 17KImg-0002Hw-00; Tue, 18 Jun 2002 15:12:34 +0200 From: Sheldon Hearn To: Mike Makonnen Cc: arch@FreeBSD.ORG Subject: Re: rcNG rollout in -current In-reply-to: Your message of "Tue, 18 Jun 2002 06:05:24 MST." <20020618060524.0e1f1238.makonnen@pacbell.net> Date: Tue, 18 Jun 2002 15:12:34 +0200 Message-ID: <8799.1024405954@axl.seasidesoftware.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 18 Jun 2002 06:05:24 MST, Mike Makonnen wrote: > Which reminds me, could you put a note in UPDATING that: > > - setting rcng_named on means you have to remove "-u bind -g bind" > from named_flags It's not required, but it does look a little funny having the options repeated in the proctitle. > - while the boot scripts will start named jailed correctly it's up to > the administrator to make sure that configuration and zone files > are placed correctly Okay. > - By default /var/run/named.pid will be symlinked to > /var/run/named.pid and syslog will open a socket in > /var/run Are you sure? I could swear it was /var/run/named/pid and /var/run/named/pid. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 18 7:21:19 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by hub.freebsd.org (Postfix) with ESMTP id A034E37B407 for ; Tue, 18 Jun 2002 07:21:16 -0700 (PDT) Received: from kokeb.ambesa.net ([64.166.85.39]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GXW00IULNVGFX@mta6.snfc21.pbi.net> for arch@FreeBSD.ORG; Tue, 18 Jun 2002 07:21:16 -0700 (PDT) Received: from kokeb.ambesa.net (tanstaafl@localhost [127.0.0.1]) by kokeb.ambesa.net (8.12.3/8.12.3) with ESMTP id g5IEQV8S009192; Tue, 18 Jun 2002 07:26:31 -0700 (PDT envelope-from mikem@kokeb.ambesa.net) Received: (from mikem@localhost) by kokeb.ambesa.net (8.12.3/8.12.3/Submit) id g5IEQUL6009191; Tue, 18 Jun 2002 07:26:30 -0700 (PDT envelope-from mikem) Date: Tue, 18 Jun 2002 07:26:30 -0700 From: Mike Makonnen Subject: Re: rcNG rollout in -current In-reply-to: <8799.1024405954@axl.seasidesoftware.co.za> To: Sheldon Hearn Cc: arch@FreeBSD.ORG Message-id: <20020618072630.49a803cf.makonnen@pacbell.net> MIME-version: 1.0 X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i386--freebsd5.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <20020618060524.0e1f1238.makonnen@pacbell.net> <8799.1024405954@axl.seasidesoftware.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 18 Jun 2002 15:12:34 +0200 Sheldon Hearn wrote: > > > - By default /var/run/named.pid will be symlinked to > > /var/run/named.pid and syslog will open a socket in > > /var/run > > Are you sure? I could swear it was /var/run/named/pid and > /var/run/named/pid. > Yes, /var/run/named/ was added as a workaround a couple of weeks ago because named no longer ran as root anymore and therefore didn't have the necessary permissions to write to /var/run/. Cheers, Mike Makonnen. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 18 10:54:54 2002 Delivered-To: freebsd-arch@freebsd.org Received: from 12-234-90-219.client.attbi.com (12-234-90-219.client.attbi.com [12.234.90.219]) by hub.freebsd.org (Postfix) with ESMTP id DB28137B40F; Tue, 18 Jun 2002 10:54:48 -0700 (PDT) Received: from master.gorean.org (master.gorean.org [10.0.0.2]) by 12-234-90-219.client.attbi.com (8.12.3/8.12.3) with ESMTP id g5IHsWBu021635; Tue, 18 Jun 2002 10:54:32 -0700 (PDT) (envelope-from DougB@FreeBSD.org) Received: from localhost (doug@localhost) by master.gorean.org (8.12.4/8.12.4/Submit) with ESMTP id g5IHsW75001815; Tue, 18 Jun 2002 10:54:32 -0700 (PDT) Date: Tue, 18 Jun 2002 10:54:32 -0700 (PDT) From: Doug Barton To: Trish Lynch Cc: Nik Clayton , Subject: Re: 4.x compatibilty.. Was: MFC of rcNG? In-Reply-To: <20020618090225.Y464-100000@femme.listmistress.org> Message-ID: <20020618105115.A1723-100000@master.gorean.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 18 Jun 2002, Trish Lynch wrote: > for what its worth, I agree with this rather than the "2.2+rc is going > away as soon as 5.0 comes out" > > People may have changes to the original rc system that they were using > that they would be given time to migrate if we used rcng as the default in > 5.0 but were able to use the old one as well First, anyone smart enough to make modifications to their /etc/rc* scripts is probably smart enough to hack them into the rcNG framework with a minimum of fuss. It's not really THAT much different internally. Second, it's exactly for situations like this that I think we SHOULD make a clean break at 5.0. There are already enough clean breaks to be made other places, this is very likely to be one of the least of them. -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 18 11: 6:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id E318B37B404; Tue, 18 Jun 2002 11:06:06 -0700 (PDT) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.36 #1) id 17KNNK-0005Na-00; Tue, 18 Jun 2002 20:06:42 +0200 From: Sheldon Hearn To: Doug Barton Cc: Trish Lynch , Nik Clayton , arch@FreeBSD.org Subject: Re: 4.x compatibilty.. Was: MFC of rcNG? In-reply-to: Your message of "Tue, 18 Jun 2002 10:54:32 MST." <20020618105115.A1723-100000@master.gorean.org> Date: Tue, 18 Jun 2002 20:06:42 +0200 Message-ID: <20681.1024423602@axl.seasidesoftware.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 18 Jun 2002 10:54:32 MST, Doug Barton wrote: > First, anyone smart enough to make modifications to their /etc/rc* scripts > is probably smart enough to hack them into the rcNG framework with a > minimum of fuss. It's not really THAT much different internally. Second, > it's exactly for situations like this that I think we SHOULD make a clean > break at 5.0. There are already enough clean breaks to be made other > places, this is very likely to be one of the least of them. How about this... We commit to keeping rcOLD working on RELENG_4 to the end of RELENG_4. We commit to making rcNG available as an experimental option on RELENG_4 well before 4.7-RELEASE, as long as we think it's feasible to do so. We commit to keeping rcOLD working on HEAD / RELENG_5 as long as it's feasible to do so. We make rcNG the default for 5.0-RELEASE, so that the hurdle is encountered when upgraders are most expecting hurdles. We make it clear in the release notes for 5.0-RELEASE that rcOLD, while still supported, may go away at some point in the lifespan of RELENG_5. Seems to me that this would keep as many people happy as possible, without making any commitments that might hinder forward motion. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 18 11:23:43 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay1.yahoo.com (mail-relay1.yahoo.com [216.145.48.34]) by hub.freebsd.org (Postfix) with ESMTP id 59B5637B407; Tue, 18 Jun 2002 11:23:39 -0700 (PDT) Received: from FreeBSD.org (12-234-90-219.client.attbi.com [12.234.90.219]) by mail-relay1.yahoo.com (Postfix) with ESMTP id E54828B61F; Tue, 18 Jun 2002 11:23:38 -0700 (PDT) Message-ID: <3D0F7AAA.110E0D8@FreeBSD.org> Date: Tue, 18 Jun 2002 11:23:38 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.79 [en] (X11; U; FreeBSD 4.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Sheldon Hearn Cc: Trish Lynch , Nik Clayton , arch@FreeBSD.ORG Subject: Re: 4.x compatibilty.. Was: MFC of rcNG? References: <20681.1024423602@axl.seasidesoftware.co.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Sheldon Hearn wrote: > How about this... > > We commit to keeping rcOLD working on RELENG_4 to the end of > RELENG_4. That's a given. > We commit to making rcNG available as an experimental option > on RELENG_4 well before 4.7-RELEASE, as long as we think it's > feasible to do so. For sufficiently conservative definitions of "feasible," ok. > We commit to keeping rcOLD working on HEAD / RELENG_5 as long as > it's feasible to do so. Wadda ya mean "we" kemo sabe? It's already going to be enough work to keep rcng up to date on 5.x, and the old system up to date on 4.x. Maintainging 3 seperate rc systems on 2 widely divergent branches doesn't sound like fun to me. I would like to reiterate my previous points... namely that for the vast majority of users, this change will be almost unnoticed. They will still have the familiar rc.conf[.local] files, and whether we have rcold in there or not, they will still have to update them for 5.x. Further confusing the issue by having two different systems in the base won't help, it'll only hurt. I would also like to suggest at this point that we hold off on further discussion of this nature till we flip the switch to make rc_ng the default. Rather than speculate as to how big a hill we have to climb, let's actually start the trip, and see how it looks after day 1. Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 18 11:35:15 2002 Delivered-To: freebsd-arch@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 04A7837B406; Tue, 18 Jun 2002 11:35:02 -0700 (PDT) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.36 #1) id 17KNpK-0005T3-00; Tue, 18 Jun 2002 20:35:38 +0200 From: Sheldon Hearn To: Doug Barton Cc: Trish Lynch , Nik Clayton , arch@FreeBSD.ORG Subject: Re: 4.x compatibilty.. Was: MFC of rcNG? In-reply-to: Your message of "Tue, 18 Jun 2002 11:23:38 MST." <3D0F7AAA.110E0D8@FreeBSD.org> Date: Tue, 18 Jun 2002 20:35:38 +0200 Message-ID: <21020.1024425338@axl.seasidesoftware.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 18 Jun 2002 11:23:38 MST, Doug Barton wrote: > I would also like to suggest at this point that we hold off on > further discussion of this nature till we flip the switch to make > rc_ng the default. Rather than speculate as to how big a hill we have > to climb, let's actually start the trip, and see how it looks after > day 1. That makes a lot of sense. Why make decisions on how to deal with this now, before we've seen what the impact is? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 18 11:42:23 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay1.yahoo.com (mail-relay1.yahoo.com [216.145.48.34]) by hub.freebsd.org (Postfix) with ESMTP id 17AEB37B408; Tue, 18 Jun 2002 11:42:17 -0700 (PDT) Received: from FreeBSD.org (12-234-90-219.client.attbi.com [12.234.90.219]) by mail-relay1.yahoo.com (Postfix) with ESMTP id AF58D8B5D0; Tue, 18 Jun 2002 11:42:16 -0700 (PDT) Message-ID: <3D0F7F08.6899223C@FreeBSD.org> Date: Tue, 18 Jun 2002 11:42:16 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.79 [en] (X11; U; FreeBSD 4.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Sheldon Hearn Cc: Trish Lynch , Nik Clayton , arch@FreeBSD.ORG Subject: Re: 4.x compatibilty.. Was: MFC of rcNG? References: <21020.1024425338@axl.seasidesoftware.co.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Sheldon Hearn wrote: > > On Tue, 18 Jun 2002 11:23:38 MST, Doug Barton wrote: > > > I would also like to suggest at this point that we hold off on > > further discussion of this nature till we flip the switch to make > > rc_ng the default. Rather than speculate as to how big a hill we have > > to climb, let's actually start the trip, and see how it looks after > > day 1. > > That makes a lot of sense. Thanks, I try to do that occasionally, just to keep people off balance. :)y To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 18 12:54: 5 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.gnf.org (ns1.gnf.org [63.196.132.67]) by hub.freebsd.org (Postfix) with ESMTP id 140B237B403; Tue, 18 Jun 2002 12:54:00 -0700 (PDT) Received: from mail.gnf.org (smtp.gnf.org [172.25.11.11]) by ns1.gnf.org (8.11.6/8.11.6) with ESMTP id g5IJrhX08091; Tue, 18 Jun 2002 12:53:43 -0700 (PDT) (envelope-from gordon@FreeBSD.org) Received: by mail.gnf.org (Postfix, from userid 888) id 6AD9411E515; Tue, 18 Jun 2002 12:53:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.gnf.org (Postfix) with ESMTP id 69ABD11A572; Tue, 18 Jun 2002 12:53:39 -0700 (PDT) Date: Tue, 18 Jun 2002 12:53:39 -0700 (PDT) From: Gordon Tetlow X-X-Sender: gordont@smtp.gnf.org To: Sheldon Hearn Cc: Doug Barton , Trish Lynch , Nik Clayton , Subject: Re: 4.x compatibilty.. Was: MFC of rcNG? In-Reply-To: <20681.1024423602@axl.seasidesoftware.co.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 18 Jun 2002, Sheldon Hearn wrote: > We make rcNG the default for 5.0-RELEASE, so that the hurdle is > encountered when upgraders are most expecting hurdles. We make > it clear in the release notes for 5.0-RELEASE that rcOLD, while > still supported, may go away at some point in the lifespan of > RELENG_5. The problem isn't that we want to get rid of rcOLD (well, maybe we do =), but more the problem of maintenance. DougB and I don't have a whole lot of time to dedicate to keeping things in sync. That said, we plan on making a best effort to keep everything glued together. Finally, I think a wait and see attitude is the best option. Let's figure out how much of a headache we will have before throwing aspirin at it. -gordon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 18 14:55:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from nothing-going-on.demon.co.uk (pc-62-31-42-140-hy.blueyonder.co.uk [62.31.42.140]) by hub.freebsd.org (Postfix) with ESMTP id 14AFA37B413 for ; Tue, 18 Jun 2002 14:54:47 -0700 (PDT) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.11.3/8.11.3) id g5ILtNC74876 for arch@freebsd.org; Tue, 18 Jun 2002 22:55:23 +0100 (BST) (envelope-from nik) Date: Tue, 18 Jun 2002 22:55:23 +0100 From: Nik Clayton To: arch@freebsd.org Subject: Timetables for interface deprecation/deletion Message-ID: <20020618225523.J52976@canyon.nothing-going-on.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="hABqaeELJqnDDeDE" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Organization: FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --hABqaeELJqnDDeDE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ It's times like this I regret the fact that we don't have a Linus equivalent to lay down the law ] As FreeBSD develops, we inevitably change, adapt, and throw away old 'interfaces'. =20 * Library APIs * The behaviour of command line options * The use of certain commands * Configuration options and mechanisms and more. I think the life cycle of an interface can be described as follows: Introductory We make no guarantee this interface will be in future versions of FreeBSD. Stable This interface is guaranteed to exist in=20 all minor versions of FreeBSD corresponding with the major version in which it exists. Once an interface is marked 'Stable' it must go through the 'Deprecated' and 'Obsolete' stages before removal. Deprecated The interface is supported, but is slated for obsolecence in the next major release of FreeBSD. Obsolete The interface is not supported. It may work, but it is not guaranteed to. The interface will be removed in the next major version of FreeBSD. Assuming, for the moment, that that makes sense to people, over what sort= =20 of timescales should interfaces move from state to state? And does the project have the will to guarantee this? [ "Guarantee"? OK, nothing's guaranteed in an open source project. But IMHO, there are a few things that the project should commit to. As long as these things are appropriately documented, and decided upon -- committer vote? core declaration? -- unwillingness to commit to them=20 should be grounds for removal of a commit bit.=20 =20 Harsh, I know. But as I mention above, we don't have a Linus-like figure to lay down the law. ] N --=20 FreeBSD: The Power to Serve http://www.freebsd.org/ (__) FreeBSD Documentation Project http://www.freebsd.org/docproj/ \\\'',) \/ \= ^ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- .\._/= _) --hABqaeELJqnDDeDE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9D6xKk6gHZCw343URAoVwAKCQx2W9lRFkU77e4cRxHF/lJQ3DBwCfcxc+ +w6nhphALy3EMZ07778VI2E= =LpCz -----END PGP SIGNATURE----- --hABqaeELJqnDDeDE-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 18 14:56:16 2002 Delivered-To: freebsd-arch@freebsd.org Received: from nothing-going-on.demon.co.uk (pc-62-31-42-140-hy.blueyonder.co.uk [62.31.42.140]) by hub.freebsd.org (Postfix) with ESMTP id 4553B37B437; Tue, 18 Jun 2002 14:54:58 -0700 (PDT) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.11.3/8.11.3) id g5ILeU774857; Tue, 18 Jun 2002 22:40:30 +0100 (BST) (envelope-from nik) Date: Tue, 18 Jun 2002 22:40:30 +0100 From: Nik Clayton To: Doug Barton Cc: Sheldon Hearn , Trish Lynch , Nik Clayton , arch@FreeBSD.ORG Subject: Re: 4.x compatibilty.. Was: MFC of rcNG? Message-ID: <20020618224029.I52976@canyon.nothing-going-on.org> References: <20681.1024423602@axl.seasidesoftware.co.za> <3D0F7AAA.110E0D8@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="2oox5VnwalALFvA7" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D0F7AAA.110E0D8@FreeBSD.org>; from DougB@FreeBSD.org on Tue, Jun 18, 2002 at 11:23:38AM -0700 Organization: FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --2oox5VnwalALFvA7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 18, 2002 at 11:23:38AM -0700, Doug Barton wrote: > I would like to reiterate my previous points... namely that for the > vast majority of users, this change will be almost unnoticed.=20 Not so. At least, I hope not. At the very least, I look forward to being able to tell people "Yes, you can stop/start/restart any service with 'sh /etc/rc.d/.sh stop|start|restart" In addition, the way the sysadmin moves things around in the boot order will change. Instead of editing /etc/rc*, you change some comments in some shell scripts. If I want to find out *why* things started in a particular order I now run rcorder(8). Doubtless there are others. So, not only does the project's documentation have to change, but so does all the internal documentation maintained by companies that are using FreeBSD that describes how to do things to their FreeBSD systems. [ Now multiply this by every change that's going in to 5.x that won't have a backward compatible implementation ] These changes take time to make. And throwing up yet another bar in the adoption of 5.x is a *bad thing*. This is about to become a wider discussion that rc_ng. So I'll stop here, and kick off a new thread. N --=20 FreeBSD: The Power to Serve http://www.freebsd.org/ (__) FreeBSD Documentation Project http://www.freebsd.org/docproj/ \\\'',) \/ \= ^ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- .\._/= _) --2oox5VnwalALFvA7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9D6jNk6gHZCw343URAuboAKCWeHUSh85iBQwFAXXYp2zqhTilqACgj/6v qhjg7Ng2hc2jsqs0OC6BkwU= =iMxZ -----END PGP SIGNATURE----- --2oox5VnwalALFvA7-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 18 15:17:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay1.yahoo.com (mail-relay1.yahoo.com [216.145.48.34]) by hub.freebsd.org (Postfix) with ESMTP id A892B37B407; Tue, 18 Jun 2002 15:17:38 -0700 (PDT) Received: from FreeBSD.org (socks1.yahoo.com [216.145.50.200]) by mail-relay1.yahoo.com (Postfix) with ESMTP id 147288B621; Tue, 18 Jun 2002 15:17:38 -0700 (PDT) Message-ID: <3D0FB17F.6F8B5819@FreeBSD.org> Date: Tue, 18 Jun 2002 15:17:35 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.79 [en] (X11; U; FreeBSD 4.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nik Clayton Cc: Sheldon Hearn , Trish Lynch , arch@freebsd.org Subject: Re: 4.x compatibilty.. Was: MFC of rcNG? References: <20681.1024423602@axl.seasidesoftware.co.za> <3D0F7AAA.110E0D8@FreeBSD.org> <20020618224029.I52976@canyon.nothing-going-on.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nik Clayton wrote: > > On Tue, Jun 18, 2002 at 11:23:38AM -0700, Doug Barton wrote: > > I would like to reiterate my previous points... namely that for the > > vast majority of users, this change will be almost unnoticed. > > Not so. At least, I hope not. At the very least, I look forward to > being able to tell people "Yes, you can stop/start/restart any service > with 'sh /etc/rc.d/.sh stop|start|restart" Yeah, sorry... I was thinking about it from a different perspective. My point is that for most of our users, whose only contact with the rc* stuff that exists currently is twiddling rc.conf*, the change will be transparent. For those "medium to high" power/enterprise/commercial users who actually care about such things, there will be a learning curve. But (and I may be biased here) I think it's all curving in the right direction. > So, not only does the project's documentation have to change, but so > does all the internal documentation maintained by companies that are > using FreeBSD that describes how to do things to their FreeBSD systems. *Nod* But, in one sense my way makes things easier because it gives you a clean point of delimitation. "If you have a 5.x system, you do this. If you have a 4.x system, you do this." As opposed to any of the 4+ different combinations of ([45].x times rc[ng|old] times other variables) that I know I'd hate to write documentation for. :) > These changes take time to make. And throwing up yet another bar in the > adoption of 5.x is a *bad thing*. > > This is about to become a wider discussion that rc_ng. Ok, I agree with your premise (this is one more hurdle), but not your conclusions. I'll likely contribute to the new thread you're going to start, but briefly, my thought is that precisely because 5.x is going to be a major paradigm shift in so many other areas, we ought to get as much of the pain out of the way as early in the process as we can. I also don't think that putting the bar high is a bad thing. It'll help restrict the early adopters to people who are already highly motivated. The contrast to "5.x is too hard to migrate to." Is, "Every time I think I understand 5.x, they change something else! To hell with them!" I think the latter is MUCH more dangerous long term. Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 18 16:11: 1 2002 Delivered-To: freebsd-arch@freebsd.org Received: from 12-234-90-219.client.attbi.com (12-234-90-219.client.attbi.com [12.234.90.219]) by hub.freebsd.org (Postfix) with ESMTP id DDD2337B419; Tue, 18 Jun 2002 16:10:34 -0700 (PDT) Received: from master.gorean.org (master.gorean.org [10.0.0.2]) by 12-234-90-219.client.attbi.com (8.12.3/8.12.3) with ESMTP id g5INAYBu025064; Tue, 18 Jun 2002 16:10:34 -0700 (PDT) (envelope-from DougB@FreeBSD.org) Received: from localhost (doug@localhost) by master.gorean.org (8.12.4/8.12.4/Submit) with ESMTP id g5INAYSR002535; Tue, 18 Jun 2002 16:10:34 -0700 (PDT) Date: Tue, 18 Jun 2002 16:10:34 -0700 (PDT) From: Doug Barton To: "Jin Guojun[DSD]" Cc: "Crist J. Clark" , , Subject: Re: conf/39444: rc.sendmail syntax error: cannot disable sendmail In-Reply-To: <3D0FB406.83DE356D@lbl.gov> Message-ID: <20020618155900.O2483-100000@master.gorean.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [ Greg, including you to get your opinion on my proposal below, and switching to -arch for the same reason. ] On Tue, 18 Jun 2002, Jin Guojun[DSD] wrote: > "Crist J. Clark" wrote: > > "NO" _can_ be used. It's meaning is different than "NONE." "NO" means > > not to run the sendmail(8) listener, but the submitting and 'outbound' > > daemons can still be run. > > sendmail does not need to run on background to send/submit outbound mail. > The backgrounding daemon is solely for receiving inbound message. There are two daemons started for "typical" mail _delivery_ purposes. One is there to run the queue periodically. Current thought is that this is superior to doing it through cron. The other is in fact there to receive connections from the local host. This is new to recent versions of sendmail, and allows the daemon that runs for that purpose to do so as an unprivileged user. > Nop, the manual page does not say "NO" can be used any where. If "NO" > cannot be used, then, it is not compatible to existing sys-admin > syntax. It forces to use "NONE" instead of "NO" as Doug's message > in closing this case: The problem here is that historically sendmail_enable="NO" always meant "don't run a listener for incoming mail, but still let me send mail from this host." The current situation preserves that meaning, even though it still starts two sendmail daemons. What I think is confusing to users is that we're trying to overload the sendmail_enable option to also handle whether or not to use any kind of sendmail by adding the NONE value. What I think we need is a new knob, something like use_real_sendmail, that will default to YES, leaving the new status quo for sendmail_enable="NO" intact, but also be able to completely disable all sendmail stuff, including listeners for outgoing mail, queue runners, etc. That way users can have a clear indication of what's going to happen, and the same YES/NO syntax they are familiar with. I'm definitely open to suggestions on the name of the knob, but what do y'all think of the idea? -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 18 18: 0:44 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id AD9A737B403; Tue, 18 Jun 2002 18:00:38 -0700 (PDT) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g5J10awQ141464; Tue, 18 Jun 2002 21:00:36 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <3D0FB17F.6F8B5819@FreeBSD.org> References: <20681.1024423602@axl.seasidesoftware.co.za> <3D0F7AAA.110E0D8@FreeBSD.org> <20020618224029.I52976@canyon.nothing-going-on.org> <3D0FB17F.6F8B5819@FreeBSD.org> Date: Tue, 18 Jun 2002 21:00:34 -0400 To: Doug Barton , Nik Clayton From: Garance A Drosihn Subject: Re: 4.x compatibilty.. Was: MFC of rcNG? Cc: Sheldon Hearn , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 3:17 PM -0700 6/18/02, Doug Barton wrote: > Yeah, sorry... I was thinking about it from a different >perspective. My point is that for most of our users, whose only >contact with the rc* stuff that exists currently is twiddling >rc.conf*, the change will be transparent. For those "medium to >high" power/enterprise/commercial users who actually care about >such things, there will be a learning curve. But (and I may be >biased here) I think it's all curving in the right direction. Providing for a smooth transition for some new change does not in any way imply that the change is a bad direction. I think the rcNew stuff is great to see. For the users who *do* care about /etc/rc-stuff, please realize that they are going to face whatever headaches that we developers avoid. It's not like they are all running one single machine which will be running 4.x one day, and 5.x the next. They're going to have multiple machines, and any responsible organization is going to run 5.0 on a few machines for awhile, instead of cutting the entire organization over in one fell swoop. Some of them won't REALLY switch over their organization to 5.x until 5.1-release or even later. They WILL have to deal with both rc-setups on a day-to-day basis for months. It is obviously more work to get rcNew into stable, or support rcOld in -current, but I do think that one or the other of those things should happen. I would think that it would be nicer to get rcNew into stable -- even though that implies more work, because it *should* be true that rcOld in the 4.x-stable branch will be seeing fewer changes as our (developer) attention moves more and more to 5.x-current. I also assume that anyone who has to deal with both branches will soon feel that they would rather have rcNew in both, and not rcOld in both. I also think that we don't really have all that many people testing things on current. We claim to have hundreds of thousands, if not millions of FreeBSD users. I doubt we have more than 50-100 users who are *actively* tracking -current. There are a lot of odd cases which can come up in that other 99.9% of our users. Please note that none of this is meant as a comment specific to rcNew per se. I'm just of the opinion that any user-visible improvement that we *can* move into stable, without disrupting stable, is probably a good thing. I do appreciate all the work it's taken to get rcNew this far. But I also think we should be slow to say "There are so many completely incompatible changes in 5.0 anyway, what's one more?". For some change which can be MFC'ed (without disruption), I think that both developers and the end-users are better off if the change is at least available for testing by users in stable. Now, that could very well be a reasonable thing to say for rcNew, but I'd just be slow to say it... :-) -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 18 18:20:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by hub.freebsd.org (Postfix) with ESMTP id 8241A37B40A; Tue, 18 Jun 2002 18:19:56 -0700 (PDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g5J1Jtk20161; Tue, 18 Jun 2002 18:19:56 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 18 Jun 2002 18:19:55 -0700 Received: from twogun.apple.com (twogun.apple.com [17.202.45.118]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id g5J1Jri10871; Tue, 18 Jun 2002 18:19:54 -0700 (PDT) Date: Tue, 18 Jun 2002 18:19:51 -0700 Subject: Re: Timetables for interface deprecation/deletion Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v524) Cc: arch@FreeBSD.ORG To: Nik Clayton From: "Jordan K. Hubbard" In-Reply-To: <20020618225523.J52976@canyon.nothing-going-on.org> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.524) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nik, I'm glad you were the first one to bring this up since I'd likely have only been accused of being self-serving if I were the one to do so. :-) Apple is facing the very same issue with respect to "published APIs" and making it clear which we're free to deprecate at some future date, which are obsolete and purely for backwards compatibility (e.g. not to be used for new code), which are purely "use at your own risk" and which are fully supported in the sense that we'll contort ourselves into all sorts of unnatural shapes, if and as necessary, to preserve compatibility with them. We've also adopted Sun's nomenclature for the macros which bracket these APIs in various headers since we didn't see any need to reinvent that particular wheel. I don't have the list handy right now, but it basically defines the macro names you need to bracket the various header definitions for the APIs you want to classify and/or restrict. If FreeBSD's willing to go the same route, it would greatly help in syncronizing this kind of API clean-up work between FreeBSD and Darwin. Thoughts? I'm just looking for opinions at this stage and nobody's talking about touching ANYTHING right now, this is just stage 1 (or zero, depending on how you measure things). - Jordan On Tuesday, Jun 18, 2002, at 14:55 America/Los_Angeles, Nik Clayton wrote: > [ It's times like this I regret the fact that we don't have a Linus > equivalent to lay down the law ] > > As FreeBSD develops, we inevitably change, adapt, and throw away old > 'interfaces'. > > * Library APIs > * The behaviour of command line options > * The use of certain commands > * Configuration options and mechanisms > > and more. > > I think the life cycle of an interface can be described as follows: > > Introductory We make no guarantee this interface will be in > future versions of FreeBSD. > > Stable This interface is guaranteed to exist in > all minor versions of FreeBSD corresponding with > the major version in which it exists. > > Once an interface is marked 'Stable' it must go > through the 'Deprecated' and 'Obsolete' stages > before removal. > > Deprecated The interface is supported, but is slated for > obsolecence in the next major release of > FreeBSD. > > Obsolete The interface is not supported. It may work, > but it is not guaranteed to. The interface will > be removed in the next major version of FreeBSD. > > Assuming, for the moment, that that makes sense to people, over what > sort > of timescales should interfaces move from state to state? > > And does the project have the will to guarantee this? > > [ "Guarantee"? OK, nothing's guaranteed in an open source project. > But > IMHO, there are a few things that the project should commit to. As > long as these things are appropriately documented, and decided upon > -- > committer vote? core declaration? -- unwillingness to commit to them > should be grounds for removal of a commit bit. > > Harsh, I know. But as I mention above, we don't have a Linus-like > figure to lay down the law. ] > > N > -- > FreeBSD: The Power to Serve http://www.freebsd.org/ > (__) > FreeBSD Documentation Project http://www.freebsd.org/docproj/ > \\\'',) > > \/ \ ^ > --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- > .\._/_) > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 18 18:40:14 2002 Delivered-To: freebsd-arch@freebsd.org Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by hub.freebsd.org (Postfix) with ESMTP id BDCE237B407; Tue, 18 Jun 2002 18:40:08 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc03.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020619014008.SZHN20219.sccrmhc03.attbi.com@InterJet.elischer.org>; Wed, 19 Jun 2002 01:40:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA22322; Tue, 18 Jun 2002 18:21:21 -0700 (PDT) Date: Tue, 18 Jun 2002 18:21:20 -0700 (PDT) From: Julian Elischer To: Garance A Drosihn Cc: Doug Barton , Nik Clayton , Sheldon Hearn , arch@FreeBSD.ORG Subject: Re: 4.x compatibilty.. Was: MFC of rcNG? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 18 Jun 2002, Garance A Drosihn wrote: > At 3:17 PM -0700 6/18/02, Doug Barton wrote: As I mentionned, my (employer's) bank clients are ultra concervative, but when we move to 5.x in late 2004 or 2005 they will be budgetting for such things as a new audit of teh configurations so switching for them then will be ok, but we sell 4.x upgrades as "bugfix releases" to the don't budget in such large items at those times.. As long as 4.x systems work the way they have and don't require changes that can't be handled automatically I'm happy. 5.x can be quite different as far as I'm concerned.. so.. "good job so far, and it looks like you have a good plan." being able to get tehm 'used to' the new system by having it in 4.8 as an option will be enormously useful too but I don't think we need the old system to be stil available in 5.x as long as /usr/local/etc/rc.d can still be used for 3rd party apps that can't easily be changed.. julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 18 19: 2:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 0EBCA37B40F; Tue, 18 Jun 2002 19:02:05 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.3/8.12.3) with ESMTP id g5J224DK051488; Tue, 18 Jun 2002 22:02:04 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.3/8.12.3/Submit) id g5J224qM051487; Tue, 18 Jun 2002 22:02:04 -0400 (EDT) (envelope-from wollman) Date: Tue, 18 Jun 2002 22:02:04 -0400 (EDT) From: Garrett Wollman Message-Id: <200206190202.g5J224qM051487@khavrinen.lcs.mit.edu> To: nik@FreeBSD.ORG Subject: Re: Timetables for interface deprecation/deletion In-Reply-To: <20020618225523.J52976@canyon.nothing-going-on.org> Organization: MIT Laboratory for Computer Science Cc: arch@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <20020618225523.J52976@canyon.nothing-going-on.org> you write: > Deprecated The interface is supported, but is slated for > obsolecence in the next major release of > FreeBSD. Any interface which is not documented is automatically in this state. >Assuming, for the moment, that that makes sense to people, over what sort >of timescales should interfaces move from state to state? I think that `major release' would be considered a reasonable milestone, as you have already effectively written into the definition. That is to say, an interface which is introduced in major release X.0 will persist throughout the lifecycle of X.*. An interface which is introduced in minor release X.Y (Y > 0) will persist throughout the lifecycle of (X+1).*. (This second statement is another way to say, ``new features appear in -current first''.) There is another lifecycle category which you didn't mention: Legacy This interface is supported for standards compliance or compatibility purposes only. This interface SHOULD NOT be used. If and when the standard is revised (or applications rewritten) to remove the requirement for this interface, it may be removed at any time and any point in the release cycle. -GAWollman -- Garrett A. Wollman | [G]enes make enzymes, and enzymes control the rates of wollman@lcs.mit.edu | chemical processes. Genes do not make ``novelty- Opinions not those of| seeking'' or any other complex and overt behavior. MIT, LCS, CRS, or NSA| - Stephen Jay Gould (1941-2002) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 18 19:53:33 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by hub.freebsd.org (Postfix) with ESMTP id DF3D237B40B; Tue, 18 Jun 2002 19:53:31 -0700 (PDT) Received: from pool0442.cvx22-bradley.dialup.earthlink.net ([209.179.199.187] helo=mindspring.com) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17KVb8-0006GX-00; Tue, 18 Jun 2002 19:53:30 -0700 Message-ID: <3D0FF201.862D015D@mindspring.com> Date: Tue, 18 Jun 2002 19:52:49 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nik Clayton Cc: arch@freebsd.org Subject: Re: Timetables for interface deprecation/deletion References: <20020618225523.J52976@canyon.nothing-going-on.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nik Clayton wrote: > [ It's times like this I regret the fact that we don't have a Linus > equivalent to lay down the law ] I think Kirk McKusick is well enough respected all around, and as an originator of much of what is today BSD, and a former member of CSRG, I think if he wanted to "lay down the law", that people would listen to him. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 18 22:32: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 646D637B40E; Tue, 18 Jun 2002 22:32:02 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.3/8.12.2) with ESMTP id g5J5UFIj005364; Wed, 19 Jun 2002 07:30:15 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Garrett Wollman Cc: nik@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: Timetables for interface deprecation/deletion In-Reply-To: Your message of "Tue, 18 Jun 2002 22:02:04 EDT." <200206190202.g5J224qM051487@khavrinen.lcs.mit.edu> Date: Wed, 19 Jun 2002 07:30:15 +0200 Message-ID: <5363.1024464615@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I've read the entire thread now. I'm sure this is well intended. But I am firmly against such a sweeping use of "red tape" as it will make forward progress practically impossible: KSE for instance would not be possible because it changes the API so that old ps(1) binaries do not work. I think we need make a considered judgement, per major release, about what is in, what is out and what stays for compatibility reasons, having rigid and inflexible rules on the subject is not helpful to anybody. This is the kind of rigid square policy-making which big companies need to apply because they dare not delegate "good judgement" to their development department. This does not belong in a for-fun Open Source project. I agree that we need to follow standards reasonably close, but we do not need to be backwards compatible over timespans of 5 years. -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 18 22:49:24 2002 Delivered-To: freebsd-arch@freebsd.org Received: from horsey.gshapiro.net (horsey.gshapiro.net [209.220.147.178]) by hub.freebsd.org (Postfix) with ESMTP id AC6E837B409; Tue, 18 Jun 2002 22:49:09 -0700 (PDT) Received: from horsey.gshapiro.net (gshapiro@localhost [IPv6:::1]) by horsey.gshapiro.net (8.12.4/8.12.4) with ESMTP id g5J5n8R7037078 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 18 Jun 2002 22:49:09 -0700 (PDT) Received: (from gshapiro@localhost) by horsey.gshapiro.net (8.12.4/8.12.4/Submit) id g5J5n8N1037075; Tue, 18 Jun 2002 22:49:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15632.6996.519381.823439@horsey.gshapiro.net> Date: Tue, 18 Jun 2002 22:49:08 -0700 From: Gregory Neil Shapiro To: Doug Barton Cc: "Jin Guojun[DSD]" , "Crist J. Clark" , Subject: Re: conf/39444: rc.sendmail syntax error: cannot disable sendmail In-Reply-To: <20020618155900.O2483-100000@master.gorean.org> References: <3D0FB406.83DE356D@lbl.gov> <20020618155900.O2483-100000@master.gorean.org> X-Mailer: VM 7.03 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >> sendmail does not need to run on background to send/submit outbound mail. >> The backgrounding daemon is solely for receiving inbound message. Yes, 8.12 does indeed require a daemon running listening on the localhost for outbound mail. That was the whole reason for NO vs NONE. DougB> The problem here is that historically sendmail_enable="NO" always meant DougB> "don't run a listener for incoming mail, but still let me send mail from DougB> this host." Yes, and that's what I tried to preserve. I didn't want to break existing sendmail_enable=NO configurations. If I had changed sendmail_enable=NO to start absolutely no daemons, locally submitted mail (e.g., mail, cron, lpd, etc) would sit in /var/spool/clientmqueue/ forever (regardless of whether it was to a local or remote user). That is unacceptable. DougB> What I think we need is a new knob, something like DougB> use_real_sendmail, that will default to YES, leaving the new status DougB> quo for sendmail_enable="NO" intact, but also be able to completely DougB> disable all sendmail stuff, including listeners for outgoing mail, DougB> queue runners, etc. That way users can have a clear indication of DougB> what's going to happen, and the same YES/NO syntax they are familiar DougB> with. If you don't want *any* sendmail daemon running, you can either use: sendmail_enable="NONE" or mta_start_script="" I don't see the problem with using one of these methods. They are both well documented in the 4.6 and 5.0 release notes, /usr/src/UPDATING, and the man pages. If we now add yet another method of doing this, it still doesn't solve the learning curve problem that people appear to be having with sendmail_enable="NONE" and will only add more confusion. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 18 23:10:38 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay1.yahoo.com (mail-relay1.yahoo.com [216.145.48.34]) by hub.freebsd.org (Postfix) with ESMTP id 1F98B37B405; Tue, 18 Jun 2002 23:10:35 -0700 (PDT) Received: from FreeBSD.org (socks1.yahoo.com [216.145.50.200]) by mail-relay1.yahoo.com (Postfix) with ESMTP id 844B68B5DE; Tue, 18 Jun 2002 23:10:34 -0700 (PDT) Message-ID: <3D102055.F08DD2AE@FreeBSD.org> Date: Tue, 18 Jun 2002 23:10:29 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.79 [en] (X11; U; FreeBSD 4.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gregory Neil Shapiro Cc: "Jin Guojun[DSD]" , "Crist J. Clark" , FreeBSD-arch@FreeBSD.ORG Subject: Re: conf/39444: rc.sendmail syntax error: cannot disable sendmail References: <3D0FB406.83DE356D@lbl.gov> <20020618155900.O2483-100000@master.gorean.org> <15632.6996.519381.823439@horsey.gshapiro.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Gregory Neil Shapiro wrote: > DougB> The problem here is that historically sendmail_enable="NO" always meant > DougB> "don't run a listener for incoming mail, but still let me send mail from > DougB> this host." > > Yes, and that's what I tried to preserve. I think you did a good job on that, don't get me wrong. > DougB> What I think we need is a new knob, something like > DougB> use_real_sendmail, that will default to YES, leaving the new status > DougB> quo for sendmail_enable="NO" intact, but also be able to completely > DougB> disable all sendmail stuff, including listeners for outgoing mail, > DougB> queue runners, etc. That way users can have a clear indication of > DougB> what's going to happen, and the same YES/NO syntax they are familiar > DougB> with. > > If you don't want *any* sendmail daemon running, you can either use: > > sendmail_enable="NONE" > > or > > mta_start_script="" > > I don't see the problem with using one of these methods. The problem is, the users are getting confused. Neither of the methods you describe is "standard," which is a big part of the confusion. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 18 23:24:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from horsey.gshapiro.net (horsey.gshapiro.net [209.220.147.178]) by hub.freebsd.org (Postfix) with ESMTP id C656C37B410; Tue, 18 Jun 2002 23:24:44 -0700 (PDT) Received: from horsey.gshapiro.net (gshapiro@localhost [IPv6:::1]) by horsey.gshapiro.net (8.12.4/8.12.4) with ESMTP id g5J6OhR7037309 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 18 Jun 2002 23:24:43 -0700 (PDT) Received: (from gshapiro@localhost) by horsey.gshapiro.net (8.12.4/8.12.4/Submit) id g5J6Ohes037306; Tue, 18 Jun 2002 23:24:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15632.9131.365021.260177@horsey.gshapiro.net> Date: Tue, 18 Jun 2002 23:24:43 -0700 From: Gregory Neil Shapiro To: Doug Barton Cc: "Jin Guojun[DSD]" , "Crist J. Clark" , FreeBSD-arch@FreeBSD.org Subject: Re: conf/39444: rc.sendmail syntax error: cannot disable sendmail In-Reply-To: <3D102055.F08DD2AE@FreeBSD.org> References: <3D0FB406.83DE356D@lbl.gov> <20020618155900.O2483-100000@master.gorean.org> <15632.6996.519381.823439@horsey.gshapiro.net> <3D102055.F08DD2AE@FreeBSD.org> X-Mailer: VM 7.03 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG DougB> The problem is, the users are getting confused. Neither of the methods DougB> you describe is "standard," which is a big part of the confusion. I guess the standard way would be: sendmail_enable=NO sendmail_submit_enable=NO sendmail_outbound_enable=NO sendmail_msp_queue_enable=NO This is (and was) always available. sendmail_enable=NONE is just a shortcut that has the same effect as setting all four to NO. With that in mind, the only other thing that could be added is a sendmail_dont_run_at_all variable that, if set to YES, is exactly the same as: 1. sendmail_enable=NONE, or 2. mta_start_script="", or 3. sendmail_enable=NO sendmail_submit_enable=NO sendmail_outbound_enable=NO sendmail_msp_queue_enable=NO My preference is not to add a fourth equivalent method to the above list. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 18 23:52:16 2002 Delivered-To: freebsd-arch@freebsd.org Received: from nothing-going-on.demon.co.uk (pc-62-31-42-140-hy.blueyonder.co.uk [62.31.42.140]) by hub.freebsd.org (Postfix) with ESMTP id 0D60737B407; Tue, 18 Jun 2002 23:52:11 -0700 (PDT) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.11.3/8.11.3) id g5IMRqe75515; Tue, 18 Jun 2002 23:27:52 +0100 (BST) (envelope-from nik) Date: Tue, 18 Jun 2002 23:27:51 +0100 From: Nik Clayton To: Doug Barton Cc: Nik Clayton , Sheldon Hearn , Trish Lynch , arch@freebsd.org Subject: Re: 4.x compatibilty.. Was: MFC of rcNG? Message-ID: <20020618232751.K52976@canyon.nothing-going-on.org> References: <20681.1024423602@axl.seasidesoftware.co.za> <3D0F7AAA.110E0D8@FreeBSD.org> <20020618224029.I52976@canyon.nothing-going-on.org> <3D0FB17F.6F8B5819@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="72k7VsmfIboquFwl" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D0FB17F.6F8B5819@FreeBSD.org>; from DougB@FreeBSD.org on Tue, Jun 18, 2002 at 03:17:35PM -0700 Organization: FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --72k7VsmfIboquFwl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 18, 2002 at 03:17:35PM -0700, Doug Barton wrote: > But (and I may be biased here) I think it's all curving in the > right direction.=20 As do I. 5.x is going to kick ass. But the more painful we make the migration process, the fewer people who will migrate. N --=20 FreeBSD: The Power to Serve http://www.freebsd.org/ (__) FreeBSD Documentation Project http://www.freebsd.org/docproj/ \\\'',) \/ \= ^ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- .\._/= _) --72k7VsmfIboquFwl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9D7Pnk6gHZCw343URAsK+AJ453pyYl1uyP8Pa+SYZtRA/FLBjkACeKRFi fScyd93hMGyleP+9teSWrQY= =5gEJ -----END PGP SIGNATURE----- --72k7VsmfIboquFwl-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 19 0:26:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay1.yahoo.com (mail-relay1.yahoo.com [216.145.48.34]) by hub.freebsd.org (Postfix) with ESMTP id 6358037B40C; Wed, 19 Jun 2002 00:26:32 -0700 (PDT) Received: from FreeBSD.org (socks1.yahoo.com [216.145.50.200]) by mail-relay1.yahoo.com (Postfix) with ESMTP id 863A18B5E5; Wed, 19 Jun 2002 00:26:31 -0700 (PDT) Message-ID: <3D10321E.BB58CBC@FreeBSD.org> Date: Wed, 19 Jun 2002 00:26:22 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.79 [en] (X11; U; FreeBSD 4.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gregory Neil Shapiro Cc: "Jin Guojun[DSD]" , "Crist J. Clark" , FreeBSD-arch@FreeBSD.org Subject: Re: conf/39444: rc.sendmail syntax error: cannot disable sendmail References: <3D0FB406.83DE356D@lbl.gov> <20020618155900.O2483-100000@master.gorean.org> <15632.6996.519381.823439@horsey.gshapiro.net> <3D102055.F08DD2AE@FreeBSD.org> <15632.9131.365021.260177@horsey.gshapiro.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Gregory Neil Shapiro wrote: > sendmail_enable=NONE is just a > shortcut that has the same effect as setting all four to NO. With that in > mind, the only other thing that could be added is a > sendmail_dont_run_at_all variable that, if set to YES, is exactly the same > as: > > 1. sendmail_enable=NONE, or > 2. mta_start_script="", or > 3. sendmail_enable=NO > sendmail_submit_enable=NO > sendmail_outbound_enable=NO > sendmail_msp_queue_enable=NO > > My preference is not to add a fourth equivalent method to the above list. Well, I was thinking of doing it the positive way, so my suggestion was use_real_sendmail="YES", but either way is fine with me. I do think this is needed, but I'd like to hear from others before we make a decision. -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 19 0:52:48 2002 Delivered-To: freebsd-arch@freebsd.org Received: from adsl-63-198-35-122.dsl.snfc21.pacbell.net (adsl-63-198-35-122.dsl.snfc21.pacbell.net [63.198.35.122]) by hub.freebsd.org (Postfix) with ESMTP id 34E7037B404; Wed, 19 Jun 2002 00:52:35 -0700 (PDT) Received: from lbl.gov (localhost [127.0.0.1]) by adsl-63-198-35-122.dsl.snfc21.pacbell.net (8.11.6/8.11.6) with ESMTP id g5J7rJc00589; Wed, 19 Jun 2002 00:53:19 -0700 (PDT) (envelope-from j_guojun@lbl.gov) Message-ID: <3D10386F.BD245FCA@lbl.gov> Date: Wed, 19 Jun 2002 00:53:19 -0700 From: "Jin Guojun[DSD]" X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.5-RELEASE i386) X-Accept-Language: zh, zh-CN, en MIME-Version: 1.0 To: Gregory Neil Shapiro Cc: Doug Barton , "Crist J. Clark" , FreeBSD-arch@FreeBSD.org Subject: Re: conf/39444: rc.sendmail syntax error: cannot disable sendmail References: <3D0FB406.83DE356D@lbl.gov> <20020618155900.O2483-100000@master.gorean.org> <15632.6996.519381.823439@horsey.gshapiro.net> <3D102055.F08DD2AE@FreeBSD.org> <15632.9131.365021.260177@horsey.gshapiro.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Gregory Neil Shapiro wrote: > > DougB> The problem is, the users are getting confused. Neither of the methods > DougB> you describe is "standard," which is a big part of the confusion. > > I guess the standard way would be: > > sendmail_enable=NO > sendmail_submit_enable=NO > sendmail_outbound_enable=NO > sendmail_msp_queue_enable=NO > > This is (and was) always available. sendmail_enable=NONE is just a > shortcut that has the same effect as setting all four to NO. With that in > mind, the only other thing that could be added is a > sendmail_dont_run_at_all variable that, if set to YES, is exactly the same > as: > > 1. sendmail_enable=NONE, or > 2. mta_start_script="", or > 3. sendmail_enable=NO > sendmail_submit_enable=NO > sendmail_outbound_enable=NO > sendmail_msp_queue_enable=NO > > My preference is not to add a fourth equivalent method to the above list. There is no need for another method to do above. Issues are: (1) NONE is used only here, so it is not a "standard" syntax for general purpose. It is not clear if it means sendmail_enable=NO in old system or not. So, above information with some further explanation need to be put into /etc/mail/README and/or in man/rc.sendmail. It is confusing. (2) From /etc/mail/README, running a daemon to accept localhost is needed for outbound traffic. If sendmail_submit_enable=NO and sendmail_enable=NO, then outbound mail will silently sinks. This needs to be clearly stated in some place easy to see because this is new. For another security reason, from old system, users may kill the sendmail accepting messages if they are not aware this new feature. Most argument here is that "How can I trust something is not suppose to run?" Under new system, after they kill the sendmail daemon, all outgoing mail will lost without any warning, and users may take long time to find out no mail was sent due to this issue. Changing things in email system will significantly affect current computing environment, so we need to be careful when doing so. -- ------------ Jin Guojun ----------- v --- j_guojun@lbl.gov --- Distributed Systems Department http://www.itg.lbl.gov/~jin M/S 50B-2239 Ph#:(510) 486-7531 Fax: 486-6363 Lawrence Berkeley National Laboratory, Berkeley, CA 94720 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 19 3:10:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by hub.freebsd.org (Postfix) with ESMTP id D399237B407 for ; Wed, 19 Jun 2002 03:10:16 -0700 (PDT) Received: from kokeb.ambesa.net ([64.166.84.56]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GXY00JV96X48Q@mta6.snfc21.pbi.net> for freebsd-arch@freebsd.org; Wed, 19 Jun 2002 03:10:16 -0700 (PDT) Received: from kokeb.ambesa.net (tanstaafl@localhost [127.0.0.1]) by kokeb.ambesa.net (8.12.3/8.12.3) with ESMTP id g5JAFXeU013621 for ; Wed, 19 Jun 2002 03:15:33 -0700 (PDT envelope-from mikem@kokeb.ambesa.net) Received: (from mikem@localhost) by kokeb.ambesa.net (8.12.3/8.12.3/Submit) id g5JAFXt8013620; Wed, 19 Jun 2002 03:15:33 -0700 (PDT envelope-from mikem) Date: Wed, 19 Jun 2002 03:15:33 -0700 From: Mike Makonnen Subject: Configuration management To: freebsd-arch@freebsd.org Message-id: <20020619031533.2c302e68.makonnen@pacbell.net> MIME-version: 1.0 X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i386--freebsd5.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, From time to time, I've seen threads on various mailing-lists about creating a gui tool for configuring the system (basically /etc/rc.conf). The assumption is that providing some sort of point-and-click interface will make it easier to configure FreeBSD. The problem with this, among other things, is that it requires developer buy-in because the configuration tool has to be updated everytime a new knob is added, which makes it more tedious and error prone for the developer. I am of a different opinion. I happen to like plain-text configuration files. The problem is not that we need an easier way to _edit_ the files, but rather we need a better way to manage all those files and the changes we make to them. For example, I have a haphazard collection of rcs files for files I have edited in /etc. Most times I do co/ci when I edit them but sometimes I'm in a hurry and I don't bother or I just plain forget. Not all the files are in rcs. I don't have a standard tagging scheme. I also don't generally tag them all before or after a mergemaster. However, I believe these things should be done for all my files on a consistent basis, but I'm generally too lazy and don't bother :-( so an automated system that did all these things for me would be nice. I also have a love-hate relationship with mergemaster (no offense, Doug 8-) and would much rather have a completely automated way of updating my configuration files after an installworld that would easily allow me to back out a certain change if it b0rked my system. To address this, I would like to develop a set of scripts, for inclusion in the base system, that manage the files in /etc as a set of rcs files. It would not introduce any changes to the files themselves, but it would allow the creation of a separate repository to handle versioning and a set of wrapper scripts for editing and updating the actual configuration files. For example, an admin would be able to do the following things: - create a configuration repository from the files in /etc (or any other directory, for that matter) - add a file to the repository - add a pre-existing rcs file to the repository - edit the file through a wrapper script that checks out the file from the configuration repo, starts and editor, and checks-in the modified version before saving it to etc. - tag the current versions of files in /etc - revert all/some of the files to a previous revision/tag I would also like to then add optional support for this in mergemaster so that it can do something like: - notice that the repository does not contain the latest version of a file in /etc - update the repository - tag the current version of the files in use in etc with a pre-mm tag - update /etc as usual - add any new files to the repository This way if you screwed up the mergemaster you could get back the same exact files you had before the update and retry. An additional benefit is that when you backup your machine you will have a complete history of all changes made, all apropriately tagged, by you by the FreeBSD project. In short, I want to make it easier for people to manage their FreeBSD system by automating those tasks that a good sysadmin should do, but that most of us don't have the time or discipline to do, without in any way impacting those who already have a configuration versioning scheme that works for them and without moving away from text configuration files. Comments? Cheers, Mike Makonnen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 19 4:25:14 2002 Delivered-To: freebsd-arch@freebsd.org Received: from tara.freenix.org (keltia.freenix.org [62.4.20.87]) by hub.freebsd.org (Postfix) with ESMTP id D52AB37B40C for ; Wed, 19 Jun 2002 04:25:10 -0700 (PDT) Received: by tara.freenix.org (Postfix/TLS, from userid 101) id B0BDF2A8F; Wed, 19 Jun 2002 13:25:09 +0200 (CEST) Date: Wed, 19 Jun 2002 13:25:09 +0200 From: Ollivier Robert To: FreeBSD-arch@FreeBSD.org Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? Message-ID: <20020619112509.GA23487@tara.freenix.org> Mail-Followup-To: FreeBSD-arch@FreeBSD.org References: <3CF3DAFB.7C9C5108@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.99i X-Operating-System: FreeBSD 5.0-CURRENT K6-3D/266 & 2x PIII/800 SMP Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG According to Antoine Beaupre: > Ideally, /usr/local should go away. Packages should install in /usr by > default. But the ports system would need a bigger fence around it to > expose /usr this way, IMHO. If you're advocating something like the FHS used on Linux (which put things like gnome and the kitchen-sink in /usr/bin), then forget it. I don't want FreeBSD become another Debian-like monster. The FHS way complicates life far too much, forces one to have a far too big /usr and is a PITA to deal with. Been there, Done that. Got the scars even. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 19 4:41: 2 2002 Delivered-To: freebsd-arch@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id E0F4937B408 for ; Wed, 19 Jun 2002 04:40:38 -0700 (PDT) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.36 #1) id 17Kdps-0006U0-00; Wed, 19 Jun 2002 13:41:16 +0200 From: Sheldon Hearn To: Mike Makonnen Cc: freebsd-arch@freebsd.org Subject: Re: Configuration management In-reply-to: Your message of "Wed, 19 Jun 2002 03:15:33 MST." <20020619031533.2c302e68.makonnen@pacbell.net> Date: Wed, 19 Jun 2002 13:41:16 +0200 Message-ID: <24923.1024486876@axl.seasidesoftware.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 19 Jun 2002 03:15:33 MST, Mike Makonnen wrote: > In short, I want to make it easier for people to manage their FreeBSD system > by automating those tasks that a good sysadmin should do, but that most of > us don't have the time or discipline to do, without in any way impacting those > who already have a configuration versioning scheme that works for them and > without moving away from text configuration files. > > Comments? I'd certainly try out a prototype solution if it were committed to the ports tree. I have a feeling that I want what you're proposing, but I don't think anyone can really make a call on this until they've seen it in action. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 19 5:56:44 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.nsu.ru (mx.nsu.ru [193.124.215.71]) by hub.freebsd.org (Postfix) with ESMTP id 58A2837B408 for ; Wed, 19 Jun 2002 05:56:38 -0700 (PDT) Received: from drweb by mail.nsu.ru with drweb-scanned (Exim 3.20 #1) id 17Kf0H-0007BT-00; Wed, 19 Jun 2002 19:56:05 +0700 Received: from regency.nsu.ru ([193.124.210.26]) by mail.nsu.ru with esmtp (Exim 3.20 #1) id 17Kf0G-0007Ai-00; Wed, 19 Jun 2002 19:56:04 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.12.3/8.12.3) with ESMTP id g5JCuUcp086170; Wed, 19 Jun 2002 19:56:30 +0700 (NOVST) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.12.3/8.12.3/Submit) id g5JCuUsr086137; Wed, 19 Jun 2002 19:56:30 +0700 (NOVST) Date: Wed, 19 Jun 2002 19:56:29 +0700 From: Alexey Dokuchaev To: Ollivier Robert Cc: FreeBSD-arch@freebsd.org Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? Message-ID: <20020619195629.B71807@regency.nsu.ru> References: <3CF3DAFB.7C9C5108@mindspring.com> <20020619112509.GA23487@tara.freenix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020619112509.GA23487@tara.freenix.org>; from roberto@keltia.freenix.fr on Wed, Jun 19, 2002 at 01:25:09PM +0200 X-Envelope-To: roberto@keltia.freenix.fr, FreeBSD-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Jun 19, 2002 at 01:25:09PM +0200, Ollivier Robert wrote: > According to Antoine Beaupre: > > Ideally, /usr/local should go away. Packages should install in /usr by > > default. But the ports system would need a bigger fence around it to > > expose /usr this way, IMHO. > > If you're advocating something like the FHS used on Linux (which put things > like gnome and the kitchen-sink in /usr/bin), then forget it. I don't want > FreeBSD become another Debian-like monster. Very true. The idea of ports separated from the base is a lot of help when dealing with system upgrade/backup/wipe-out. Heck, I could have simply "rm -rf /usr/local" and get rid of all non-X11 ports I have ;-) And still get the box running. 3-rd party should go in /usr/local (OK, X11 goes in /usr/X11R6), thus leaving /usr populated by the base only. Period. ./danfe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 19 6:27:49 2002 Delivered-To: freebsd-arch@freebsd.org Received: from thuvia.demon.co.uk (thuvia.demon.co.uk [193.237.34.248]) by hub.freebsd.org (Postfix) with ESMTP id 5DE0C37B404 for ; Wed, 19 Jun 2002 06:27:41 -0700 (PDT) Received: from dotar.thuvia.org (dotar.thuvia.org [10.0.0.4]) by phaidor.thuvia.org (8.11.6/8.11.6) with ESMTP id g5JDQnN67446; Wed, 19 Jun 2002 14:26:49 +0100 (BST) (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (localhost [IPv6:::1]) by dotar.thuvia.org (8.12.3/8.12.3) with ESMTP id g5JDQmCs039571; Wed, 19 Jun 2002 14:26:48 +0100 (BST) (envelope-from mark@dotar.thuvia.org) Received: (from mark@localhost) by dotar.thuvia.org (8.12.3/8.12.3/Submit) id g5JDQmAo039570; Wed, 19 Jun 2002 14:26:48 +0100 (BST) Date: Wed, 19 Jun 2002 14:26:48 +0100 (BST) From: Mark Valentine Message-Id: <200206191326.g5JDQmAo039570@dotar.thuvia.org> In-Reply-To: Alexey Dokuchaev's message of Jun 19, 1:04pm X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: danfe@regency.nsu.ru (Alexey Dokuchaev), Ollivier Robert Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? Cc: FreeBSD-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > From: danfe@regency.nsu.ru (Alexey Dokuchaev) > Date: Wed 19 Jun, 2002 > Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? > The idea of ports separated from the base is a lot of help > when dealing with system upgrade/backup/wipe-out. Heck, I could have > simply "rm -rf /usr/local" and get rid of all non-X11 ports I have ;-) > And still get the box running. Yes, that separation is invaluable. > 3-rd party should go in /usr/local (OK, X11 goes in /usr/X11R6), thus > leaving /usr populated by the base only. Period. Except that /usr/local is the wrong place for FreeBSD's binary packages, since they are quite likely to conflict with *local* policy. For two decades my /usr/local has followed a uniform cross-platform policy with an established structure and administration regime, and it's simply not possible to install a typical FreeBSD package non-destructively. I certainly hope that a next generation ports system uses a different default location: /opt, /usr/pkg, or whatever, but leave /usr/local to *local* policy. I even have to patch /usr/local out of BSD.usr.dist here (I raised that flag a long time ago in PR misc/355). Mark. -- Mark Valentine, Thuvia Labs "Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses "We're kind of stupid that way." *munch* *munch* and endorses FreeBSD -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 19 10:27:42 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.gnf.org (ns1.gnf.org [63.196.132.67]) by hub.freebsd.org (Postfix) with ESMTP id 2D35E37B40F for ; Wed, 19 Jun 2002 10:27:36 -0700 (PDT) Received: from mail.gnf.org (smtp.gnf.org [172.25.11.11]) by ns1.gnf.org (8.11.6/8.11.6) with ESMTP id g5JHRXX15269 for ; Wed, 19 Jun 2002 10:27:33 -0700 (PDT) (envelope-from gordont@gnf.org) Received: by mail.gnf.org (Postfix, from userid 888) id 0652B11E515; Wed, 19 Jun 2002 10:27:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.gnf.org (Postfix) with ESMTP id 0559811A572 for ; Wed, 19 Jun 2002 10:27:36 -0700 (PDT) Date: Wed, 19 Jun 2002 10:27:36 -0700 (PDT) From: Gordon Tetlow To: arch@FreeBSD.org Subject: MFC of src/etc/rc.subr Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I'm going to MFC src/etc/rc.subr into -STABLE probably tomorrow unless someone has some grevious reason that it shouldn't. -gordon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 19 10:30:46 2002 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id AFCFA37B40F for ; Wed, 19 Jun 2002 10:30:14 -0700 (PDT) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.3/8.12.2) with ESMTP id g5JHUEP8041579; Wed, 19 Jun 2002 10:30:14 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.4/8.12.3/Submit) id g5JHUC3i041578; Wed, 19 Jun 2002 10:30:12 -0700 (PDT) Date: Wed, 19 Jun 2002 10:30:12 -0700 From: "David O'Brien" To: Mark Valentine Cc: Alexey Dokuchaev , Ollivier Robert , FreeBSD-arch@freebsd.org Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? Message-ID: <20020619103012.A41546@dragon.nuxi.com> Reply-To: FreeBSD-arch@freebsd.org References: <200206191326.g5JDQmAo039570@dotar.thuvia.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200206191326.g5JDQmAo039570@dotar.thuvia.org>; from mark@thuvia.demon.co.uk on Wed, Jun 19, 2002 at 02:26:48PM +0100 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Jun 19, 2002 at 02:26:48PM +0100, Mark Valentine wrote: > I even have to patch /usr/local out of BSD.usr.dist here (I raised that flag > a long time ago in PR misc/355). What is wrong with local/ in BSD.usr.dist? All it does is create the directory tree, which it sounds like you want anyway. BSD.usr.dist does not determine where ports are installed. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 19 10:37: 7 2002 Delivered-To: freebsd-arch@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 68BC637B406 for ; Wed, 19 Jun 2002 10:37:03 -0700 (PDT) Received: from sheldonh by axl.seasidesoftware.co.za with local (Exim 3.36 #1) id 17KjOl-0000w5-00; Wed, 19 Jun 2002 19:37:39 +0200 Date: Wed, 19 Jun 2002 19:37:39 +0200 From: Sheldon Hearn To: Gordon Tetlow Cc: arch@FreeBSD.org Subject: Re: MFC of src/etc/rc.subr Message-ID: <20020619173739.GA971@starjuice.net> Mail-Followup-To: Gordon Tetlow , arch@FreeBSD.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On (2002/06/19 10:27), Gordon Tetlow wrote: > I'm going to MFC src/etc/rc.subr into -STABLE probably tomorrow unless > someone has some grevious reason that it shouldn't. Please either strip out the named_rcng stuff or wait until it works. That part of the work is not really RELENG_4-quality yet. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 19 10:41:11 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.gnf.org (ns1.gnf.org [63.196.132.67]) by hub.freebsd.org (Postfix) with ESMTP id EF42537B400 for ; Wed, 19 Jun 2002 10:41:07 -0700 (PDT) Received: from mail.gnf.org (smtp.gnf.org [172.25.11.11]) by ns1.gnf.org (8.11.6/8.11.6) with ESMTP id g5JHf5X15369; Wed, 19 Jun 2002 10:41:05 -0700 (PDT) (envelope-from gordon@FreeBSD.org) Received: by mail.gnf.org (Postfix, from userid 888) id B4AD611E515; Wed, 19 Jun 2002 10:41:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.gnf.org (Postfix) with ESMTP id B3AA211A572; Wed, 19 Jun 2002 10:41:07 -0700 (PDT) Date: Wed, 19 Jun 2002 10:41:07 -0700 (PDT) From: Gordon Tetlow X-X-Sender: gordont@smtp.gnf.org To: Sheldon Hearn Cc: arch@FreeBSD.org Subject: Re: MFC of src/etc/rc.subr In-Reply-To: <20020619173739.GA971@starjuice.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 19 Jun 2002, Sheldon Hearn wrote: > On (2002/06/19 10:27), Gordon Tetlow wrote: > > > I'm going to MFC src/etc/rc.subr into -STABLE probably tomorrow unless > > someone has some grevious reason that it shouldn't. > > Please either strip out the named_rcng stuff or wait until it works. > That part of the work is not really RELENG_4-quality yet. I'm only MFC'ing one file src/etc/rc.subr. Not the whole shebang. This is going to be used in case someone is demented enough to write a port that uses the rc.subr stuff. No one should use it for quite a while, but the support needs to be in place for people to use it. -gordon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 19 10:45: 2 2002 Delivered-To: freebsd-arch@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id CA93037B409; Wed, 19 Jun 2002 10:44:56 -0700 (PDT) Received: from sheldonh by axl.seasidesoftware.co.za with local (Exim 3.36 #1) id 17KjWa-0001Es-00; Wed, 19 Jun 2002 19:45:44 +0200 Date: Wed, 19 Jun 2002 19:45:44 +0200 From: Sheldon Hearn To: Gordon Tetlow Cc: arch@FreeBSD.org Subject: Re: MFC of src/etc/rc.subr Message-ID: <20020619174544.GA4542@starjuice.net> Mail-Followup-To: Gordon Tetlow , arch@FreeBSD.org References: <20020619173739.GA971@starjuice.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On (2002/06/19 10:41), Gordon Tetlow wrote: > > > I'm going to MFC src/etc/rc.subr into -STABLE probably tomorrow unless > > > someone has some grevious reason that it shouldn't. > > > > Please either strip out the named_rcng stuff or wait until it works. > > That part of the work is not really RELENG_4-quality yet. > > I'm only MFC'ing one file src/etc/rc.subr. Not the whole shebang. This is > going to be used in case someone is demented enough to write a port that > uses the rc.subr stuff. No one should use it for quite a while, but the > support needs to be in place for people to use it. You did actually say that the first time. *blush* Sorry. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 19 10:49:18 2002 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 26A7237B414; Wed, 19 Jun 2002 10:49:13 -0700 (PDT) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.3/8.12.2) with ESMTP id g5JHnCP8042063; Wed, 19 Jun 2002 10:49:12 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.4/8.12.3/Submit) id g5JHnCPW042062; Wed, 19 Jun 2002 10:49:12 -0700 (PDT) Date: Wed, 19 Jun 2002 10:49:12 -0700 From: "David O'Brien" To: Gregory Neil Shapiro Cc: Doug Barton , "Jin Guojun[DSD]" , "Crist J. Clark" , FreeBSD-arch@FreeBSD.org Subject: Re: conf/39444: rc.sendmail syntax error: cannot disable sendmail Message-ID: <20020619104912.B41546@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org References: <3D0FB406.83DE356D@lbl.gov> <20020618155900.O2483-100000@master.gorean.org> <15632.6996.519381.823439@horsey.gshapiro.net> <3D102055.F08DD2AE@FreeBSD.org> <15632.9131.365021.260177@horsey.gshapiro.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15632.9131.365021.260177@horsey.gshapiro.net>; from gshapiro@FreeBSD.org on Tue, Jun 18, 2002 at 11:24:43PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Jun 18, 2002 at 11:24:43PM -0700, Gregory Neil Shapiro wrote: > DougB> The problem is, the users are getting confused. Neither of the methods > DougB> you describe is "standard," which is a big part of the confusion. > > I guess the standard way would be: > > sendmail_enable=NO > sendmail_submit_enable=NO > sendmail_outbound_enable=NO > sendmail_msp_queue_enable=NO Yes. Since you fully support this, I don't understand what the issue is. People have old configurations that want "sendmail_enable=NO" to equal the above? Too bad, there are many configuration changes to learn when going from -stable to -current. So they will just have to learn there is more granularity now. > This is (and was) always available. sendmail_enable=NONE is just a > shortcut that has the same effect as setting all four to NO. This is non-standard. In fact I would really like us to use the NetBSD way of testing the knobs such that any "negative" setting means no. "NONE" would break with this. Thus my voiced support is "do nothing" (other than maybe remove the NONE support). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 19 10:54: 2 2002 Delivered-To: freebsd-arch@freebsd.org Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by hub.freebsd.org (Postfix) with ESMTP id E361037B407; Wed, 19 Jun 2002 10:53:56 -0700 (PDT) Received: from blossom.cjclark.org ([12.234.91.48]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020619175356.EKBQ1024.sccrmhc01.attbi.com@blossom.cjclark.org>; Wed, 19 Jun 2002 17:53:56 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.3/8.12.3) with ESMTP id g5JHrtJK021887; Wed, 19 Jun 2002 10:53:55 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.3/8.12.3/Submit) id g5JHrtjl021886; Wed, 19 Jun 2002 10:53:55 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Wed, 19 Jun 2002 10:53:55 -0700 From: "Crist J. Clark" To: "Jin Guojun[DSD]" Cc: Gregory Neil Shapiro , Doug Barton , FreeBSD-arch@FreeBSD.org Subject: Re: conf/39444: rc.sendmail syntax error: cannot disable sendmail Message-ID: <20020619105355.B21469@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <3D0FB406.83DE356D@lbl.gov> <20020618155900.O2483-100000@master.gorean.org> <15632.6996.519381.823439@horsey.gshapiro.net> <3D102055.F08DD2AE@FreeBSD.org> <15632.9131.365021.260177@horsey.gshapiro.net> <3D10386F.BD245FCA@lbl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D10386F.BD245FCA@lbl.gov>; from j_guojun@lbl.gov on Wed, Jun 19, 2002 at 12:53:19AM -0700 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Jun 19, 2002 at 12:53:19AM -0700, Jin Guojun[DSD] wrote: [snip] > There is no need for another method to do above. Issues are: > > (1) NONE is used only here, so it is not a "standard" syntax for general > purpose. It is not clear if it means sendmail_enable=NO in old system or > not. So, above information with some further explanation need to be put > into /etc/mail/README and/or in man/rc.sendmail. > It is confusing. From the 4.6 Release Notes, With this sendmail upgrade, multiple sendmail daemons (some required to handle outgoing mail) are started by rc(8), even if the sendmail_enable variable is set to NO. To completely disable sendmail, sendmail_enable must be set to NONE. Alternatively, for systems using a different MTA, the mta_start_script variable can be used to point to a different startup script (more details can be found in rc.sendmail(8)). The "NONE" has already been discussed to _death_ on -current and -stable. See, http://www.freebsd.org/cgi/getmsg.cgi?fetch=257186+261471+/usr/local/www/db/text/2002/freebsd-current/20020331.freebsd-current This and the other changes to sendmail(8) are documented in the release notes, /etc/mail/README, /usr/src/UPDATING, and /usr/src/contrib/sendmail/RELEASE_NOTES. If people don't find the information in one of these places, putting it in yet another location probably will not help. > (2) From /etc/mail/README, running a daemon to accept localhost is needed > for outbound traffic. If sendmail_submit_enable=NO and sendmail_enable=NO, > then outbound mail will silently sinks. This needs to be clearly stated > in some place easy to see because this is new. It's in the release notes (as quoted above) and /usr/src/UPDATING points to /etc/mail/README. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 19 11: 0:42 2002 Delivered-To: freebsd-arch@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 4FD1637B403; Wed, 19 Jun 2002 11:00:34 -0700 (PDT) Received: from sheldonh by axl.seasidesoftware.co.za with local (Exim 3.36 #1) id 17Kjlh-0001Xc-00; Wed, 19 Jun 2002 20:01:21 +0200 Date: Wed, 19 Jun 2002 20:01:21 +0200 From: Sheldon Hearn To: David O'Brien Cc: Gregory Neil Shapiro , Doug Barton , "Jin Guojun[DSD]" , "Crist J. Clark" , FreeBSD-arch@FreeBSD.org Subject: Re: conf/39444: rc.sendmail syntax error: cannot disable sendmail Message-ID: <20020619180121.GA5897@starjuice.net> Mail-Followup-To: David O'Brien , Gregory Neil Shapiro , Doug Barton , "Jin Guojun[DSD]" , "Crist J. Clark" , FreeBSD-arch@FreeBSD.org References: <3D0FB406.83DE356D@lbl.gov> <20020618155900.O2483-100000@master.gorean.org> <15632.6996.519381.823439@horsey.gshapiro.net> <3D102055.F08DD2AE@FreeBSD.org> <15632.9131.365021.260177@horsey.gshapiro.net> <20020619104912.B41546@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020619104912.B41546@dragon.nuxi.com> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On (2002/06/19 10:49), David O'Brien wrote: > > sendmail_enable=NO > > sendmail_submit_enable=NO > > sendmail_outbound_enable=NO > > sendmail_msp_queue_enable=NO > > Yes. Since you fully support this, I don't understand what the issue is. > People have old configurations that want "sendmail_enable=NO" to equal > the above? Too bad, there are many configuration changes to learn when > going from -stable to -current. So they will just have to learn there is > more granularity now. Ah, but the problem is that submit_enable, outbound_enable and msp_queue_enable were new additions on the RELENG_4 branch, so the user expectations of interest are those of users tracking -STABLE, not those upgrading from -STABLE to -CURRENT. From the beginning, this whole thing has been about a POLA violation on the -STABLE branch. That said, what's done is done, and it's unlikely that any further changes are going to improve the situation. Ciao, Sheldon. -- Sheldon Hearn Postmaster - Gambling.com In systems administration, a change is NOT as good as a holiday! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 19 11: 3:30 2002 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 43C3F37B40B; Wed, 19 Jun 2002 11:03:27 -0700 (PDT) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.3/8.12.2) with ESMTP id g5JI3QP8042372; Wed, 19 Jun 2002 11:03:26 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.4/8.12.3/Submit) id g5JI3QFP042371; Wed, 19 Jun 2002 11:03:26 -0700 (PDT) Date: Wed, 19 Jun 2002 11:03:26 -0700 From: "David O'Brien" To: Gregory Neil Shapiro , Doug Barton , "Jin Guojun[DSD]" , "Crist J. Clark" , FreeBSD-arch@FreeBSD.org Subject: Re: conf/39444: rc.sendmail syntax error: cannot disable sendmail Message-ID: <20020619110326.C42106@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org References: <3D0FB406.83DE356D@lbl.gov> <20020618155900.O2483-100000@master.gorean.org> <15632.6996.519381.823439@horsey.gshapiro.net> <3D102055.F08DD2AE@FreeBSD.org> <15632.9131.365021.260177@horsey.gshapiro.net> <20020619104912.B41546@dragon.nuxi.com> <20020619180121.GA5897@starjuice.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020619180121.GA5897@starjuice.net>; from sheldonh@starjuice.net on Wed, Jun 19, 2002 at 08:01:21PM +0200 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Jun 19, 2002 at 08:01:21PM +0200, Sheldon Hearn wrote: > Ah, but the problem is that submit_enable, outbound_enable and > msp_queue_enable were new additions on the RELENG_4 branch, so the user > expectations of interest are those of users tracking -STABLE, not those > upgrading from -STABLE to -CURRENT. I suspected that was the real issue, but hadn't seen it explicitly stated in this thread. It sounds then, that this is purely a -stable issue (not sure -arch is the place for it then). > >From the beginning, this whole thing has been about a POLA violation on > the -STABLE branch. > > That said, what's done is done, and it's unlikely that any further > changes are going to improve the situation. Probably true. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 19 11: 6:40 2002 Delivered-To: freebsd-arch@freebsd.org Received: from horsey.gshapiro.net (horsey.gshapiro.net [209.220.147.178]) by hub.freebsd.org (Postfix) with ESMTP id 5817037B40B for ; Wed, 19 Jun 2002 11:06:36 -0700 (PDT) Received: from horsey.gshapiro.net (gshapiro@localhost [IPv6:::1]) by horsey.gshapiro.net (8.12.4/8.12.4) with ESMTP id g5JI6ZR7045092 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 19 Jun 2002 11:06:35 -0700 (PDT) Received: (from gshapiro@localhost) by horsey.gshapiro.net (8.12.4/8.12.4/Submit) id g5JI6Za1045089; Wed, 19 Jun 2002 11:06:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15632.51243.373927.477888@horsey.gshapiro.net> Date: Wed, 19 Jun 2002 11:06:35 -0700 From: Gregory Neil Shapiro To: Sheldon Hearn Cc: FreeBSD-arch@FreeBSD.org Subject: Re: conf/39444: rc.sendmail syntax error: cannot disable sendmail In-Reply-To: <20020619180121.GA5897@starjuice.net> References: <3D0FB406.83DE356D@lbl.gov> <20020618155900.O2483-100000@master.gorean.org> <15632.6996.519381.823439@horsey.gshapiro.net> <3D102055.F08DD2AE@FreeBSD.org> <15632.9131.365021.260177@horsey.gshapiro.net> <20020619104912.B41546@dragon.nuxi.com> <20020619180121.GA5897@starjuice.net> X-Mailer: VM 7.03 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG sheldonh> From the beginning, this whole thing has been about a POLA sheldonh> violation on the -STABLE branch. It is ironic that the whole reason this was introduced was to avoid a POLA in that if I had left sendmail_enable=NO to mean don't start any daemons[1], that would have meant all outbound and local mail would have stayed in clientmqueue forever. [1] Note that even before I touched this, sendmail_enable=NO didn't mean don't start any sendmail daemons. This was broken when Peter added sendmail_outbound_enable. Perhaps I should just give up and make sendmail set-user-ID root again in RELENG_4. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 19 11:13:44 2002 Delivered-To: freebsd-arch@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id B5BBA37B400; Wed, 19 Jun 2002 11:13:34 -0700 (PDT) Received: from sheldonh by axl.seasidesoftware.co.za with local (Exim 3.36 #1) id 17KjyI-0001ZS-00; Wed, 19 Jun 2002 20:14:22 +0200 Date: Wed, 19 Jun 2002 20:14:22 +0200 From: Sheldon Hearn To: Gregory Neil Shapiro Cc: FreeBSD-arch@FreeBSD.org Subject: Re: conf/39444: rc.sendmail syntax error: cannot disable sendmail Message-ID: <20020619181422.GA6026@starjuice.net> Mail-Followup-To: Gregory Neil Shapiro , FreeBSD-arch@FreeBSD.org References: <3D0FB406.83DE356D@lbl.gov> <20020618155900.O2483-100000@master.gorean.org> <15632.6996.519381.823439@horsey.gshapiro.net> <3D102055.F08DD2AE@FreeBSD.org> <15632.9131.365021.260177@horsey.gshapiro.net> <20020619104912.B41546@dragon.nuxi.com> <20020619180121.GA5897@starjuice.net> <15632.51243.373927.477888@horsey.gshapiro.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15632.51243.373927.477888@horsey.gshapiro.net> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On (2002/06/19 11:06), Gregory Neil Shapiro wrote: > [1] Note that even before I touched this, sendmail_enable=NO didn't mean > don't start any sendmail daemons. This was broken when Peter added > sendmail_outbound_enable. > > Perhaps I should just give up and make sendmail set-user-ID root again in > RELENG_4. That might be worth consideration, especially if it can be done in such a way that people who've adapted to the new world order won't have to revert any changes. But then what have we scored? We still have to support sendmail_enable="NONE". Don't beat yourself up over this. How many -STABLE users are really getting totally screwed by it? It's a wart, and look what we got in return -- a more secure out-of-the-box MTA. :-) -- Sheldon Hearn Postmaster - Gambling.com In systems administration, a change is NOT as good as a holiday! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 19 11:28:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from thuvia.demon.co.uk (thuvia.demon.co.uk [193.237.34.248]) by hub.freebsd.org (Postfix) with ESMTP id 07A5C37B409 for ; Wed, 19 Jun 2002 11:28:42 -0700 (PDT) Received: from dotar.thuvia.org (dotar.thuvia.org [10.0.0.4]) by phaidor.thuvia.org (8.11.6/8.11.6) with ESMTP id g5JISdN68861; Wed, 19 Jun 2002 19:28:40 +0100 (BST) (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (localhost [IPv6:::1]) by dotar.thuvia.org (8.12.3/8.12.3) with ESMTP id g5JISdCs047710; Wed, 19 Jun 2002 19:28:39 +0100 (BST) (envelope-from mark@dotar.thuvia.org) Received: (from mark@localhost) by dotar.thuvia.org (8.12.3/8.12.3/Submit) id g5JISdEI047709; Wed, 19 Jun 2002 19:28:39 +0100 (BST) Date: Wed, 19 Jun 2002 19:28:39 +0100 (BST) From: Mark Valentine Message-Id: <200206191828.g5JISdEI047709@dotar.thuvia.org> In-Reply-To: "David O'Brien"'s message of Jun 19, 10:30am X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: FreeBSD-arch@freebsd.org Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? Cc: Alexey Dokuchaev , Ollivier Robert Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > From: "David O'Brien" > Date: Wed 19 Jun, 2002 > Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? > What is wrong with local/ in BSD.usr.dist? The permissions it applies (and the assumption that you *want* a /usr/local, though that's doesn't affect me). I always used to get bitten after an upgrade by things failing after the permissions on my /usr/local reverted if I forgot to maintain my patch. I don't suffer at the moment because my /usr/local is currently a symlink. The last disaster I had with /usr/local was when I forgot that I had to unpack and install the cvsup binary package instead of using pkg_add (boy, what a mess that made). I routinely disable BSD.local.dist, of course. Cheers, Mark. -- Mark Valentine, Thuvia Labs "Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses "We're kind of stupid that way." *munch* *munch* and endorses FreeBSD -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 19 11:31:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 4D12437B40B for ; Wed, 19 Jun 2002 11:31:35 -0700 (PDT) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.3/8.12.2) with ESMTP id g5JIVYP8042751; Wed, 19 Jun 2002 11:31:34 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.4/8.12.3/Submit) id g5JIVYIE042750; Wed, 19 Jun 2002 11:31:34 -0700 (PDT) Date: Wed, 19 Jun 2002 11:31:34 -0700 From: "David O'Brien" To: Mark Valentine Cc: FreeBSD-arch@freebsd.org, Alexey Dokuchaev , Ollivier Robert Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? Message-ID: <20020619113134.A42703@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <200206191828.g5JISdEI047709@dotar.thuvia.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200206191828.g5JISdEI047709@dotar.thuvia.org>; from mark@thuvia.demon.co.uk on Wed, Jun 19, 2002 at 07:28:39PM +0100 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Jun 19, 2002 at 07:28:39PM +0100, Mark Valentine wrote: > > What is wrong with local/ in BSD.usr.dist? > > The permissions it applies (and the assumption that you *want* a > /usr/local, though that's doesn't affect me). > > I always used to get bitten after an upgrade by things failing after > the permissions on my /usr/local reverted if I forgot to maintain my > patch. From what to what? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 19 11:38:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from thuvia.demon.co.uk (thuvia.demon.co.uk [193.237.34.248]) by hub.freebsd.org (Postfix) with ESMTP id CE8AD37B40B; Wed, 19 Jun 2002 11:38:21 -0700 (PDT) Received: from dotar.thuvia.org (dotar.thuvia.org [10.0.0.4]) by phaidor.thuvia.org (8.11.6/8.11.6) with ESMTP id g5JIcKN68915; Wed, 19 Jun 2002 19:38:20 +0100 (BST) (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (localhost [IPv6:::1]) by dotar.thuvia.org (8.12.3/8.12.3) with ESMTP id g5JIcJCs048019; Wed, 19 Jun 2002 19:38:19 +0100 (BST) (envelope-from mark@dotar.thuvia.org) Received: (from mark@localhost) by dotar.thuvia.org (8.12.3/8.12.3/Submit) id g5JIcJ8C048018; Wed, 19 Jun 2002 19:38:19 +0100 (BST) Date: Wed, 19 Jun 2002 19:38:19 +0100 (BST) From: Mark Valentine Message-Id: <200206191838.g5JIcJ8C048018@dotar.thuvia.org> In-Reply-To: "David O'Brien"'s message of Jun 19, 11:31am X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: obrien@freebsd.org Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? Cc: FreeBSD-arch@freebsd.org, Alexey Dokuchaev , Ollivier Robert Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > From: "David O'Brien" > Date: Wed 19 Jun, 2002 > Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? > > I always used to get bitten after an upgrade by things failing after > > the permissions on my /usr/local reverted if I forgot to maintain my > > patch. > > From what to what? My /usr/local is uname=root gname=staff mode=0775. mtree wants it to be uname=root gname=wheel mode=0755. Cheers, Mark. -- Mark Valentine, Thuvia Labs "Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses "We're kind of stupid that way." *munch* *munch* and endorses FreeBSD -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 19 11:56:24 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id C705737B415; Wed, 19 Jun 2002 11:55:57 -0700 (PDT) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020619185557.JWIL11659.rwcrmhc53.attbi.com@blossom.cjclark.org>; Wed, 19 Jun 2002 18:55:57 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.3/8.12.3) with ESMTP id g5JItvJK022214; Wed, 19 Jun 2002 11:55:57 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.3/8.12.3/Submit) id g5JItuMI022213; Wed, 19 Jun 2002 11:55:56 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Wed, 19 Jun 2002 11:55:56 -0700 From: "Crist J. Clark" To: "David O'Brien" Cc: Gregory Neil Shapiro , Doug Barton , "Jin Guojun[DSD]" , FreeBSD-arch@FreeBSD.org Subject: Re: conf/39444: rc.sendmail syntax error: cannot disable sendmail Message-ID: <20020619115556.D21469@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <3D0FB406.83DE356D@lbl.gov> <20020618155900.O2483-100000@master.gorean.org> <15632.6996.519381.823439@horsey.gshapiro.net> <3D102055.F08DD2AE@FreeBSD.org> <15632.9131.365021.260177@horsey.gshapiro.net> <20020619104912.B41546@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020619104912.B41546@dragon.nuxi.com>; from obrien@FreeBSD.org on Wed, Jun 19, 2002 at 10:49:12AM -0700 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Jun 19, 2002 at 10:49:12AM -0700, David O'Brien wrote: > On Tue, Jun 18, 2002 at 11:24:43PM -0700, Gregory Neil Shapiro wrote: > > DougB> The problem is, the users are getting confused. Neither of the methods > > DougB> you describe is "standard," which is a big part of the confusion. > > > > I guess the standard way would be: > > > > sendmail_enable=NO > > sendmail_submit_enable=NO > > sendmail_outbound_enable=NO > > sendmail_msp_queue_enable=NO > > Yes. Since you fully support this, I don't understand what the issue is. > People have old configurations that want "sendmail_enable=NO" to equal > the above? Too bad, there are many configuration changes to learn when > going from -stable to -current. So they will just have to learn there is > more granularity now. I don't think there would be much of an issue if it were only changed in -CURRENT (see my last remark), but this change was made to -STABLE and just hit its first -RELEASE cycle. To rehash the logic one last time, sendmail(8) in the -STABLE was upgraded to 8.12.2. In order to send outbound mail properly, the new version sendmail(8) needs a listening, submission daemon (this is a security feature, not a bug). Since sendmail_enable="YES" has been the default in FreeBSD forever, turning this on as well by default was the obvious thing to do. Those who use alternate MTAs or just have something against sendmail(8) got upset because now when they switched 'sendmail_enable' to "NO," they _still_ had a sendmail(8) daemon listening. They complained that setting all of those switches to "NO" was too much of a hassle (not really a good argument) and what if more changes were made in the future, they want a way to turn off sendmail(8) now and forever (actually a pretty good argument). The heart of the problem is that to those who use sendmail(8), 'sendmail_enable="NO"' meant turn on the listener to receive incoming mail from remote sites (but not necessarily outgoing mail), whereas to the non-sendmail(8) users, it meant turn off sendmail(8) completely. With the new design, it could no longer serve those two different function for both groups. So, instead of making a whole new knob or defaulting to the non-sendmail(8) user's desired behavior (the monthly flamefests on -current and -stable about removing sendmail(8) from the base system are not due for another week or two, so don't start that again right now), a new setting for the existing 'sendmail_enable' switch was provided that will disable all sendmail(8) daemons at startup now and forever, "NONE". For people who use sendmail(8) as an MTA, either in both incoming and outgoing or just in outgoing modes, (which are believed to be the vast majority of users) they need not modify their old rc.conf(5)'s and they should get the same behavior as they did before the upgrade to >8.12.2. This was the most important consideration. Someone who upgrades -STABLE or to the next -RELEASE should get the same _functionality_ with the same rc.conf to the greatest extent possible (if it means running a sendmail(8) daemon that was not running before, so be it). To add to the excitement, 'sendmaill_enable' (and 'inetd_enable' as well) were actually turned off by default for a few days in -STABLE, but after massive postings to -stable the defaults were switched back. (I'm just glad we finally managed to get ftp(1) and telnet(1) turned off by default. It only took a remote root hole in telnetd(8) to finally get that done.) > > This is (and was) always available. sendmail_enable=NONE is just a > > shortcut that has the same effect as setting all four to NO. > > This is non-standard. In fact I would really like us to use the NetBSD > way of testing the knobs such that any "negative" setting means no. > "NONE" would break with this. > > Thus my voiced support is "do nothing" (other than maybe remove the NONE > support). What to do in -CURRENT is a whole 'nother ball game. At present, 'sendmail_enable' is "NO" in -CURRENT (yay!) and 'sendmail_{submit,outbound}_enable' both default to "YES." Since rc_ng development is finally getting some life, we can look at completely reworking these issues, what knobs exist and what their default settings are, for 5.0-RELEASE. Also since we are importing the NetBSD startup, having things work more like theirs makes a lot more sense. As for -STABLE, I think "NONE" is a reasonable band-aid cure for the remaining life of the RELENG_4 branch. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 19 12: 3:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: from is2.mh.itc.u-tokyo.ac.jp (is2.mh.itc.u-tokyo.ac.jp [133.11.205.12]) by hub.freebsd.org (Postfix) with ESMTP id 1CA6337B404 for ; Wed, 19 Jun 2002 12:02:27 -0700 (PDT) Received: from is2.mh.itc.u-tokyo.ac.jp (is2.mh.itc.u-tokyo.ac.jp [127.0.0.1]) by is2.mh.itc.u-tokyo.ac.jp (Postfix) with ESMTP id 4E650378076 for ; Thu, 20 Jun 2002 04:02:26 +0900 (JST) Received: from mailhosting.itc.u-tokyo.ac.jp (IDENT:mirapoint@mailhosting.itc.u-tokyo.ac.jp [133.11.205.3]) by is2.mh.itc.u-tokyo.ac.jp (8.11.3/8.11.3) with ESMTP id g5JJ2QL09207 for ; Thu, 20 Jun 2002 04:02:26 +0900 Received: from amulet.ht.myn.rcast.u-tokyo.ac.jp (YahooBB219001110022.bbtec.net [219.1.110.22]) by mailhosting.itc.u-tokyo.ac.jp (Mirapoint Messaging Server MOS 2.9.3.2) with ESMTP id AGL27946; Thu, 20 Jun 2002 04:02:24 +0900 (JST) Date: Thu, 20 Jun 2002 04:02:41 +0900 Message-ID: From: Hiroharu Tamaru To: freebsd-arch@FreeBSD.ORG Subject: Re: Configuration management In-Reply-To: <20020619031533.2c302e68.makonnen@pacbell.net> References: <20020619031533.2c302e68.makonnen@pacbell.net> User-Agent: Wanderlust/2.8.1 (Something) Emacs/21.2 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: multipart/mixed; boundary="Multipart_Thu_Jun_20_04:02:41_2002-1" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --Multipart_Thu_Jun_20_04:02:41_2002-1 Content-Type: text/plain; charset=US-ASCII Hi, At Wed, 19 Jun 2002 03:15:33 -0700, Mike Makonnen wrote: > I am of a different opinion. I happen to like plain-text configuration files. > The problem is not that we need an easier way to _edit_ the files, > but rather we need a better way to manage all those files and the changes > we make to them. For example, I have a haphazard collection of rcs files I totally agree. In fact I have been using cvs for this task since FreeBSD 2.2.x days. I track -stable every several months. As the buildworld Makefiles evolve, things has become easier, and never harder. I am not using mergemaster at all in the process (no offense here too; I just adopted a way without it before it appeared). I have always found the "cvs diff" abilty invaluable. For what it's worth, I will attach my helper scripts (mainly for bootstraping the repository on a newly installed machine) to give you an idea. It's not fully automated nor complete nor clean, but has served me quite well for a long time. These is no script for automating updates; I type them manually following my memo: # cvsup the source, then cd /usr/src make -j4 buildworld < /dev/null >& build.2001.02.02 & make -j4 buildkernel < /dev/null >& kernel.2001.02.02 & cd /w/4src rm -rf config mkdir config cd /usr/src/etc make distrib-dirs distribution DESTDIR=/w/4src/config cd /w/4src/config /w/4src/tools/clean-etc-distrib-check | less /w/4src/tools/clean-etc-distrib cvs -d /var/cvs import -m "import after cvsup" config FreeBSD_core RELENG_4_20010202 suspend cd ~ mkdir cvstmp chmod go-rwx cvstmp cd cvstmp cvs -d /var/cvs co -jFreeBSD_core:yesterday -jFreeBSD_core config .... cd ~/cvstmp/config/ cvs diff -u cvs commit -m "merged after cvsup" fg cd /usr/src make installworld < /dev/null >& install.2001.02.02 & make installkernel < /dev/null >>& install.2001.02.02 & cd / cvs update cd /dev ./MAKEDEV all shutdown -r +1 Oh, by the way, on my machines, the following links exist: /usr/src -> /w/4src/src /usr/obj -> /w/4src/i386 or /w/4src/alpha and I have /w/4src/config as the teporary install space for /etc stuff and /w/4src/tools for the scripts I have. /w is nfs mounted all around the place and the clients simple use what the build machine has built here. The repository is at /var/cvs with the module name "config" The clean-etc-distrib stuff was mainly for the very old days when "make distribution" installed binary programs in /w/4src/config/ . I was too lazy to update my scripts. -- Hiroharu Tamaru --Multipart_Thu_Jun_20_04:02:41_2002-1 Content-Type: text/plain; charset=US-ASCII Content-Disposition: attachment; filename="bootstrap-etc-cvs" Content-Transfer-Encoding: 7bit #!/bin/sh ERR=0 if [ ! -d /w/4src/config/etc -o -e /w/4src/config/dev/null ]; then cat < ../files.list filelist=`cat ../files.list` echo "copying all CVS controlled files for / to $DIR/config/" echo "diffs are available at $DIR/files.diff" for i in ${filelist}; do diff -u $i /$i >> ../files.diff cp /$i $i done echo "change dir to $DIR/config/etc" cd etc echo "rm passwd master.passwd pwd.db spwd.db" rm passwd master.passwd pwd.db spwd.db echo "cvs remove passwd master.passwd pwd.db spwd.db" cvs remove passwd master.passwd pwd.db spwd.db echo "" echo "Invoking /bin/csh" echo "You can check up using cvs commands now." echo "Exit this shell to continue." echo "Commit will follow exit and then $DIR will be removed." csh cd $DIR/config echo "==================================================================" cvs commit -m "newly installed" echo "==================================================================" rm -rf $DIR || exit mkdir $DIR || exit cd $DIR || exit echo "==================================================================" cvs -d /var/cvs checkout config echo "==================================================================" cd config || exit cp -RPpv . / rm -rf $DIR || exit echo "everything is copyed to /" echo "try cvs update at / and also run 'recover.modes'" --Multipart_Thu_Jun_20_04:02:41_2002-1 Content-Type: text/plain; charset=US-ASCII Content-Disposition: attachment; filename="clean-etc-distrib-check" Content-Transfer-Encoding: 7bit #!/bin/sh - rm -f ./root/distribution.files find . -ls \ | awk '{if ($7~/,/){print $3,$4,$5,$6,$7$8,$12}else if($12~/-/){print $3,$4,$5,$6,$7,$11,$12,$13}else{print $3,$4,$5,$6,$7,$11}}' \ | sort +5 > ./root/distribution.files echo "===== differences in distribution files" diff -u0 /root/distribution.files ./root/distribution.files echo "===== everything but files and dirs" find . \! \( -type d -o -type f \) | xargs ls -dl echo "===== empty files" find . -type f -size 0 | xargs ls -dl echo "===== executable binaries" find . -type f -perm -100 | xargs file | grep 'executable$' | grep -v ' text ' --Multipart_Thu_Jun_20_04:02:41_2002-1 Content-Type: text/plain; charset=US-ASCII Content-Disposition: attachment; filename="clean-etc-distrib" Content-Transfer-Encoding: 7bit #!/bin/sh - echo "===== generate ./root/distribution.files" rm -f ./root/distribution.files find . -ls \ | awk '{if ($7~/,/){print $3,$4,$5,$6,$7$8,$12}else if($12~/-/){print $3,$4,$5,$6,$7,$11,$12,$13}else{print $3,$4,$5,$6,$7,$11}}' \ | sort +5 > ./root/distribution.files echo "===== remove everything but files and dirs" find . \! \( -type d -o -type f \) | xargs rm -f echo "===== remove empty files" find . -type f -size 0 | xargs rm -f echo "===== remove executable binaries" find . -type f -perm -100 | xargs file | grep 'executable$' | grep -v ' text '\ | sed 's/:[^:]*$//' | xargs rm -f echo "===== remove empty directories .. don't bother about the errors!" find . -type d | sort -r | xargs rmdir echo "===== generate ./root/mtree.modes" mtree -c -kuid,gid,mode > ./root/mtree.modes echo "===== done" --Multipart_Thu_Jun_20_04:02:41_2002-1 Content-Type: text/plain; charset=US-ASCII Content-Disposition: attachment; filename="recover.modes" Content-Transfer-Encoding: 7bit #!/bin/sh - # execute this from root directory, or where ever you want it to root at. cd / mtree -U -e -f ./root/mtree.modes # --Multipart_Thu_Jun_20_04:02:41_2002-1-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 19 12:21:39 2002 Delivered-To: freebsd-arch@freebsd.org Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id 0B64937B40C for ; Wed, 19 Jun 2002 12:21:34 -0700 (PDT) Received: from pool0424.cvx40-bradley.dialup.earthlink.net ([216.244.43.169] helo=mindspring.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17Kl19-0000JT-00; Wed, 19 Jun 2002 12:21:24 -0700 Message-ID: <3D10D98E.4B8E308F@mindspring.com> Date: Wed, 19 Jun 2002 12:20:46 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Makonnen Cc: freebsd-arch@freebsd.org Subject: Re: Configuration management References: <20020619031533.2c302e68.makonnen@pacbell.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Makonnen wrote: > From time to time, I've seen threads on various mailing-lists about > creating a gui tool for configuring the system (basically /etc/rc.conf). > The assumption is that providing some sort of point-and-click interface > will make it easier to configure FreeBSD. The problem with this, among > other things, is that it requires developer buy-in because the configuration > tool has to be updated everytime a new knob is added, which makes it more > tedious and error prone for the developer. The tool was already written, and is available in ports. It doesn't require tweaking for new knobs, because it operates on knobs in an abstract sense, rather than having a full list of knobs. It gets its knob list from the l-values in the files on which it operates. I am personally a big fan of the single configuration store; this is because it's more important to me to be able to replicate an exisiting configuration onto a new machine, than it is for me to be able to back up to a previous known working configuration. > For example, I have a haphazard collection of rcs files > for files I have edited in /etc. Most times I do co/ci when I edit them > but sometimes I'm in a hurry and I don't bother or I just plain forget. Not all > the files are in rcs. I don't have a standard tagging scheme. I also don't > generally tag them all before or after a mergemaster. However, I believe these > things should be done for all my files on a consistent basis, but I'm > generally too lazy and don't bother :-( so an automated system that did > all these things for me would be nice. [ ... ] > To address this, I would like to develop a set of scripts, for inclusion in > the base system, that manage the files in /etc as a set of rcs files. The canonical way of doing this would probably be to support versioning in the file system. There are ways that this can be done, but there are certain things about UNIX that make it hard to get right (specifically, globbing), and VFS stacking is not as easy as it should be, so that approach is probably going to be a non-starter, unless you are prepared to do a lot of work. I think your project is a interesting idea, even though I would personally probably not use it (but I do not administer a large enough number of FreeBSD systems frequently enough for it to be an issue for me). I know that David Wolfskill does a lot of this type of thing himself. He would probably have a lot of suggestions that would be useful for you. If you are in the Bay Area, then you might want to contact BayLISA, where you could get input from a large number of system administrators for large systems and large clusters. You might also want to look at a number of the existing tools in this area. There are several projects that deal with graphical administration. They are mostly Linux-centric, but there have been active FreeBSD porting efforts. I really think that this may be more of a UNIX thing in general, than a FreeBSD thing in particular, or at least a BSD thing in general, given that FreeBSD's "rcNG" project is in the process of converting 5.x to be as compatible with the NetBSD rc system, and therefore configuration files, as possible. Good luck with your project! -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 19 18:49: 7 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by hub.freebsd.org (Postfix) with ESMTP id 87AAA37B40E for ; Wed, 19 Jun 2002 18:49:04 -0700 (PDT) Received: from zoot.corp.yahoo.com (zoot.corp.yahoo.com [216.145.52.89]) by mrout2.yahoo.com (8.11.6/8.11.6/y.out) with ESMTP id g5K1mrR81310; Wed, 19 Jun 2002 18:48:53 -0700 (PDT) Received: from localhost (dougb@localhost) by zoot.corp.yahoo.com (8.12.3/8.12.3/Submit) with ESMTP id g5K1mrHg021761; Wed, 19 Jun 2002 18:48:53 -0700 (PDT) Date: Wed, 19 Jun 2002 18:48:53 -0700 (PDT) From: Doug Barton To: Gordon Tetlow Cc: arch@FreeBSD.org Subject: Re: MFC of src/etc/rc.subr In-Reply-To: Message-ID: <20020619184818.W21357-100000@zoot.corp.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 19 Jun 2002, Gordon Tetlow wrote: > I'm going to MFC src/etc/rc.subr into -STABLE probably tomorrow unless > someone has some grevious reason that it shouldn't. Personally I think it's way too premature to consider this, before we actually have things working in -current. -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 19 19:10:53 2002 Delivered-To: freebsd-arch@freebsd.org Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id C48AB37B40F; Wed, 19 Jun 2002 19:10:50 -0700 (PDT) Received: from pool0411.cvx21-bradley.dialup.earthlink.net ([209.179.193.156] helo=mindspring.com) by gull.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17KrPO-0003NK-00; Wed, 19 Jun 2002 19:10:50 -0700 Message-ID: <3D113982.4370D5E0@mindspring.com> Date: Wed, 19 Jun 2002 19:10:10 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Doug Barton Cc: Gordon Tetlow , arch@FreeBSD.org Subject: Re: MFC of src/etc/rc.subr References: <20020619184818.W21357-100000@zoot.corp.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Doug Barton wrote: > On Wed, 19 Jun 2002, Gordon Tetlow wrote: > > I'm going to MFC src/etc/rc.subr into -STABLE probably tomorrow unless > > someone has some grevious reason that it shouldn't. > > Personally I think it's way too premature to consider this, before we > actually have things working in -current. Since it won't be turned on by default, this should be a non-problem. Even if it were turned on, it should *still* not be a problem, until people provide ports rc scripts in the new format. I think things *are* working in -current. The intent, I think, is still to allow ports made for 5.x to run on 4.7 when/if it becomes available. That's what was promised, the first half dozen times this issue came up. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 19 22:50:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id B79B537B410; Wed, 19 Jun 2002 22:50:38 -0700 (PDT) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.3/8.12.2) with ESMTP id g5K5obP8055681; Wed, 19 Jun 2002 22:50:37 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.4/8.12.3/Submit) id g5K5obeV055680; Wed, 19 Jun 2002 22:50:37 -0700 (PDT) Date: Wed, 19 Jun 2002 22:50:37 -0700 From: "David O'Brien" To: Doug Barton Cc: Gordon Tetlow , arch@FreeBSD.org Subject: Re: MFC of src/etc/rc.subr Message-ID: <20020619225037.A55653@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org Mail-Followup-To: David O'Brien , Doug Barton , Gordon Tetlow , arch@FreeBSD.org References: <20020619184818.W21357-100000@zoot.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020619184818.W21357-100000@zoot.corp.yahoo.com>; from DougB@FreeBSD.org on Wed, Jun 19, 2002 at 06:48:53PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Jun 19, 2002 at 06:48:53PM -0700, Doug Barton wrote: > On Wed, 19 Jun 2002, Gordon Tetlow wrote: > > > I'm going to MFC src/etc/rc.subr into -STABLE probably tomorrow unless > > someone has some grevious reason that it shouldn't. > > Personally I think it's way too premature to consider this, before we > actually have things working in -current. Uh, things are working in -current. At this point I've only heard there might be a sendmail nit and a BIND one. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 19 23:32:34 2002 Delivered-To: freebsd-arch@freebsd.org Received: from nothing-going-on.demon.co.uk (pc-62-31-42-140-hy.blueyonder.co.uk [62.31.42.140]) by hub.freebsd.org (Postfix) with ESMTP id 0B7FB37B405; Wed, 19 Jun 2002 23:32:29 -0700 (PDT) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.11.3/8.11.3) id g5IMRqe75515; Tue, 18 Jun 2002 23:27:52 +0100 (BST) (envelope-from nik) Date: Tue, 18 Jun 2002 23:27:51 +0100 From: Nik Clayton To: Doug Barton Cc: Nik Clayton , Sheldon Hearn , Trish Lynch , arch@freebsd.org Subject: Re: 4.x compatibilty.. Was: MFC of rcNG? Message-ID: <20020618232751.K52976@canyon.nothing-going-on.org> References: <20681.1024423602@axl.seasidesoftware.co.za> <3D0F7AAA.110E0D8@FreeBSD.org> <20020618224029.I52976@canyon.nothing-going-on.org> <3D0FB17F.6F8B5819@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="72k7VsmfIboquFwl" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D0FB17F.6F8B5819@FreeBSD.org>; from DougB@FreeBSD.org on Tue, Jun 18, 2002 at 03:17:35PM -0700 Organization: FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --72k7VsmfIboquFwl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 18, 2002 at 03:17:35PM -0700, Doug Barton wrote: > But (and I may be biased here) I think it's all curving in the > right direction.=20 As do I. 5.x is going to kick ass. But the more painful we make the migration process, the fewer people who will migrate. N --=20 FreeBSD: The Power to Serve http://www.freebsd.org/ (__) FreeBSD Documentation Project http://www.freebsd.org/docproj/ \\\'',) \/ \= ^ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- .\._/= _) --72k7VsmfIboquFwl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9D7Pnk6gHZCw343URAsK+AJ453pyYl1uyP8Pa+SYZtRA/FLBjkACeKRFi fScyd93hMGyleP+9teSWrQY= =5gEJ -----END PGP SIGNATURE----- --72k7VsmfIboquFwl-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 20 1:52:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay1.yahoo.com (mail-relay1.yahoo.com [216.145.48.34]) by hub.freebsd.org (Postfix) with ESMTP id 3448437B40C for ; Thu, 20 Jun 2002 01:52:51 -0700 (PDT) Received: from FreeBSD.org (12-234-90-219.client.attbi.com [12.234.90.219]) by mail-relay1.yahoo.com (Postfix) with ESMTP id 374BC8B60C; Thu, 20 Jun 2002 01:52:48 -0700 (PDT) Message-ID: <3D1197E0.26BCCA08@FreeBSD.org> Date: Thu, 20 Jun 2002 01:52:48 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.79 [en] (X11; U; FreeBSD 4.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: Gordon Tetlow , arch@FreeBSD.org Subject: Re: MFC of src/etc/rc.subr References: <20020619184818.W21357-100000@zoot.corp.yahoo.com> <3D113982.4370D5E0@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > > Doug Barton wrote: > > On Wed, 19 Jun 2002, Gordon Tetlow wrote: > > > I'm going to MFC src/etc/rc.subr into -STABLE probably tomorrow unless > > > someone has some grevious reason that it shouldn't. > > > > Personally I think it's way too premature to consider this, before we > > actually have things working in -current. > > Since it won't be turned on by default, this should be a > non-problem. Even if it were turned on, it should *still* > not be a problem, until people provide ports rc scripts in > the new format. > > I think things *are* working in -current. There have been patches to fix typos, logic errors, etc.; every day since the stuff was committed recently. Note, I don't think this is a problem, since we basically expect this sort of thing in the early stages. My concern is that people will start writing scripts that use these interfaces, then we're going to change them. However, if no one else objects, I suppose it's ok.... -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 20 1:57:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay1.yahoo.com (mail-relay1.yahoo.com [216.145.48.34]) by hub.freebsd.org (Postfix) with ESMTP id 3748B37B40D; Thu, 20 Jun 2002 01:57:26 -0700 (PDT) Received: from FreeBSD.org (12-234-90-219.client.attbi.com [12.234.90.219]) by mail-relay1.yahoo.com (Postfix) with ESMTP id 7CC658B5BE; Thu, 20 Jun 2002 01:57:24 -0700 (PDT) Message-ID: <3D1198F4.2FC3EF44@FreeBSD.org> Date: Thu, 20 Jun 2002 01:57:24 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.79 [en] (X11; U; FreeBSD 4.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: cjclark@alum.mit.edu Cc: David O'Brien , Gregory Neil Shapiro , "Jin Guojun[DSD]" , FreeBSD-arch@FreeBSD.org Subject: Adding a dont_use_any_sendmail knob References: <3D0FB406.83DE356D@lbl.gov> <20020618155900.O2483-100000@master.gorean.org> <15632.6996.519381.823439@horsey.gshapiro.net> <3D102055.F08DD2AE@FreeBSD.org> <15632.9131.365021.260177@horsey.gshapiro.net> <20020619104912.B41546@dragon.nuxi.com> <20020619115556.D21469@blossom.cjclark.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Crist J. Clark" wrote: > I don't think there would be much of an issue if it were only changed > in -CURRENT (see my last remark), but this change was made to -STABLE > and just hit its first -RELEASE cycle. And now that it's in a release, even more users are confused, and asking questions about it. > Those who use alternate MTAs or just have something against > sendmail(8) got upset because now when they switched 'sendmail_enable' > to "NO," they _still_ had a sendmail(8) daemon listening. I don't see it that way at all. This is not an "anti-sendmail" thing. I myself use sendmail, both for outgoing and incoming mail. My point is simply that users are confused about this current state of events, and we should do something to make things more clear. Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 20 3:35:10 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rina.r.dl.itc.u-tokyo.ac.jp (rina.r.dl.itc.u-tokyo.ac.jp [133.11.199.247]) by hub.freebsd.org (Postfix) with ESMTP id A08B737B405 for ; Thu, 20 Jun 2002 03:35:07 -0700 (PDT) Received: from rina.r.dl.itc.u-tokyo.ac.jp (localhost [127.0.0.1]) by rina.r.dl.itc.u-tokyo.ac.jp (8.12.3+3.5Wbeta/3.7W-rina.r-Nankai-Koya) with ESMTP id g5KAZ53i029301 ; Thu, 20 Jun 2002 19:35:06 +0900 (JST) Message-Id: <200206201035.g5KAZ53i029301@rina.r.dl.itc.u-tokyo.ac.jp> Date: Thu, 20 Jun 2002 19:35:05 +0900 From: Seigo Tanimura To: arch@FreeBSD.org Subject: multiple threads for interrupts Cc: Seigo Tanimura User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.3 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Digital Library Research Division, Information Techinology Centre, The University of Tokyo MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At the moment, each interrupt type (hardware and swi) has only one kernel thread to handle interrupts. This can be a potential bottleneck in an SMP host because virtually only up to one processor can handle interrupts. One solution is to run multiple threads for each of the interrupt types. Since I noticed this issue first during my work of network locking, I have been tweaking the swi subsystem so that it runs multiple threads for an swi type. For those who are interested, the patch can be found at: http://people.FreeBSD.org/~tanimura/patches/swipool.diff.gz While I worked on only swis, hardware interrupts should suffer from the same issue as well. Thus it would be better to tweak the general interrupt mechanism rather than only the swi subsystem. I will see how that works in the next few days. Comments and flames are welcome. Thanks a lot. -- Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 20 3:44:24 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rina.r.dl.itc.u-tokyo.ac.jp (rina.r.dl.itc.u-tokyo.ac.jp [133.11.199.247]) by hub.freebsd.org (Postfix) with ESMTP id 6239037B400 for ; Thu, 20 Jun 2002 03:44:20 -0700 (PDT) Received: from rina.r.dl.itc.u-tokyo.ac.jp (localhost [127.0.0.1]) by rina.r.dl.itc.u-tokyo.ac.jp (8.12.3+3.5Wbeta/3.7W-rina.r-Nankai-Koya) with ESMTP id g5KAiJ3i032356 ; Thu, 20 Jun 2002 19:44:19 +0900 (JST) Message-Id: <200206201044.g5KAiJ3i032356@rina.r.dl.itc.u-tokyo.ac.jp> Date: Thu, 20 Jun 2002 19:44:18 +0900 From: Seigo Tanimura To: Seigo Tanimura Cc: arch@FreeBSD.org Subject: Re: multiple threads for interrupts In-Reply-To: <200206201035.g5KAZ53i029301@rina.r.dl.itc.u-tokyo.ac.jp> References: <200206201035.g5KAZ53i029301@rina.r.dl.itc.u-tokyo.ac.jp> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.3 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Digital Library Research Division, Information Techinology Centre, The University of Tokyo MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 20 Jun 2002 19:35:05 +0900, Seigo Tanimura said: tanimura> At the moment, each interrupt type (hardware and swi) has only one tanimura> kernel thread to handle interrupts. This can be a potential tanimura> bottleneck in an SMP host because virtually only up to one processor tanimura> can handle interrupts. tanimura> One solution is to run multiple threads for each of the interrupt tanimura> types. Since I noticed this issue first during my work of network tanimura> locking, I have been tweaking the swi subsystem so that it runs tanimura> multiple threads for an swi type. For those who are interested, the tanimura> patch can be found at: tanimura> http://people.FreeBSD.org/~tanimura/patches/swipool.diff.gz With this patch, the system runs as many kernel threads as the number of CPUs for each swi types: naho% dmesg | grep SMP FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs naho% ps axuwwg | grep swi root 13 0.0 0.0 0 3 ?? WL 1Jan70 3:08.71 (swi1: net) root 14 0.0 0.0 0 3 ?? WL 1Jan70 3:05.91 (swi1: net) root 15 0.1 0.0 0 3 ?? WL 1Jan70 6:37.67 (swi6: tty:sio clock) root 16 0.0 0.0 0 3 ?? WL 1Jan70 5:56.67 (swi6: tty:sio clock) root 17 0.0 0.0 0 3 ?? WL 1Jan70 0:00.00 (swi4: vm) root 18 0.0 0.0 0 3 ?? WL 1Jan70 0:00.00 (swi4: vm) root 20 0.0 0.0 0 3 ?? WL 1Jan70 0:00.00 (swi2: camnet) root 21 0.0 0.0 0 3 ?? WL 1Jan70 0:00.00 (swi2: camnet) root 22 0.0 0.0 0 3 ?? WL 1Jan70 0:00.25 (swi3: cambio) root 23 0.0 0.0 0 3 ?? WL 1Jan70 0:00.00 (swi3: cambio) root 24 0.0 0.0 0 3 ?? WL 1Jan70 0:00.00 (swi5: task queue) root 25 0.0 0.0 0 3 ?? WL 1Jan70 0:00.00 (swi5: task queue) root 30 0.0 0.0 0 3 ?? WL 1Jan70 0:00.00 (swi0: tty:sio) root 31 0.0 0.0 0 3 ?? WL 1Jan70 0:00.00 (swi0: tty:sio) tanimura 47144 0.0 0.1 308 46 p1 M+ 7:38PM 0:00.00 grep swi The number of CPUs is chosen for the number of kernel threads per an swi type because it is the maximum possible number of threads runnable in parallel. It gives us nothing but contention to run more threads. tanimura> While I worked on only swis, hardware interrupts should suffer from tanimura> the same issue as well. Thus it would be better to tweak the general tanimura> interrupt mechanism rather than only the swi subsystem. I will see tanimura> how that works in the next few days. tanimura> Comments and flames are welcome. Thanks a lot. -- Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 20 4:19: 7 2002 Delivered-To: freebsd-arch@freebsd.org Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 1E52937B403 for ; Thu, 20 Jun 2002 04:19:05 -0700 (PDT) Received: from pool0027.cvx22-bradley.dialup.earthlink.net ([209.179.198.27] helo=mindspring.com) by falcon.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17Kzxu-0004oE-00; Thu, 20 Jun 2002 04:19:02 -0700 Message-ID: <3D11BA00.45A85EC9@mindspring.com> Date: Thu, 20 Jun 2002 04:18:24 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Seigo Tanimura Cc: arch@FreeBSD.org Subject: Re: multiple threads for interrupts References: <200206201035.g5KAZ53i029301@rina.r.dl.itc.u-tokyo.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Seigo Tanimura wrote: > One solution is to run multiple threads for each of the interrupt > types. Since I noticed this issue first during my work of network > locking, I have been tweaking the swi subsystem so that it runs > multiple threads for an swi type. For those who are interested, the > patch can be found at: > > http://people.FreeBSD.org/~tanimura/patches/swipool.diff.gz Benchmarks before and after, demonstrating an improvement? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 20 6:15:34 2002 Delivered-To: freebsd-arch@freebsd.org Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by hub.freebsd.org (Postfix) with ESMTP id EFE2637B409 for ; Thu, 20 Jun 2002 06:15:27 -0700 (PDT) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g5KDCxF21531; Thu, 20 Jun 2002 09:12:59 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Thu, 20 Jun 2002 09:12:59 -0400 From: Bosko Milekic To: Seigo Tanimura Cc: arch@FreeBSD.ORG Subject: Re: multiple threads for interrupts Message-ID: <20020620091259.A21509@unixdaemons.com> References: <200206201035.g5KAZ53i029301@rina.r.dl.itc.u-tokyo.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200206201035.g5KAZ53i029301@rina.r.dl.itc.u-tokyo.ac.jp>; from tanimura@r.dl.itc.u-tokyo.ac.jp on Thu, Jun 20, 2002 at 07:35:05PM +0900 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Jun 20, 2002 at 07:35:05PM +0900, Seigo Tanimura wrote: > At the moment, each interrupt type (hardware and swi) has only one > kernel thread to handle interrupts. This can be a potential > bottleneck in an SMP host because virtually only up to one processor > can handle interrupts. > > One solution is to run multiple threads for each of the interrupt > types. Since I noticed this issue first during my work of network > locking, I have been tweaking the swi subsystem so that it runs > multiple threads for an swi type. For those who are interested, the > patch can be found at: > > http://people.FreeBSD.org/~tanimura/patches/swipool.diff.gz This looks very interesting. However, I'm unsure as to whether spinning off another thread as opposed to just setting the need bit and letting the original thread re-service is actually a better idea. It would be interesting to keep this code around and see what happens with performance. Perhaps we will observe that it is only better in the software interrupt case, or vice-versa. > While I worked on only swis, hardware interrupts should suffer from > the same issue as well. Thus it would be better to tweak the general > interrupt mechanism rather than only the swi subsystem. I will see > how that works in the next few days. > > Comments and flames are welcome. Thanks a lot. > > -- > Seigo Tanimura Regards, -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 20 8:38: 4 2002 Delivered-To: freebsd-arch@freebsd.org Received: from horsey.gshapiro.net (horsey.gshapiro.net [209.220.147.178]) by hub.freebsd.org (Postfix) with ESMTP id 94A9437B404; Thu, 20 Jun 2002 08:38:01 -0700 (PDT) Received: from horsey.gshapiro.net (gshapiro@localhost [IPv6:::1]) by horsey.gshapiro.net (8.12.4/8.12.4) with ESMTP id g5KFbxLW004089 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 20 Jun 2002 08:37:59 -0700 (PDT) Received: (from gshapiro@localhost) by horsey.gshapiro.net (8.12.4/8.12.4/Submit) id g5KFbw0S004086; Thu, 20 Jun 2002 08:37:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15633.63190.645099.218482@horsey.gshapiro.net> Date: Thu, 20 Jun 2002 08:37:58 -0700 From: Gregory Neil Shapiro To: Doug Barton Cc: cjclark@alum.mit.edu, FreeBSD-arch@FreeBSD.org Subject: Re: Adding a dont_use_any_sendmail knob In-Reply-To: <3D1198F4.2FC3EF44@FreeBSD.org> References: <3D0FB406.83DE356D@lbl.gov> <20020618155900.O2483-100000@master.gorean.org> <15632.6996.519381.823439@horsey.gshapiro.net> <3D102055.F08DD2AE@FreeBSD.org> <15632.9131.365021.260177@horsey.gshapiro.net> <20020619104912.B41546@dragon.nuxi.com> <20020619115556.D21469@blossom.cjclark.org> <3D1198F4.2FC3EF44@FreeBSD.org> X-Mailer: VM 7.03 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG DougB> My point is simply that users are confused about this current state DougB> of events, and we should do something to make things more clear. And I claim that is impossible. If we add a new variable, users still have to find that variable in the documentation. If users are going to look at the documentation, they will already find (in more places than anything else is documented) the current solution. The fact that they are having difficulties now proves they aren't reading documentation and therefore won't find the new variable either. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 20 11:19:35 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 8BB0637B408 for ; Thu, 20 Jun 2002 11:19:31 -0700 (PDT) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.3/8.12.3) with SMTP id g5KIJNsi019243; Thu, 20 Jun 2002 14:19:27 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Thu, 20 Jun 2002 14:19:23 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Seigo Tanimura Cc: arch@FreeBSD.org Subject: Re: multiple threads for interrupts In-Reply-To: <200206201035.g5KAZ53i029301@rina.r.dl.itc.u-tokyo.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Unfortunately, I'm probably not really qualified to talk much about the swi stuff. But I can say I'd really like to have multiple netisr threads once the lock pushdown on IPv4 is more done :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 20 11:33: 8 2002 Delivered-To: freebsd-arch@freebsd.org Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by hub.freebsd.org (Postfix) with ESMTP id 7A49837B40A; Thu, 20 Jun 2002 11:33:04 -0700 (PDT) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g5KIUkB23173; Thu, 20 Jun 2002 14:30:46 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Thu, 20 Jun 2002 14:30:46 -0400 From: Bosko Milekic To: Robert Watson Cc: Seigo Tanimura , arch@FreeBSD.ORG Subject: Re: multiple threads for interrupts Message-ID: <20020620143046.A23114@unixdaemons.com> References: <200206201035.g5KAZ53i029301@rina.r.dl.itc.u-tokyo.ac.jp> 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 rwatson@FreeBSD.ORG on Thu, Jun 20, 2002 at 02:19:23PM -0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Jun 20, 2002 at 02:19:23PM -0400, Robert Watson wrote: > Unfortunately, I'm probably not really qualified to talk much about the > swi stuff. But I can say I'd really like to have multiple netisr threads > once the lock pushdown on IPv4 is more done :-). As I hinted, I think that this is a reasonable idea. However, we may end up observing that, for certain cases, particularly those such as network device hardware interrupts (which essentially just queue the packet and schedule the software interrupt thread), it is better to wait until the handler is done running and merely re-service it because the second thread is likely to contend with the first anyway, and because that contention may lead to ping-ponging between CPU caches. We may end up seeing that for netisr type stuff, it is better to have multiple threads running in parallel. We may see, also, for example, that it is better to have a maximum of N/m threads running in parallel for an N cpu system (where m < N). I would like to keep the thread pool code around, and possibly see it committed soon, but not have it take effect in all cases just yet, particularly not in the hardware interrupt cases, at least not right now. > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Network Associates Laboratories Regards, -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 20 12:44:33 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hotmail.com (f112.law3.hotmail.com [209.185.241.112]) by hub.freebsd.org (Postfix) with ESMTP id EF30D37B41E for ; Thu, 20 Jun 2002 12:43:40 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 20 Jun 2002 12:43:40 -0700 Received: from 149.99.123.124 by lw3fd.law3.hotmail.msn.com with HTTP; Thu, 20 Jun 2002 19:43:40 GMT X-Originating-IP: [149.99.123.124] From: "Gary Thorpe" To: freebsd-arch@freebsd.org Subject: Re: multiple threads for interrupts Date: Thu, 20 Jun 2002 15:43:40 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Jun 2002 19:43:40.0916 (UTC) FILETIME=[C761C340:01C21892] Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >From: Terry Lambert >To: Seigo Tanimura >CC: arch@FreeBSD.org >Subject: Re: multiple threads for interrupts >Date: Thu, 20 Jun 2002 04:18:24 -0700 > >Seigo Tanimura wrote: > > One solution is to run multiple threads for each of the interrupt > > types. Since I noticed this issue first during my work of network > > locking, I have been tweaking the swi subsystem so that it runs > > multiple threads for an swi type. For those who are interested, the > > patch can be found at: > > > > http://people.FreeBSD.org/~tanimura/patches/swipool.diff.gz > >Benchmarks before and after, demonstrating an improvement? > >-- Terry I am not a kernel programmer, but I have read a paper which concludes that making threads have an "affinity" or "stickiness" to the last CPU it was run on is benifical because it leads to less cache flushing/refilling. Maybe this will be a factor in having multiple threads for interrupt handling? _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 20 13:45:49 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by hub.freebsd.org (Postfix) with ESMTP id AD80837B403 for ; Thu, 20 Jun 2002 13:45:45 -0700 (PDT) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.1/8.12.1) with ESMTP id g5KKjhr4018996 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 20 Jun 2002 13:45:44 -0700 (PDT)?g (envelope-from sam@errno.com)œ Message-ID: <124a01c2189b$72df9cd0$52557f42@errno.com> From: "Sam Leffler" To: Subject: DIAGNOSTIC vs. INVARIANTS Date: Thu, 20 Jun 2002 13:45:43 -0700 Organization: Errno Consulting MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG It seems #ifdef DIAGNOSTIC is not used uniformly in the kernel. Specifically, it seems any code of the form: #ifdef DIAGNOSTIC if (some check) panic("some check failed..."); #endif should instead be controlled by INVARIANTS as in KASSERT(some check, ("some check failed...")); I read DIAGNOSTIC to be intended to control inclusion of code that _prints diagnostic messages_ or similar and not code that does consistency checks. Comments? Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 20 15:32:32 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id DF65337B404 for ; Thu, 20 Jun 2002 15:32:29 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 9DD795362; Fri, 21 Jun 2002 00:32:27 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "Sam Leffler" Cc: Subject: Re: DIAGNOSTIC vs. INVARIANTS References: <124a01c2189b$72df9cd0$52557f42@errno.com> From: Dag-Erling Smorgrav Date: 21 Jun 2002 00:32:26 +0200 In-Reply-To: <124a01c2189b$72df9cd0$52557f42@errno.com> Message-ID: Lines: 10 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Sam Leffler" writes: > I read DIAGNOSTIC to be intended to control inclusion of code that _prints > diagnostic messages_ or similar and not code that does consistency checks. DIAGNOSTICS is also intended for consistency checks that have a significant impact on performance. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 20 16: 1:42 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id E93C237B421 for ; Thu, 20 Jun 2002 16:00:20 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020620230020.ZNWV11426.rwcrmhc51.attbi.com@InterJet.elischer.org>; Thu, 20 Jun 2002 23:00:20 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA32984; Thu, 20 Jun 2002 15:51:57 -0700 (PDT) Date: Thu, 20 Jun 2002 15:51:56 -0700 (PDT) From: Julian Elischer To: Sam Leffler Cc: freebsd-arch@freebsd.org Subject: Re: DIAGNOSTIC vs. INVARIANTS In-Reply-To: <124a01c2189b$72df9cd0$52557f42@errno.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG yes. On Thu, 20 Jun 2002, Sam Leffler wrote: > It seems #ifdef DIAGNOSTIC is not used uniformly in the kernel. > Specifically, it seems any code of the form: > > #ifdef DIAGNOSTIC > if (some check) > panic("some check failed..."); > #endif > > should instead be controlled by INVARIANTS as in > > KASSERT(some check, ("some check failed...")); > > I read DIAGNOSTIC to be intended to control inclusion of code that _prints > diagnostic messages_ or similar and not code that does consistency checks. > > Comments? > > Sam > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 20 16: 4: 1 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by hub.freebsd.org (Postfix) with ESMTP id 211C337B618 for ; Thu, 20 Jun 2002 16:03:32 -0700 (PDT) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.1/8.12.1) with ESMTP id g5KN3Vr4022587 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 20 Jun 2002 16:03:32 -0700 (PDT)?g (envelope-from sam@errno.com)œ Message-ID: <136101c218ae$b2a37c70$52557f42@errno.com> From: "Sam Leffler" To: "Dag-Erling Smorgrav" Cc: References: <124a01c2189b$72df9cd0$52557f42@errno.com> Subject: Re: DIAGNOSTIC vs. INVARIANTS Date: Thu, 20 Jun 2002 16:03:30 -0700 Organization: Errno Consulting MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > "Sam Leffler" writes: > > I read DIAGNOSTIC to be intended to control inclusion of code that _prints > > diagnostic messages_ or similar and not code that does consistency checks. > > DIAGNOSTICS is also intended for consistency checks that have a > significant impact on performance. There are things under DIAGNOSTIC that look to belong under INVARIANTS. It is a good thing to have a set of consistency checks that developers can run but that might be turned off in a production system. This looks to be how INVARIANTS is used. Consistency checks that have a significant performance impact probably should have individual controls or they'll cause the general mechanism to be much less useful. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 20 16:31:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns2.gnf.org (ns2.gnf.org [63.196.132.68]) by hub.freebsd.org (Postfix) with ESMTP id BB20B37B403; Thu, 20 Jun 2002 16:31:41 -0700 (PDT) Received: from mail.gnf.org (smtp.gnf.org [172.25.11.11]) by ns2.gnf.org (8.11.6/8.11.6) with ESMTP id g5KNI6O31508; Thu, 20 Jun 2002 16:18:06 -0700 (PDT) (envelope-from gordon@FreeBSD.org) Received: by mail.gnf.org (Postfix, from userid 888) id 1FC6211E515; Thu, 20 Jun 2002 16:31:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.gnf.org (Postfix) with ESMTP id 1EA4011A572; Thu, 20 Jun 2002 16:31:41 -0700 (PDT) Date: Thu, 20 Jun 2002 16:31:41 -0700 (PDT) From: Gordon Tetlow X-X-Sender: gordont@smtp.gnf.org To: Doug Barton Cc: Terry Lambert , Subject: Re: MFC of src/etc/rc.subr In-Reply-To: <3D1197E0.26BCCA08@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 20 Jun 2002, Doug Barton wrote: > Terry Lambert wrote: > > > > Doug Barton wrote: > > > On Wed, 19 Jun 2002, Gordon Tetlow wrote: > > > > I'm going to MFC src/etc/rc.subr into -STABLE probably tomorrow unless > > > > someone has some grevious reason that it shouldn't. > > > > > > Personally I think it's way too premature to consider this, before we > > > actually have things working in -current. > > > > Since it won't be turned on by default, this should be a > > non-problem. Even if it were turned on, it should *still* > > not be a problem, until people provide ports rc scripts in > > the new format. > > > > I think things *are* working in -current. > > My concern is that people will start writing scripts that use these > interfaces, then we're going to change them. However, if no one else > objects, I suppose it's ok.... Actually, I think this is a good reason. I'm going to think on it some more. I have some ideas I need to flesh out and probably talk with lukem about. -gordon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 20 17:12:43 2002 Delivered-To: freebsd-arch@freebsd.org Received: from corbulon.video-collage.com (corbulon.video-collage.com [64.35.99.179]) by hub.freebsd.org (Postfix) with ESMTP id C886337B410; Thu, 20 Jun 2002 17:12:37 -0700 (PDT) Received: from misha (250-217.customer.cloud9.net [168.100.250.217]) by corbulon.video-collage.com (8.12.2/8.12.2) with ESMTP id g5L0CYQC063139 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 20 Jun 2002 20:12:36 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) X-Authentication-Warning: corbulon.video-collage.com: Host 250-217.customer.cloud9.net [168.100.250.217] claimed to be misha Content-Type: text/plain; charset="iso-8859-1" From: Mikhail Teterin Organization: Virtual Estates, Inc. To: Juli Mallett Subject: feature request for xargs Date: Thu, 20 Jun 2002 20:12:17 -0400 X-Mailer: KMail [version 1.4] References: <200206200706.g5K76M514469@freefall.freebsd.org> <3D1187B7.EFE705F2@FreeBSD.org> <20020620005012.A16541@FreeBSD.ORG> In-Reply-To: <20020620005012.A16541@FreeBSD.ORG> Cc: arch@FreeBSD.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200206202012.17801.mi+mx@aldan.algebra.com> X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thursday 20 June 2002 03:50 am, Juli Mallett wrote: = > > Log: = > > That's right, you can shove your xargs(1) issues in my = > > direction, and also glad to review changes to it. Something like ``xargs -j'' which would spawn off up and wait for up to N processes. Currently it acts as if N was 1. Specifying 0 should mean no limit at all. Flag ``-j'' to resemble similar feature of make. -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 20 17:57: 4 2002 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id 5369637B40A; Thu, 20 Jun 2002 17:57:00 -0700 (PDT) Date: Thu, 20 Jun 2002 17:57:00 -0700 From: Juli Mallett To: Mikhail Teterin Cc: arch@FreeBSD.org Subject: Re: feature request for xargs Message-ID: <20020620175700.A96462@FreeBSD.ORG> References: <200206200706.g5K76M514469@freefall.freebsd.org> <3D1187B7.EFE705F2@FreeBSD.org> <20020620005012.A16541@FreeBSD.ORG> <200206202012.17801.mi+mx@aldan.algebra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <200206202012.17801.mi+mx@aldan.algebra.com>; from mi+mx@aldan.algebra.com on Thu, Jun 20, 2002 at 08:12:17PM -0400 Organisation: The FreeBSD Project X-Alternate-Addresses: , , , X-Affiliated-Projects: FreeBSD, xMach, ircd-hybrid-7 X-Towel: Yes Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Mikhail Teterin escriuréres > On Thursday 20 June 2002 03:50 am, Juli Mallett wrote: > = > > Log: > = > > That's right, you can shove your xargs(1) issues in my > = > > direction, and also glad to review changes to it. > > Something like ``xargs -j'' which would spawn off up and wait for up > to N processes. Currently it acts as if N was 1. Specifying 0 should > mean no limit at all. Flag ``-j'' to resemble similar feature of make. Tim J. Robbins and I have been discussing this for a while, and Tim had a patch. I'm CC'ing him, and I'm sure if he still has diffs, he'll be glad to send them here for review I'm sure. I'd been hesitant on this, until we were clear on how it could and would be used, but an arch@ review is probably enough :) -- Juli Mallett | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger jmallett@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 20 19:24:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 4295237B416; Thu, 20 Jun 2002 19:24:55 -0700 (PDT) Received: from pool0544.cvx21-bradley.dialup.earthlink.net ([209.179.194.34] helo=mindspring.com) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17LE6Y-0004nu-00; Thu, 20 Jun 2002 19:24:54 -0700 Message-ID: <3D128E50.CC2E0387@mindspring.com> Date: Thu, 20 Jun 2002 19:24:16 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Watson Cc: Seigo Tanimura , arch@FreeBSD.org Subject: Re: multiple threads for interrupts References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Robert Watson wrote: > Unfortunately, I'm probably not really qualified to talk much about the > swi stuff. But I can say I'd really like to have multiple netisr threads > once the lock pushdown on IPv4 is more done :-). I can understan SWI threads, to a small extent, when there is a lot of processing that needs to be done; that's how I would do a winmodem driver, were I to try to port one to FreeBSD. I can't understand the fascination with NETISR, however. It should not exist in the first place. If any one doubts this, they really need to contact Van Jacobsen; as Archie Cobbs, since he works at the same company as Van, if you don't have contact information for Van yourself. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 20 19:48:11 2002 Delivered-To: freebsd-arch@freebsd.org Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id BB33437B40E for ; Thu, 20 Jun 2002 19:47:52 -0700 (PDT) Received: from pool0544.cvx21-bradley.dialup.earthlink.net ([209.179.194.34] helo=mindspring.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17LESk-0000n0-00; Thu, 20 Jun 2002 19:47:50 -0700 Message-ID: <3D1293AE.FDEC441D@mindspring.com> Date: Thu, 20 Jun 2002 19:47:10 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Gary Thorpe Cc: freebsd-arch@freebsd.org Subject: Re: multiple threads for interrupts References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Gary Thorpe wrote: > >Seigo Tanimura wrote: > > > One solution is to run multiple threads for each of the interrupt > > > types. Since I noticed this issue first during my work of network > > > locking, I have been tweaking the swi subsystem so that it runs > > > multiple threads for an swi type. For those who are interested, the > > > patch can be found at: > > > > > > http://people.FreeBSD.org/~tanimura/patches/swipool.diff.gz > > > >Benchmarks before and after, demonstrating an improvement? > > > >-- Terry > > I am not a kernel programmer, but I have read a paper which concludes that > making threads have an "affinity" or "stickiness" to the last CPU it was run > on is benifical because it leads to less cache flushing/refilling. Maybe > this will be a factor in having multiple threads for interrupt handling? THat's a general scheduling problem. The solution is well known, and implemented in Dynix, then IRIX, now Linux. Alfred Perlstein has some patches that take it most of the way there, but leave an interlock, by maintaining a global queue. The solution I'm talking about is per CPU scheduling queues, where threads are only migrated between scheduling queues under extraordinary conditiona, so most of the scheduling never requires the locking the FreeBSD-current has today. This solves the affinity problem. I'm not sure the affinity fix solves the NETISR problem, because I think that the issue there is that the affinity you want in that case is mbuf<->cpu affinity. Basically, if you take the network interrupt on CPU 3, then you want to run the NETISR code that is associated with the protocol processing on CPU 3, as well, to avoid cache busting. The way I would suggest doing this is to run the protocol processing up to user space at interrupt time (LRP). This gets rid of NETISR. A lot of people complain that this won't allow you to receive as many packets in a given period of time. They are missing the fact that this only affect the burst rate until poll saturation occurs, at which point in time the number of packets that you receive is in fact clocked by buffer availability, and buffer availability is clocked by the ability of NETISR to process the packets up to the user space boundary, and that in turn is clocked by the ability to process the packets out to the user space programs on the other end of the sockets. What this all boils down to is that you should only permit receive data interrupts to occur at the rate that you can move the data from the wire, all the way through the system, to completion. The feedback process in the absence of available mbufs is to take the interrupt, and then replace the contents of the mubuf receive buffer ring with the new contents. The mbuf's only ever get pushed up the stack if there is a replacement mbuf allocable from the system in order to put on the ring in place of the received mbuf. Effectively, we are talking about receive ring overflow here. If you trace the dependency graph on mbuf availability all the way to user space, you will see that if you are receiving packets faster than you can process them, then you end up spending all your time servicing interrupts, and that takes away from your time to actually push data through. Jeff Mogul of DEC Western Research Laboratories described this as "receiver livelock" back early in the last decade. Luigi's and Jon Lemon's work only partially mitigates the problem. Turning off interrupts doesn't deal with the NETISR triggering, which only occurs when you splx() down from a hardware interrupt level so that the SWL list is run. Running the packets on partially up the stack doesn't resolve the problems up to the user/kernel barrier. So both are only partial solutions. I'm convinced that CPU affinity needs to happen. I'm also convinced that, for the most part, running NETISR in kernel threads, rather than to completion at interrupt, is the wrong way to go. I'm currently agnostic on the idea of whether interrupt threads will help in areas outside of networking. My instinct is that the added contention will mean that they will not. I'm reserving judgement pending seeing real benchmarks. To me, it looks like a lot of people are believing something is better because they are being told that it is better, not because they have personally measured it, gotten better numbers, and have proven to themselves that those better numbers were a result of what they thought they were measuring, rather than an artifact that could be exploited in the old code, as well. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 20 19:55:18 2002 Delivered-To: freebsd-arch@freebsd.org Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by hub.freebsd.org (Postfix) with ESMTP id 05C2E37B411; Thu, 20 Jun 2002 19:55:08 -0700 (PDT) Received: from angelica.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.4/8.12.1) with ESMTP id g5L2sq14040701; Thu, 20 Jun 2002 22:54:52 -0400 (EDT) X-Authentication-Warning: angelica.unixdaemons.com: Host bmilekic@localhost.unixdaemons.com [127.0.0.1] claimed to be angelica.unixdaemons.com Received: (from bmilekic@localhost) by angelica.unixdaemons.com (8.12.4/8.12.1/Submit) id g5L2soOJ040699; Thu, 20 Jun 2002 22:54:50 -0400 (EDT) (envelope-from bmilekic) Date: Thu, 20 Jun 2002 22:54:50 -0400 From: Bosko Milekic To: Terry Lambert Cc: Robert Watson , Seigo Tanimura , arch@FreeBSD.ORG Subject: Re: multiple threads for interrupts Message-ID: <20020620225450.A38506@unixdaemons.com> References: <3D128E50.CC2E0387@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D128E50.CC2E0387@mindspring.com>; from tlambert2@mindspring.com on Thu, Jun 20, 2002 at 07:24:16PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Jun 20, 2002 at 07:24:16PM -0700, Terry Lambert wrote: > Robert Watson wrote: > > Unfortunately, I'm probably not really qualified to talk much about the > > swi stuff. But I can say I'd really like to have multiple netisr threads > > once the lock pushdown on IPv4 is more done :-). [...] > I can't understand the fascination with NETISR, however. It should > not exist in the first place. > > If any one doubts this, they really need to contact Van Jacobsen; > as Archie Cobbs, since he works at the same company as Van, if > you don't have contact information for Van yourself. > > -- Terry That's funny. I brought up the idea of processing network interrupts to completion at the developer summit and Jeffrey Hsu pointed out quite the opposite. He mentionned, and with very good reason, that the longer you spend running the stack like that as soon as you take the interrupt, the easier you'll be in livelock when you start taking a lot of interrupts (it was along those lines (I appologize, Jeffrey, if I didn't quote you exactly here)). If we have a pool of threads available to run the stack, though, perhaps we could do a sort of hybridized thing where we take the interrupt and switch to one of our available threads to process the packet, but once we hit the stack layer, re-enable the source and keep running. That way we could take another interrupt from the same source and we'll at most end up scheduling N threads (where N <= #cpus). To make matters worse, we could even decide to not re-enable the source when we switch to the N'th (final) thread - this way, we may end up preventing total livelock should we hit a storm. Once we run out of threads, we just set the need_service bit and return. Perhaps we'll find that the optimal number of threads to schedule at most at any given time will be something like N = #cpus/2. In any case, this is at best speculative and totally theoretical and we really can't argue these issues right now and expect to reach the correct solution. Once the network stuff is further done, we'll be able to revisit this. Regards, -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 20 20: 6: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by hub.freebsd.org (Postfix) with ESMTP id 27C3137B413 for ; Thu, 20 Jun 2002 20:05:25 -0700 (PDT) Received: from angelica.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.4/8.12.1) with ESMTP id g5L35E14042294; Thu, 20 Jun 2002 23:05:14 -0400 (EDT) X-Authentication-Warning: angelica.unixdaemons.com: Host bmilekic@localhost.unixdaemons.com [127.0.0.1] claimed to be angelica.unixdaemons.com Received: (from bmilekic@localhost) by angelica.unixdaemons.com (8.12.4/8.12.1/Submit) id g5L35EHf042289; Thu, 20 Jun 2002 23:05:14 -0400 (EDT) (envelope-from bmilekic) Date: Thu, 20 Jun 2002 23:05:14 -0400 From: Bosko Milekic To: Terry Lambert Cc: Gary Thorpe , freebsd-arch@FreeBSD.ORG Subject: Re: multiple threads for interrupts Message-ID: <20020620230514.B38506@unixdaemons.com> References: <3D1293AE.FDEC441D@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D1293AE.FDEC441D@mindspring.com>; from tlambert2@mindspring.com on Thu, Jun 20, 2002 at 07:47:10PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Jun 20, 2002 at 07:47:10PM -0700, Terry Lambert wrote: > Gary Thorpe wrote: > > >Seigo Tanimura wrote: > > > > One solution is to run multiple threads for each of the interrupt > > > > types. Since I noticed this issue first during my work of network > > > > locking, I have been tweaking the swi subsystem so that it runs > > > > multiple threads for an swi type. For those who are interested, the > > > > patch can be found at: > > > > > > > > http://people.FreeBSD.org/~tanimura/patches/swipool.diff.gz > > > > > >Benchmarks before and after, demonstrating an improvement? > > > > > >-- Terry > > > > I am not a kernel programmer, but I have read a paper which concludes that > > making threads have an "affinity" or "stickiness" to the last CPU it was run > > on is benifical because it leads to less cache flushing/refilling. Maybe > > this will be a factor in having multiple threads for interrupt handling? > > THat's a general scheduling problem. The solution is well known, > and implemented in Dynix, then IRIX, now Linux. Alfred Perlstein > has some patches that take it most of the way there, but leave an > interlock, by maintaining a global queue. > > The solution I'm talking about is per CPU scheduling queues, where > threads are only migrated between scheduling queues under extraordinary > conditiona, so most of the scheduling never requires the locking the > FreeBSD-current has today. > > This solves the affinity problem. > > I'm not sure the affinity fix solves the NETISR problem, because I > think that the issue there is that the affinity you want in that > case is mbuf<->cpu affinity. Basically, if you take the network > interrupt on CPU 3, then you want to run the NETISR code that is > associated with the protocol processing on CPU 3, as well, to avoid > cache busting. > > The way I would suggest doing this is to run the protocol processing > up to user space at interrupt time (LRP). This gets rid of NETISR. > > A lot of people complain that this won't allow you to receive as > many packets in a given period of time. They are missing the fact > that this only affect the burst rate until poll saturation occurs, > at which point in time the number of packets that you receive is in > fact clocked by buffer availability, and buffer availability is > clocked by the ability of NETISR to process the packets up to the > user space boundary, and that in turn is clocked by the ability to > process the packets out to the user space programs on the other end > of the sockets. > > What this all boils down to is that you should only permit receive > data interrupts to occur at the rate that you can move the data from > the wire, all the way through the system, to completion. > > The feedback process in the absence of available mbufs is to take > the interrupt, and then replace the contents of the mubuf receive > buffer ring with the new contents. The mbuf's only ever get pushed > up the stack if there is a replacement mbuf allocable from the > system in order to put on the ring in place of the received mbuf. > Effectively, we are talking about receive ring overflow here. > > If you trace the dependency graph on mbuf availability all the > way to user space, you will see that if you are receiving packets > faster than you can process them, then you end up spending all > your time servicing interrupts, and that takes away from your > time to actually push data through. > > Jeff Mogul of DEC Western Research Laboratories described this as > "receiver livelock" back early in the last decade. > > Luigi's and Jon Lemon's work only partially mitigates the problem. > Turning off interrupts doesn't deal with the NETISR triggering, > which only occurs when you splx() down from a hardware interrupt > level so that the SWL list is run. Running the packets on partially > up the stack doesn't resolve the problems up to the user/kernel > barrier. So both are only partial solutions. > > > I'm convinced that CPU affinity needs to happen. > > I'm also convinced that, for the most part, running NETISR in > kernel threads, rather than to completion at interrupt, is the > wrong way to go. > > I'm currently agnostic on the idea of whether interrupt threads > will help in areas outside of networking. My instinct is that > the added contention will mean that they will not. I'm reserving > judgement pending seeing real benchmarks. > > To me, it looks like a lot of people are believing something is > better because they are being told that it is better, not because > they have personally measured it, gotten better numbers, and have > proven to themselves that those better numbers were a result of > what they thought they were measuring, rather than an artifact > that could be exploited in the old code, as well. Terry, dude, I can't believe I'm reading this. A lot of the stuff above makes sense but you're telling us to believe you just because you're saying it's better. And then to top it all off, you mention how we shouldn't believe things that people tell us simply because they claim that they are better. That's totally awesome! Have you ever read "Godel, Escher, Bach" by Hofstadter (sp?)? He discusses these self-referring systems in which he detects things he calls "Strange Loops" (well, that's only part of what he discusses, actually). I think I've found a "Strange Loop" in your Email: - Believe me because I'm telling you this is better. - Don't believe people who tell you to believe them because they say that it is better. If I accept the first point, I cannot accept the second without re-defining the meaning of "belief," at the very least. Similarly, if I accept the second point, I cannot accept the first without, again, somehow re-defining the meaning of "belief," at least. > -- Terry Cheers, -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org P.S.: If you haven't read "GEB," I strongly recommend it... it's really a good book. :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 20 20: 7:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from prism.flugsvamp.com (66-191-112-47.mad.wi.charter.com [66.191.112.47]) by hub.freebsd.org (Postfix) with ESMTP id 30A0E37B429 for ; Thu, 20 Jun 2002 20:07:28 -0700 (PDT) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.6/8.11.6) id g5L37CK24875; Thu, 20 Jun 2002 22:07:12 -0500 (CDT) (envelope-from jlemon) Date: Thu, 20 Jun 2002 22:07:12 -0500 From: Jonathan Lemon To: Terry Lambert Cc: Gary Thorpe , freebsd-arch@FreeBSD.ORG Subject: Re: multiple threads for interrupts Message-ID: <20020620220712.E70387@prism.flugsvamp.com> References: <3D1293AE.FDEC441D@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <3D1293AE.FDEC441D@mindspring.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Jun 20, 2002 at 07:47:10PM -0700, Terry Lambert wrote: > The way I would suggest doing this is to run the protocol processing > up to user space at interrupt time (LRP). This gets rid of NETISR. > > A lot of people complain that this won't allow you to receive as > many packets in a given period of time. They are missing the fact > that this only affect the burst rate until poll saturation occurs, > at which point in time the number of packets that you receive is in > fact clocked by buffer availability, and buffer availability is > clocked by the ability of NETISR to process the packets up to the > user space boundary, and that in turn is clocked by the ability to > process the packets out to the user space programs on the other end > of the sockets. > > What this all boils down to is that you should only permit receive > data interrupts to occur at the rate that you can move the data from > the wire, all the way through the system, to completion. > > The feedback process in the absence of available mbufs is to take > the interrupt, and then replace the contents of the mubuf receive > buffer ring with the new contents. The mbuf's only ever get pushed > up the stack if there is a replacement mbuf allocable from the > system in order to put on the ring in place of the received mbuf. > Effectively, we are talking about receive ring overflow here. > > If you trace the dependency graph on mbuf availability all the > way to user space, you will see that if you are receiving packets > faster than you can process them, then you end up spending all > your time servicing interrupts, and that takes away from your > time to actually push data through. > > Jeff Mogul of DEC Western Research Laboratories described this as > "receiver livelock" back early in the last decade. Yes, I believe anyone who has done work in this area is familiar with that technical report. > Luigi's and Jon Lemon's work only partially mitigates the problem. > Turning off interrupts doesn't deal with the NETISR triggering, > which only occurs when you splx() down from a hardware interrupt > level so that the SWL list is run. Running the packets on partially > up the stack doesn't resolve the problems up to the user/kernel > barrier. So both are only partial solutions. Yes. The patches (which I should really make an effort to find out where I put them; maybe to my left under some strawberry jam) were for -stable, and delivered the packet all the way to the socket buffer in interrupt context. They were more intended as a proof of concept than anything else, although I wouldn't have any qualms about committing them to -stable; the corresponding work has to be done in -current first though. I think that an interesting next step(s) would be to start collapsing some of the stack layering a bit. The design notes that VJ outlined for 4.4BSD (which were never completed) look interesting. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 20 20:20:56 2002 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 0594437B40E; Thu, 20 Jun 2002 20:20:52 -0700 (PDT) Received: from pool0544.cvx21-bradley.dialup.earthlink.net ([209.179.194.34] helo=mindspring.com) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17LEyf-0000K3-00; Thu, 20 Jun 2002 20:20:50 -0700 Message-ID: <3D129B66.A4B8D2F3@mindspring.com> Date: Thu, 20 Jun 2002 20:20:06 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Gordon Tetlow Cc: Doug Barton , arch@FreeBSD.org Subject: Re: MFC of src/etc/rc.subr References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Gordon Tetlow wrote: > > My concern is that people will start writing scripts that use these > > interfaces, then we're going to change them. However, if no one else > > objects, I suppose it's ok.... > > Actually, I think this is a good reason. I'm going to think on it some > more. I have some ideas I need to flesh out and probably talk with lukem > about. Not MFC'ing just the ports part (which is all we are talking about here -- personally, I'd like the whole thing in 4.7) will *guarantee* that there will be ports written for 5.x that will not work for 4.7 because they rely upon the new rc system for startup and shutdown. Personally, I don't care if the code is buggy, if it's off by default. Remember that devfs was MFC'ed under the same constraints, so there is precedent. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 20 20:31:37 2002 Delivered-To: freebsd-arch@freebsd.org Received: from grendel.twistedbit.com (grendel.twistedbit.com [199.79.183.5]) by hub.freebsd.org (Postfix) with ESMTP id AA8DF37B40F for ; Thu, 20 Jun 2002 20:31:33 -0700 (PDT) Received: from grendel.twistedbit.com (cp@localhost.tiwstedbit.com [127.0.0.1]) by grendel.twistedbit.com (8.11.3/8.9.3) with ESMTP id g5L3VWw26582 for ; Thu, 20 Jun 2002 21:31:32 -0600 (MDT) (envelope-from cp@grendel.twistedbit.com) Message-Id: <200206210331.g5L3VWw26582@grendel.twistedbit.com> To: freebsd-arch@FreeBSD.ORG Subject: Re: multiple threads for interrupts In-reply-to: Your message of "Thu, 20 Jun 2002 22:07:12 CDT." <20020620220712.E70387@prism.flugsvamp.com> From: Chuck Paterson Date: Thu, 20 Jun 2002 21:31:32 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Just a couple of random notes: The cut of BSD/OS that was handed off to FreeBSD didn't have multiple theads running networks interrupts because there were still these globals used by the tcp stack. With interrupts typically borrowing the context that was in place, BDS/OS on return from the hardware interrupt would typically run the the software interrupt on the same processor as the hardware interrupt. There typically was not a cpu switch type scheduling event. BSD/OS used a thread per interrupt to allow interrupt of higher priority to nest as much as to have multiples hardware interrupts running at a time. We though per cpu run queues were a great idea at BSDI. We didn't do them because we had lots of other stuff to do, and we really had not come up with a good answer to the when do you migrate a process question. How long do you want to let a cpu be idle before you move something on to it? But mainly it was we had lots of other stuff to do first. It seems like the number of threads you want running the network stack is depends upon what your work load is. It doesn't seem like a one answer fits all problem, at least to me. On a dual processor system running 75% user and 25% system it seems like a bad idea to use two processors in the kernel. You don't need the horse power, and you'll likely pick up some lock and cache line contention. Now if you 2 hyper threaded cpus then maybe it would be better to use two of them on the network stack, and two in userland. If you allow two cpus to process packets from the same tcp stream you can end up with packets passing each other. While this isn't suppose to be fatal, lots of stuff doesn't handle it well or at all. Later Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 20 20:42: 3 2002 Delivered-To: freebsd-arch@freebsd.org Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by hub.freebsd.org (Postfix) with ESMTP id 6FA1937B412 for ; Thu, 20 Jun 2002 20:41:59 -0700 (PDT) Received: from angelica.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.4/8.12.1) with ESMTP id g5L3fl14047809; Thu, 20 Jun 2002 23:41:47 -0400 (EDT) X-Authentication-Warning: angelica.unixdaemons.com: Host bmilekic@localhost.unixdaemons.com [127.0.0.1] claimed to be angelica.unixdaemons.com Received: (from bmilekic@localhost) by angelica.unixdaemons.com (8.12.4/8.12.1/Submit) id g5L3flwh047808; Thu, 20 Jun 2002 23:41:47 -0400 (EDT) (envelope-from bmilekic) Date: Thu, 20 Jun 2002 23:41:47 -0400 From: Bosko Milekic To: Jonathan Lemon Cc: Terry Lambert , Gary Thorpe , freebsd-arch@FreeBSD.ORG Subject: Re: multiple threads for interrupts Message-ID: <20020620234147.A44910@unixdaemons.com> References: <3D1293AE.FDEC441D@mindspring.com> <20020620220712.E70387@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020620220712.E70387@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Thu, Jun 20, 2002 at 10:07:12PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Jun 20, 2002 at 10:07:12PM -0500, Jonathan Lemon wrote: > > Luigi's and Jon Lemon's work only partially mitigates the problem. > > Turning off interrupts doesn't deal with the NETISR triggering, > > which only occurs when you splx() down from a hardware interrupt > > level so that the SWL list is run. Running the packets on partially > > up the stack doesn't resolve the problems up to the user/kernel > > barrier. So both are only partial solutions. > > Yes. The patches (which I should really make an effort to find out > where I put them; maybe to my left under some strawberry jam) were > for -stable, and delivered the packet all the way to the socket buffer > in interrupt context. They were more intended as a proof of concept > than anything else, although I wouldn't have any qualms about committing > them to -stable; the corresponding work has to be done in -current first > though. > > I think that an interesting next step(s) would be to start collapsing > some of the stack layering a bit. The design notes that VJ outlined > for 4.4BSD (which were never completed) look interesting. > -- > Jonathan I think that it's too early to make that assumption. As I mentionned, I did bring it up at the summit so I don't think that it's a totally bad idea. To get back to the topic, I think: 1) the swi pool thread stuff is cool and should go in so that it gets to mature some in the repo. We shouldn't make any big switches to use it for all cases, though, at least not yet. 2) if we decide to do go to higher layers with network interrupts then we'll probably need the pool thread stuff anyway, and we ought to consider various tweaks. I have a feeling that it's just a little too early to make reasonable decisions on how to implement this the Right Way just yet. 3) I'm interesting in what Jeffrey Hsu and Jennifer (Gosh, I hope I got her name right!) think about this, as they're currently working actively on locking down the network code. 4) Hi JLemon! Welcome back! -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 20 20:48:16 2002 Delivered-To: freebsd-arch@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 7E1BA37B40F for ; Thu, 20 Jun 2002 20:48:13 -0700 (PDT) Received: from pool0544.cvx21-bradley.dialup.earthlink.net ([209.179.194.34] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 17LFP1-0005P6-00; Thu, 20 Jun 2002 20:48:03 -0700 Message-ID: <3D12A1CC.988B23D0@mindspring.com> Date: Thu, 20 Jun 2002 20:47:24 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bosko Milekic Cc: Gary Thorpe , freebsd-arch@FreeBSD.ORG Subject: Re: multiple threads for interrupts References: <3D1293AE.FDEC441D@mindspring.com> <20020620230514.B38506@unixdaemons.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bosko Milekic wrote: > I think > I've found a "Strange Loop" in your Email: > > - Believe me because I'm telling you this is better. > - Don't believe people who tell you to believe them because they say that > it is better. > > If I accept the first point, I cannot accept the second without > re-defining the meaning of "belief," at the very least. Similarly, if I > accept the second point, I cannot accept the first without, again, > somehow re-defining the meaning of "belief," at least. Actually, I don't have a loop. What I'm saying is: - People are saying A is better - Other people are implementing A on faith alone - My personal belief is that B is better - Before anything becomes a part of FreeBSD, whether it be A or B, I'd like to see some benchmarks proving it's better. If there's a loop, maybe it's: "I'm telling you to believe that you should not believe things without benchmarks" Of course, I have no benchmarks to prove that benchmarks are really necessary or useful... 8-). I do, though, have lots of papers on receiver livelock that I've posted the references to before. The problem there is that most people don't read papers. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 20 21: 2:30 2002 Delivered-To: freebsd-arch@freebsd.org Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by hub.freebsd.org (Postfix) with ESMTP id 8E71737B405 for ; Thu, 20 Jun 2002 21:02:26 -0700 (PDT) Received: from angelica.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.4/8.12.1) with ESMTP id g5L42A14051145; Fri, 21 Jun 2002 00:02:10 -0400 (EDT) X-Authentication-Warning: angelica.unixdaemons.com: Host bmilekic@localhost.unixdaemons.com [127.0.0.1] claimed to be angelica.unixdaemons.com Received: (from bmilekic@localhost) by angelica.unixdaemons.com (8.12.4/8.12.1/Submit) id g5L42Ag5051144; Fri, 21 Jun 2002 00:02:10 -0400 (EDT) (envelope-from bmilekic) Date: Fri, 21 Jun 2002 00:02:10 -0400 From: Bosko Milekic To: Terry Lambert Cc: Gary Thorpe , freebsd-arch@FreeBSD.ORG Subject: Re: multiple threads for interrupts Message-ID: <20020621000210.A48838@unixdaemons.com> References: <3D1293AE.FDEC441D@mindspring.com> <20020620230514.B38506@unixdaemons.com> <3D12A1CC.988B23D0@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D12A1CC.988B23D0@mindspring.com>; from tlambert2@mindspring.com on Thu, Jun 20, 2002 at 08:47:24PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Jun 20, 2002 at 08:47:24PM -0700, Terry Lambert wrote: [...] > I do, though, have lots of papers on receiver livelock that I've > posted the references to before. The problem there is that most > people don't read papers. I think that more of the problem is that some people do read papers and, what's more, understand them; however, what these people are actually looking for is not more references to papers, but implementation of the concepts presented in those papers for FreeBSD, proving that those concepts also apply to _our_ system. Certain approaches work well with others, and different approaches may work less well. I'm not claiming that your suggestions are bad, I'm just stating that they shouldn't be taken as being totally correct for us as we cannot adequately evaluate them right now [*]. However, you did initially mention that it would be good to see some sort of evaluation happen, and so perhaps I just misunderstood you and wrongly interpreted you once you started to make claims that seemed to suggest (to me) without a doubt that your solution is THE best one. If that is indeed the case, then I appologize. I maintain the "GEB" is a book worth reading, though. :-) [*] In fact, Chuck just posted in response to this thread and made some very good points regarding performance, and how we may find that the optimal solution is different for different SMP configurations. > -- Terry -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 20 21:18: 5 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 0BC2737B40A for ; Thu, 20 Jun 2002 21:17:00 -0700 (PDT) Received: from pool0544.cvx21-bradley.dialup.earthlink.net ([209.179.194.34] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17LFqp-00005q-00; Thu, 20 Jun 2002 21:16:47 -0700 Message-ID: <3D12A886.425D8231@mindspring.com> Date: Thu, 20 Jun 2002 21:16:06 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bosko Milekic Cc: Gary Thorpe , freebsd-arch@FreeBSD.ORG Subject: Re: multiple threads for interrupts References: <3D1293AE.FDEC441D@mindspring.com> <20020620230514.B38506@unixdaemons.com> <3D12A1CC.988B23D0@mindspring.com> <20020621000210.A48838@unixdaemons.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bosko Milekic wrote: > On Thu, Jun 20, 2002 at 08:47:24PM -0700, Terry Lambert wrote: > [...] > > I do, though, have lots of papers on receiver livelock that I've > > posted the references to before. The problem there is that most > > people don't read papers. > > I think that more of the problem is that some people do read papers > and, what's more, understand them; however, what these people are > actually looking for is not more references to papers, but > implementation of the concepts presented in those papers for FreeBSD, > proving that those concepts also apply to _our_ system. Well, I've suggested the porting of the old LRP (non-RESCON) code to FreeBSD already, as a project. If you are willing to run 4.0 or 4.3, there are implementations of the LRP code for both, from Rice University and Duke University. Their licenses are unfortunately anti-commercial, requiring that the user contact the Rice University Office of Technology Transfer, unless you are doing a port of the FreeBSD 2.2 implementation. If you just want the concept proven, and are willing to run with FreeBSD 4.3, then I would suggest the Duke University code, which I believe proves the concept of LRP nicely. > Certain approaches work well with others, and different approaches may > work less well. I'm not claiming that your suggestions are bad, I'm > just stating that they shouldn't be taken as being totally correct for > us as we cannot adequately evaluate them right now [*]. Here is the FreeBSD 4.3 LRP-RESCON code: http://www.cs.duke.edu/~anderson/freebsd/rescon/ > However, you did initially mention that it would be good to see some > sort of evaluation happen, and so perhaps I just misunderstood you and > wrongly interpreted you once you started to make claims that seemed to > suggest (to me) without a doubt that your solution is THE best one. Well, it is. 8-). Actually, I forward-ported the LRP code from Rice FreeBSD 2.2 to FreeBSD 4.4 for a previous employer, and benchmarked it. Unfortunately, the code is unlikely to ever see the light of day, like some of the work Jon Lemon has done for Cisco. 8-(. However, I can say it benchmarked out at significantly better performance than the non-LRP FreeBSD stack. Under oppressive load, the overall system was around a factor of 4 faster on connections per second, which, even given the integration of the SYN cache code, is probably significant, since that code runs at NETISR. > If that is indeed the case, then I appologize. I maintain the "GEB" > is a book worth reading, though. :-) It's a good book. I got my copy a very long time ago (1981); I also recommend "The Mind's I" and "The Emperor's New Mind". 8-). > [*] In fact, > Chuck just posted in response to this thread and made some very good > points regarding performance, and how we may find that the optimal > solution is different for different SMP configurations. I saw that. I need to think some of them over. I think I have a fix for the migration issue he references. It's solves the problem by avoiding locking unless there's actual migration going on. The migration policy is a seperate issue, and can be dealt with totally seperately. I'd suggest starting with a simple two handed clock algorithm, and getting more complicated after seeing what that does. I'll probably have more to say after I've slept on his posting. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 20 21:58:16 2002 Delivered-To: freebsd-arch@freebsd.org Received: from castle.jp.FreeBSD.org (castle.jp.FreeBSD.org [210.226.20.15]) by hub.freebsd.org (Postfix) with ESMTP id 2E53E37B401 for ; Thu, 20 Jun 2002 21:58:11 -0700 (PDT) Received: from localhost (localhost [::1]) by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) with ESMTP/inet6 id g5L4w9N89838 for ; Fri, 21 Jun 2002 13:58:09 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) X-User-Agent: Mew/1.94.2 XEmacs/21.5 (bamboo) X-FaceAnim: (-O_O-)(O_O- )(_O- )(O- )(- -)( -O)( -O_)( -O_O)(-O_O-) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 39 From: Makoto Matsushita To: arch@FreeBSD.org Subject: Installing XFree86 package via sysinstall: need X wrapper or not? Date: Fri, 21 Jun 2002 13:58:06 +0900 Message-Id: <20020621135806Z.matusita@jp.FreeBSD.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I've heard that some users forget to install X wrapper while installing FreeBSD to a fresh PC. As a result, they can't run X server with startx. When our X distribution was XFree86 3.x, there was no problem with startx since X server has a suid bit -- for newbies, current sysinstall breaks some compatibilities. We can fix this by RUN_DEPENDS lines of ports/x11/XFree86-4/Makefile. However, it makes another problem that "hey, XFree86-4 ports install X wrapper which I don't used, no thankyou." IMHO this problem can be treated as "problem while installing XFree86 via sysinstall," here is a patch to teach sysinstall to install the X wrapper package after XFree86 package is installed. Any comments and objections are welcome. If there is no objection, I'll commit it later (maybe next week or so). -- - Makoto `MAR' Matsushita Index: install.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/sysinstall/install.c,v retrieving revision 1.321 diff -u -r1.321 install.c --- install.c 2 Apr 2002 20:42:52 -0000 1.321 +++ install.c 21 Jun 2002 04:56:18 -0000 @@ -880,6 +880,9 @@ dialog_clear_norefresh(); msgNotify("Installing XFree86 package..."); i = package_add("XFree86-4"); + if (DITEM_STATUS(i) == DITEM_SUCCESS) { + i |= package_add("wrapper"); + } restorescr(w); return i; } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 20 23:40:42 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 6373837B436 for ; Thu, 20 Jun 2002 23:40:08 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020621064008.JZDY11659.rwcrmhc53.attbi.com@InterJet.elischer.org>; Fri, 21 Jun 2002 06:40:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA34745; Thu, 20 Jun 2002 23:28:05 -0700 (PDT) Date: Thu, 20 Jun 2002 23:28:04 -0700 (PDT) From: Julian Elischer To: Terry Lambert Cc: Gary Thorpe , freebsd-arch@freebsd.org Subject: Re: multiple threads for interrupts In-Reply-To: <3D1293AE.FDEC441D@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 20 Jun 2002, Terry Lambert wrote: > Gary Thorpe wrote: > > >Seigo Tanimura wrote: > > THat's a general scheduling problem. The solution is well known, > and implemented in Dynix, then IRIX, now Linux. Alfred Perlstein > has some patches that take it most of the way there, but leave an > interlock, by maintaining a global queue. > > The solution I'm talking about is per CPU scheduling queues, where > threads are only migrated between scheduling queues under extraordinary > conditiona, so most of the scheduling never requires the locking the > FreeBSD-current has today. > Per CPU scheduling queues are I think over-rated.. it turns out that you need to have quite a lot of leakage between the queues to get a real priority based system, otherwise you have processor A running a sequence of threads that are lower in priority than threads in Processor B's run queue. To get around this you need to let processor A steal threads from Processor B's queue. Once you have this then it rapidly escalates into a mess. It may be worth while if you have 64 or 32 processors but for less than that it complicates things more than you win.. > This solves the affinity problem. yes, but it introduces synchronisation problems that were not there before.. You still have to lock the other queues while you check that you are not running low prio threads to teh disadvantage of Hi prioones elsewhere, and then since any processor can want to look at any other processor's queue, you get lock-order problems. These can be worked around but it's not a trivial problem, and I'm not implementing them for the forst version of KSEs. > > I'm not sure the affinity fix solves the NETISR problem, because I > think that the issue there is that the affinity you want in that > case is mbuf<->cpu affinity. Basically, if you take the network > interrupt on CPU 3, then you want to run the NETISR code that is > associated with the protocol processing on CPU 3, as well, to avoid > cache busting. > You have both data and instrauction caches to consider.. 2 processors running the net stack means that you are flushing stuff out of the instruction caches of 2 processors. This would degrade other stuff. > The way I would suggest doing this is to run the protocol processing > up to user space at interrupt time (LRP). This gets rid of NETISR. maybe.. > > > What this all boils down to is that you should only permit receive > data interrupts to occur at the rate that you can move the data from > the wire, all the way through the system, to completion. if it were a netgraph problem, I would push the data as far as I could without hitting a blocking lock, at which point it would be handled asynchronsly thereafter.. > > I'm convinced that CPU affinity needs to happen. Somewhat though I'm coming to believe that per cpu queues is not the way to do it.. > > I'm also convinced that, for the most part, running NETISR in > kernel threads, rather than to completion at interrupt, is the > wrong way to go. Mach did it that way. (threads). It's not necessarily right to push all the way up in one go. My personal opinion is that it shoudl go 'as far as it can' and that that may not be all the way up all the time.... > To me, it looks like a lot of people are believing something is > better because they are being told that it is better, not because > they have personally measured it, gotten better numbers, and have > proven to themselves that those better numbers were a result of > what they thought they were measuring, rather than an artifact > that could be exploited in the old code, as well. one could say that about PCPU queues..... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 21 0: 1:42 2002 Delivered-To: freebsd-arch@freebsd.org Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by hub.freebsd.org (Postfix) with ESMTP id BC0F937B490 for ; Fri, 21 Jun 2002 00:00:19 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020621070018.BUEY1547.sccrmhc02.attbi.com@InterJet.elischer.org>; Fri, 21 Jun 2002 07:00:18 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA34799; Thu, 20 Jun 2002 23:42:32 -0700 (PDT) Date: Thu, 20 Jun 2002 23:42:30 -0700 (PDT) From: Julian Elischer To: Terry Lambert Cc: Bosko Milekic , Gary Thorpe , freebsd-arch@FreeBSD.ORG Subject: Re: multiple threads for interrupts In-Reply-To: <3D12A886.425D8231@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG terry.... you know mate, it would be a Good Thing (tm) if you got back int ocoding... and I don;t mean codimg for that box in you apartment, but coding so as to provide distinct reviewable patches for FreeBSD or the topics you are interested in.. I know your excuses include: 1/ your machines are not running -current 2/ you are coding on an incompatible set of patches at teh moment 3/ you, like the rest of us have time constraints with work etc. but: could you tone down teh lectures a bit until you can actually start doing things to help with the load? At least BDE is starting to commit things again which makes it a much less annoying event to get a 'comentary' on one's style bugs when one commits, because one knows the author is actually committing things himself these days. (hopefully even more(!)) but you have not submitted code for so long that it makes what you say less 'compelling'. If YOU were to come up with a set of 'swith-on'able (and switch-offable) set of patches on any of the topics you find yourself discoursing on, I'm sure that everyone would be thrilled to give them a try. s'nuff.. ok get to the coding wheel.. On Thu, 20 Jun 2002, Terry Lambert wrote: > Bosko Milekic wrote: > > On Thu, Jun 20, 2002 at 08:47:24PM -0700, Terry Lambert wrote: > > [...] > > > I do, though, have lots of papers on receiver livelock that I've > > > posted the references to before. The problem there is that most > > > people don't read papers. > > > > I think that more of the problem is that some people do read papers > > and, what's more, understand them; however, what these people are > > actually looking for is not more references to papers, but > > implementation of the concepts presented in those papers for FreeBSD, > > proving that those concepts also apply to _our_ system. > > Well, I've suggested the porting of the old LRP (non-RESCON) > code to FreeBSD already, as a project. > > If you are willing to run 4.0 or 4.3, there are implementations > of the LRP code for both, from Rice University and Duke University. > Their licenses are unfortunately anti-commercial, requiring that > the user contact the Rice University Office of Technology Transfer, > unless you are doing a port of the FreeBSD 2.2 implementation. > > If you just want the concept proven, and are willing to run with > FreeBSD 4.3, then I would suggest the Duke University code, which > I believe proves the concept of LRP nicely. > > > > Certain approaches work well with others, and different approaches may > > work less well. I'm not claiming that your suggestions are bad, I'm > > just stating that they shouldn't be taken as being totally correct for > > us as we cannot adequately evaluate them right now [*]. > > Here is the FreeBSD 4.3 LRP-RESCON code: > > http://www.cs.duke.edu/~anderson/freebsd/rescon/ > > > > > However, you did initially mention that it would be good to see some > > sort of evaluation happen, and so perhaps I just misunderstood you and > > wrongly interpreted you once you started to make claims that seemed to > > suggest (to me) without a doubt that your solution is THE best one. > > Well, it is. 8-). > > Actually, I forward-ported the LRP code from Rice FreeBSD 2.2 to > FreeBSD 4.4 for a previous employer, and benchmarked it. > > Unfortunately, the code is unlikely to ever see the light of day, > like some of the work Jon Lemon has done for Cisco. 8-(. However, > I can say it benchmarked out at significantly better performance > than the non-LRP FreeBSD stack. Under oppressive load, the overall > system was around a factor of 4 faster on connections per second, > which, even given the integration of the SYN cache code, is probably > significant, since that code runs at NETISR. > > > > If that is indeed the case, then I appologize. I maintain the "GEB" > > is a book worth reading, though. :-) > > It's a good book. I got my copy a very long time ago (1981); I also > recommend "The Mind's I" and "The Emperor's New Mind". 8-). > > > > [*] In fact, > > Chuck just posted in response to this thread and made some very good > > points regarding performance, and how we may find that the optimal > > solution is different for different SMP configurations. > > I saw that. I need to think some of them over. I think I have a > fix for the migration issue he references. It's solves the problem > by avoiding locking unless there's actual migration going on. The > migration policy is a seperate issue, and can be dealt with totally > seperately. I'd suggest starting with a simple two handed clock > algorithm, and getting more complicated after seeing what that does. > > I'll probably have more to say after I've slept on his posting. > > -- Terry > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 21 1: 0:27 2002 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 2EE8937B40C for ; Fri, 21 Jun 2002 00:59:58 -0700 (PDT) Received: from pool0077.cvx21-bradley.dialup.earthlink.net ([209.179.192.77] helo=mindspring.com) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17LJKe-0004rd-00; Fri, 21 Jun 2002 00:59:48 -0700 Message-ID: <3D12DCA9.A5EB415C@mindspring.com> Date: Fri, 21 Jun 2002 00:58:33 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Gary Thorpe , freebsd-arch@freebsd.org Subject: Re: multiple threads for interrupts References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer wrote: > Per CPU scheduling queues are I think over-rated.. > it turns out that you need to have quite a lot of leakage between the > queues to get a real priority based system, otherwise you > have processor A running a sequence of threads that are lower in priority > than threads in Processor B's run queue. To get around this you need > to let processor A steal threads from Processor B's queue. > Once you have this then it rapidly escalates into a mess. It may be worth > while if you have 64 or 32 processors but for less than that it > complicates things more than you win.. Scheduling priority is not a facist dictatorship. You sort of imply that it should be, where *every* process with priority "A" *must* be scheduled before *every* process with priority "B". It's perfectly fine to make the decisions statistically. The current system has user specified priorities which are merely hints to the system. I will go further: it is *preferrable* to make the decision statistically... you are less likely damage locality by migrating processes for reasons of a short term imbalance. The idea of a "pull model" for migration is inherently flawed. It requires that one CPU's scheduler be able to reach into the most contended region of another CPU's scheduler queue (the head, where policy dictates that the next process that *should* be run is located). To do this implies a globally accessible lock, that is locally asserted and deasserted on each local access. It implies that on all CPU's participating in the protocol. > > This solves the affinity problem. > > yes, but it introduces synchronisation problems that were not there before.. > > You still have to lock the other queues while you check that you are not > running low prio threads to teh disadvantage of Hi prioones elsewhere, > and then since any processor can want to look at any other processor's > queue, you get lock-order problems. > > These can be worked around but it's not a trivial problem, and > I'm not implementing them for the forst version of KSEs. I thought we were on the third version... milestone 3. And it's totally independent of KSE's, I think. Personally, I thinks it *is* a trivial problem. Here is some pseudo-code for a per-CPU scheduler loop: /* * Migrate process that have been *pushed* to us (if any) * into the local scheduler queue */ IF cpu_1_migrate_queue != NULL LOCK(cpu_1_migrate_queue) local_migrate_queue = cpu_1_migrate_queue cpu_1_migrate_queue = NULL UNLOCK(migrate_queue) FOR_EACH_ELEMENT(local_migrate_queue) ADD_TO_LOCAL_SCHEDULER() ENDIF /* * Examine per CPU load figure of merit; this figure of * merit is statistical; therefore examination of it need * not be locked. */ min = this_cpu_figure_of_merit mincpu = inavlid FOR_EACH(per_cpu_figure_of_merit) IF min > figure mincpu = figure_cpu min = figure ENDIF IF (this_cpu_figure_of_merit - min) > acceptable_difference /* * Migrate a process from this CPU to the least * loaded CPU. */ process = REMOVE(cpu_1_shecduler_queue) LOCK(mincpu_migrate_queue) INSERT(process,mincpu_migrate_queue) UNLOCK(migrate_queue) ENDIF /* * Update stats */ this_cpu_ficure_of_merit = XXX /* * Do per CPU scheduling */ DOSCHEDULE() ...no locks required for the scheduler, unless a migration is in progress, and the contention is never global, it's only between two CPUs: the migrate from, and the target being migrated to. This is a push model. It resolves all of the issues you raise, except that of migration policy, which is based on the figure of merit calculation and the threshold for the acceptable level of difference. For threads, there may also be an issue of wanting negaffinity for a given thread group (process), but this is easily handled inside this model. > > I'm not sure the affinity fix solves the NETISR problem, because I > > think that the issue there is that the affinity you want in that > > case is mbuf<->cpu affinity. Basically, if you take the network > > interrupt on CPU 3, then you want to run the NETISR code that is > > associated with the protocol processing on CPU 3, as well, to avoid > > cache busting. > > You have both data and instrauction caches to consider.. > 2 processors running the net stack means that > you are flushing stuff out of the instruction caches of 2 processors. > This would degrade other stuff. Yes, it would, which is why I dislike it. If you look at the work Ingo Molnar has accomplished with getting the interrupt processing, the TCP stack, and all the intersting data, to live inside the CPU cache for the "Tux" in-kernel HTTP server, you will see what can be accomplished when you don't risk ping-ponging processes all over the place for no good reason. > > The way I would suggest doing this is to run the protocol processing > > up to user space at interrupt time (LRP). This gets rid of NETISR. > > maybe.. Yes, it's a big "maybe". Load up 4.3 and try it with and without LRP, and then make a decision when you have numbers in hand. > > What this all boils down to is that you should only permit receive > > data interrupts to occur at the rate that you can move the data from > > the wire, all the way through the system, to completion. > > if it were a netgraph problem, I would push the data as far as I could > without hitting a blocking lock, at which point it would be handled > asynchronsly thereafter.. Yes. That's one of the problems with the earlier suggestion that TCP and IP should be implemented as netgraph nodes. THere will be at least a unidirectional stall which will have to occur during the processing at the boundary between the protocol layers in order to allow the processing to run to completion. You really can't involve netgraph (or Streams, on SVR4) without causing such a stall. The stall introduce with the Streams based ODI drivers replacing the native drivers for UnixWare 2.0 (SVR4.2) ended up costing us a full 35% latency increase. > > I'm convinced that CPU affinity needs to happen. > > Somewhat though I'm coming to believe that per cpu queues is not the way > to do it.. Any approach which requires direct modification of the scheduler policy to achieve affinity is intrinsically broken. Linux may claim thread group affinit works, but it is very easy to find degenerate cases which will result either in starvation deadlock for the non-group member processes, or for unnecessary thrashing, for the group members. THe benefit to the FreeBSD use of scheduler activations -- that once a quantum is allocated, it remains allocated, until it is used up, or there is no more work to do -- can easily be lost, if you try to enforce strict priority ordering between all threads. > > I'm also convinced that, for the most part, running NETISR in > > kernel threads, rather than to completion at interrupt, is the > > wrong way to go. > > Mach did it that way. (threads). > > It's not necessarily right to push all the way up in one go. > My personal opinion is that it shoudl go 'as far as it can' > and that that may not be all the way up all the time.... MACH is widely acknowledged to have failed in a lot of its goals, particularly with threading, but also with the necessity for protection domain crossing for external pagers, and the need to support message passing (now that it turns out that all modern computers are not Northern Telecom DV1's, and so message passing ends up not being supported by the hardware bus). Chorus got a lot of things right that MACH ended up getting wrong. Neither one of them are sterling ecxamples of why one should use threads to handle interrupts. > > To me, it looks like a lot of people are believing something is > > better because they are being told that it is better, not because > > they have personally measured it, gotten better numbers, and have > > proven to themselves that those better numbers were a result of > > what they thought they were measuring, rather than an artifact > > that could be exploited in the old code, as well. > > one could say that about PCPU queues..... On the other hand, we have proof by demonstration from Sequent and SGI on per CPU run queues, with real statistics and may research papers... Can you point me at one or two on kernel threads for interrupt processing? 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 21 1:20:39 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 0D08F37B415 for ; Fri, 21 Jun 2002 01:20:16 -0700 (PDT) Received: from pool0077.cvx21-bradley.dialup.earthlink.net ([209.179.192.77] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17LJeD-0001eo-00; Fri, 21 Jun 2002 01:20:01 -0700 Message-ID: <3D12E182.67F91292@mindspring.com> Date: Fri, 21 Jun 2002 01:19:14 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Bosko Milekic , Gary Thorpe , freebsd-arch@FreeBSD.ORG Subject: Re: multiple threads for interrupts References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer wrote: > you know mate, it would be a Good Thing (tm) > if you got back int ocoding... and I don;t mean codimg for that box in you > apartment, but coding so as to provide distinct reviewable patches for > FreeBSD or the topics you are interested in.. > > I know your excuses include: > 1/ your machines are not running -current Actually, the problem there is that patches against -stable are not considered acceptable because -current is so far and away from -stable that it's impossible to reconcile... there's more than a year and a half's difference in the code bases -- almost two years. > 2/ you are coding on an incompatible set of patches at teh moment Not a problem. I have disk space. Checking out multiple source trees isn't a problem (or wasn't, until the toolchain diverged). > 3/ you, like the rest of us have time constraints with work etc. Can't argue that one. > but: > > could you tone down teh lectures a bit until you can actually > start doing things to help with the load? > At least BDE is starting to commit things again which makes it > a much less annoying event to get a 'comentary' on one's style bugs > when one commits, because one knows the author is actually committing > things himself these days. (hopefully even more(!)) > > but you have not submitted code > for so long that it makes what you say less 'compelling'. I posted a corrective patch for the _BSD_WHAR_T_ definition problem with G++ 3.1 just the other day. A couple of months back, I posted patches to several major ethernet drivers to support soft interrupt coelescing (they were even integrated). Also did code review on the patches that Mario posted, and pointed out that they broke SIGPIPE delivery on write(2) to sockets. Etc. > If YOU were to come up with a set of 'swith-on'able (and switch-offable) > set of patches on any of the topics you find yourself discoursing on, > I'm sure that everyone would be thrilled to give them a try. For some of the things, there would need to be some baseline changes first. It's necessary to be able to set attributes on an address family structure for it to be properly integrated, rather than just being a proof of concept implementation. You willing to commit some struct changes, and some changes to uipc_*.c, before something can even get properly started? They would look like gratuitous changes, to start with... (fair warning). > s'nuff.. > > ok > > get to the coding wheel.. My LRP suggestion was made in the context of a graduate student looking for a project to work on. You really need to keep the subject lines straight, rather than dumping "all of Terry's posts" into a single bin, and treating them as if they were all about things I think other people should do to FreeBSD. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 21 7:33:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from corbulon.video-collage.com (corbulon.video-collage.com [64.35.99.179]) by hub.freebsd.org (Postfix) with ESMTP id 8864E37B40A; Fri, 21 Jun 2002 07:33:24 -0700 (PDT) Received: from misha (250-217.customer.cloud9.net [168.100.250.217]) by corbulon.video-collage.com (8.12.2/8.12.2) with ESMTP id g5LEXKQC039142 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Fri, 21 Jun 2002 10:33:22 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) X-Authentication-Warning: corbulon.video-collage.com: Host 250-217.customer.cloud9.net [168.100.250.217] claimed to be misha Content-Type: text/plain; charset="iso-8859-1" From: Mikhail Teterin Organization: Virtual Estates, Inc. To: Juli Mallett Subject: Re: feature request for xargs Date: Fri, 21 Jun 2002 10:33:03 -0400 X-Mailer: KMail [version 1.4] Cc: arch@FreeBSD.ORG References: <200206200706.g5K76M514469@freefall.freebsd.org> <200206202012.17801.mi+mx@aldan.algebra.com> <20020620175700.A96462@FreeBSD.ORG> In-Reply-To: <20020620175700.A96462@FreeBSD.ORG> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200206211033.03948.mi+mx@aldan.algebra.com> X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thursday 20 June 2002 08:57 pm, Juli Mallett wrote: = > Something like ``xargs -j'' which would spawn off up and wait for up = > to N processes. Currently it acts as if N was 1. Specifying 0 should = > mean no limit at all. Flag ``-j'' to resemble similar feature of make. = = Tim J. Robbins and I have been discussing this for a while, and Tim had = a patch. I'm CC'ing him, and I'm sure if he still has diffs, he'll be = glad to send them here for review I'm sure. = = I'd been hesitant on this, until we were clear on how it could and would = be used, but an arch@ review is probably enough :) Here is the usage, for which I currently use make(1). Every once in a while, I have to process a big collection of images -- scanned and/or taken with a digital camera. A scripts I have, work on one image at a time, but I have two processors, so -- with the Makefile -- I do ``make -j2''. This works good, but may be done simpler with something like echo *.JPG | xargs -n1 -j2