From owner-freebsd-arch Sun Mar 11 7: 3: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 8691137B718 for ; Sun, 11 Mar 2001 07:03:04 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id CAA08272; Mon, 12 Mar 2001 02:03:02 +1100 Date: Mon, 12 Mar 2001 02:02:25 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: arch@FreeBSD.ORG Cc: Warner Losh Subject: Re: Breaking up make.conf In-Reply-To: <20010310170844.C36413@dragon.nuxi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 10 Mar 2001, David O'Brien wrote: > On Thu, Mar 08, 2001 at 09:49:30PM -0700, Warner Losh wrote: > > Also, the previous patches don't include bsd.own.mk, which we depend > > on being included to define OBJFORMAT. So I backed that part of them > > out. > > Rather than all this funk, why not do what the Ports Collection does -- > have its own bsd.*.mk file. So make it that /usr/share/bsd.*.mk all > include /etc/world-make.conf, and sys.mk does not. Thus if I am just > using BSD make, but not all its bsd.*.mk frame work, I won't get bogus > CFLAGS settings. > > I.E., lets assume /usr/share/mk/bsd.*.mk is the domain of /usr/src only. The main reason is that make.conf often needs to be included before parsing Makefiles, or at least at the start of Makefiles, but most Makefiles include bsd.*.mk last. The ports .mk files configure paths much better than sys.mk. They use ${PORTSDIR} but sys.mk hard-codes 3 absolute paths in /etc. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 12 10:33:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 182A537B719 for ; Mon, 12 Mar 2001 10:33:24 -0800 (PST) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id LAA26928; Mon, 12 Mar 2001 11:33:21 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id LAA07284; Mon, 12 Mar 2001 11:33:19 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15021.5742.621060.580501@nomad.yogotech.com> Date: Mon, 12 Mar 2001 11:33:18 -0700 (MST) To: Warner Losh Cc: arch@FreeBSD.ORG Subject: Re: Breaking up make.conf In-Reply-To: <200103110145.f2B1jOI23270@harmony.village.org> References: <20010310170844.C36413@dragon.nuxi.com> <200103090430.f294Ucs04824@billy-club.village.org> <20010308201422.A94052@mollari.cthul.hu> <200103090241.SAA27525@gndrsh.dnsmgr.net> <200103090349.f293nGs04577@billy-club.village.org> <200103090449.f294nUs06142@billy-club.village.org> <200103110145.f2B1jOI23270@harmony.village.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > : I.E., lets assume /usr/share/mk/bsd.*.mk is the domain of /usr/src only. > > I think that's a bad assumption. I know of several projects outside > of /usr/src that use bsd.*.mk. They should use something besides bsd.*.mk, aka ts.*.mk? :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 12 11:14:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 2BEAD37B718 for ; Mon, 12 Mar 2001 11:14:10 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f2CJDtI38620; Mon, 12 Mar 2001 12:13:55 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200103121913.f2CJDtI38620@harmony.village.org> To: nate@yogotech.com (Nate Williams) Subject: Re: Breaking up make.conf Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Mon, 12 Mar 2001 11:33:18 MST." <15021.5742.621060.580501@nomad.yogotech.com> References: <15021.5742.621060.580501@nomad.yogotech.com> <20010310170844.C36413@dragon.nuxi.com> <200103090430.f294Ucs04824@billy-club.village.org> <20010308201422.A94052@mollari.cthul.hu> <200103090241.SAA27525@gndrsh.dnsmgr.net> <200103090349.f293nGs04577@billy-club.village.org> <200103090449.f294nUs06142@billy-club.village.org> <200103110145.f2B1jOI23270@harmony.village.org> Date: Mon, 12 Mar 2001 12:13:55 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <15021.5742.621060.580501@nomad.yogotech.com> Nate Williams writes: : > : I.E., lets assume /usr/share/mk/bsd.*.mk is the domain of /usr/src only. : > : > I think that's a bad assumption. I know of several projects outside : > of /usr/src that use bsd.*.mk. : : They should use something besides bsd.*.mk, aka ts.*.mk? :) We do wrap them in tsc.*.mk, but use the underlying bsd.*.mk because there's no need to reinvent the wheen. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 12 11:30: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 7316A37B71A for ; Mon, 12 Mar 2001 11:29:54 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2CJTee21828; Mon, 12 Mar 2001 11:29:40 -0800 (PST) (envelope-from obrien) Date: Mon, 12 Mar 2001 11:29:40 -0800 From: "David O'Brien" To: Warner Losh Cc: arch@FreeBSD.ORG Subject: Re: Breaking up make.conf Message-ID: <20010312112939.E21123@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20010310170844.C36413@dragon.nuxi.com> <200103090430.f294Ucs04824@billy-club.village.org> <20010308201422.A94052@mollari.cthul.hu> <200103090241.SAA27525@gndrsh.dnsmgr.net> <200103090349.f293nGs04577@billy-club.village.org> <200103090430.f294Ucs04824@billy-club.village.org> <200103090449.f294nUs06142@billy-club.village.org> <20010310170844.C36413@dragon.nuxi.com> <200103110145.f2B1jOI23270@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103110145.f2B1jOI23270@harmony.village.org>; from imp@harmony.village.org on Sat, Mar 10, 2001 at 06:45:24PM -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 X-Loop: FreeBSD.ORG On Sat, Mar 10, 2001 at 06:45:24PM -0700, Warner Losh wrote: > In message <20010310170844.C36413@dragon.nuxi.com> "David O'Brien" writes: > : I.E., lets assume /usr/share/mk/bsd.*.mk is the domain of /usr/src only. > > I think that's a bad assumption. I know of several projects outside > of /usr/src that use bsd.*.mk. They should either copy the bsd.*.mk files to their own place, OR accpet they have to play by our assumptions. They are named "bsd" :-) -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 12 11:31:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id DB7C637B718 for ; Mon, 12 Mar 2001 11:31:10 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2CJV6C21871; Mon, 12 Mar 2001 11:31:06 -0800 (PST) (envelope-from obrien) Date: Mon, 12 Mar 2001 11:31:06 -0800 From: "David O'Brien" To: Warner Losh Cc: arch@FreeBSD.ORG Subject: Re: Breaking up make.conf Message-ID: <20010312113106.F21123@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <15021.5742.621060.580501@nomad.yogotech.com> <20010310170844.C36413@dragon.nuxi.com> <200103090430.f294Ucs04824@billy-club.village.org> <20010308201422.A94052@mollari.cthul.hu> <200103090241.SAA27525@gndrsh.dnsmgr.net> <200103090349.f293nGs04577@billy-club.village.org> <200103090449.f294nUs06142@billy-club.village.org> <200103110145.f2B1jOI23270@harmony.village.org> <15021.5742.621060.580501@nomad.yogotech.com> <200103121913.f2CJDtI38620@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103121913.f2CJDtI38620@harmony.village.org>; from imp@harmony.village.org on Mon, Mar 12, 2001 at 12:13:55PM -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 X-Loop: FreeBSD.ORG On Mon, Mar 12, 2001 at 12:13:55PM -0700, Warner Losh wrote: > : > I think that's a bad assumption. I know of several projects outside > : > of /usr/src that use bsd.*.mk. > : > : They should use something besides bsd.*.mk, aka ts.*.mk? :) > > We do wrap them in tsc.*.mk, but use the underlying bsd.*.mk because > there's no need to reinvent the wheen. This is a convience for a few that seems to be causing more pain for more, if we don't take the position bsd.*.mk is for /usr/src -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 12 11:32:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 05DAC37B71A for ; Mon, 12 Mar 2001 11:32:17 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2CJWGZ21892 for arch@FreeBSD.ORG; Mon, 12 Mar 2001 11:32:16 -0800 (PST) (envelope-from obrien) Date: Mon, 12 Mar 2001 11:32:15 -0800 From: "David O'Brien" To: arch@FreeBSD.ORG Subject: Re: Breaking up make.conf Message-ID: <20010312113215.G21123@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <20010310170844.C36413@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bde@zeta.org.au on Mon, Mar 12, 2001 at 02:02:25AM +1100 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 X-Loop: FreeBSD.ORG On Mon, Mar 12, 2001 at 02:02:25AM +1100, Bruce Evans wrote: > The ports .mk files configure paths much better than sys.mk. They > use ${PORTSDIR} but sys.mk hard-codes 3 absolute paths in /etc. That can easily be fixed. :-) -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 12 11:33:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 1451137B718 for ; Mon, 12 Mar 2001 11:33:26 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f2CJXPL72105; Mon, 12 Mar 2001 11:33:25 -0800 (PST) (envelope-from dillon) Date: Mon, 12 Mar 2001 11:33:25 -0800 (PST) From: Matt Dillon Message-Id: <200103121933.f2CJXPL72105@earth.backplane.com> To: "David O'Brien" , Warner Losh , arch@FreeBSD.ORG Subject: Re: Breaking up make.conf References: <15021.5742.621060.580501@nomad.yogotech.com> <20010310170844.C36413@dragon.nuxi.com> <200103090430.f294Ucs04824@billy-club.village.org> <20010308201422.A94052@mollari.cthul.hu> <200103090241.SAA27525@gndrsh.dnsmgr.net> <200103090349.f293nGs04577@billy-club.village.org> <200103090449.f294nUs06142@billy-club.village.org> <200103110145.f2B1jOI23270@harmony.village.org> <15021.5742.621060.580501@nomad.yogotech.com> <200103121913.f2CJDtI38620@harmony.village.org> <20010312113106.F21123@dragon.nuxi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You guys are all nuts. /etc/make.conf is perfectly fine the way it is. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 12 11:34:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id A974E37B719; Mon, 12 Mar 2001 11:34:36 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f2CJYZI38844; Mon, 12 Mar 2001 12:34:36 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200103121934.f2CJYZI38844@harmony.village.org> To: obrien@FreeBSD.ORG Subject: Re: Breaking up make.conf Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Mon, 12 Mar 2001 11:29:40 PST." <20010312112939.E21123@dragon.nuxi.com> References: <20010312112939.E21123@dragon.nuxi.com> <20010310170844.C36413@dragon.nuxi.com> <200103090430.f294Ucs04824@billy-club.village.org> <20010308201422.A94052@mollari.cthul.hu> <200103090241.SAA27525@gndrsh.dnsmgr.net> <200103090349.f293nGs04577@billy-club.village.org> <200103090430.f294Ucs04824@billy-club.village.org> <200103090449.f294nUs06142@billy-club.village.org> <20010310170844.C36413@dragon.nuxi.com> <200103110145.f2B1jOI23270@harmony.village.org> Date: Mon, 12 Mar 2001 12:34:35 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010312112939.E21123@dragon.nuxi.com> "David O'Brien" writes: : On Sat, Mar 10, 2001 at 06:45:24PM -0700, Warner Losh wrote: : > In message <20010310170844.C36413@dragon.nuxi.com> "David O'Brien" writes: : > : I.E., lets assume /usr/share/mk/bsd.*.mk is the domain of /usr/src only. : > : > I think that's a bad assumption. I know of several projects outside : > of /usr/src that use bsd.*.mk. : : They should either copy the bsd.*.mk files to their own place, OR accpet : they have to play by our assumptions. They are named "bsd" :-) I'm sorry, but I beleive that's bogus. Jsut ebcause tehy say bsd doean't mean they are private to the build process. We install them on the system, and document them bsd.README. No where in bsd.README has there ever eben a warning that FreeBSD or anybdoy else would make these private to the build world process. If you want something that is private to the buidlworld process, then create a framework that is used only by the buildworld process. Besides, they are included last in all our makefiles, and that's too late for them to include global config information. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 12 11:35:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id E649237B718 for ; Mon, 12 Mar 2001 11:35:50 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f2CJZoI38879 for ; Mon, 12 Mar 2001 12:35:50 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200103121935.f2CJZoI38879@harmony.village.org> To: arch@FreeBSD.ORG Subject: Re: Breaking up make.conf In-reply-to: Your message of "Mon, 12 Mar 2001 11:31:06 PST." <20010312113106.F21123@dragon.nuxi.com> References: <20010312113106.F21123@dragon.nuxi.com> <15021.5742.621060.580501@nomad.yogotech.com> <20010310170844.C36413@dragon.nuxi.com> <200103090430.f294Ucs04824@billy-club.village.org> <20010308201422.A94052@mollari.cthul.hu> <200103090241.SAA27525@gndrsh.dnsmgr.net> <200103090349.f293nGs04577@billy-club.village.org> <200103090449.f294nUs06142@billy-club.village.org> <200103110145.f2B1jOI23270@harmony.village.org> <15021.5742.621060.580501@nomad.yogotech.com> <200103121913.f2CJDtI38620@harmony.village.org> Date: Mon, 12 Mar 2001 12:35:50 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010312113106.F21123@dragon.nuxi.com> "David O'Brien" writes: : On Mon, Mar 12, 2001 at 12:13:55PM -0700, Warner Losh wrote: : > : > I think that's a bad assumption. I know of several projects outside : > : > of /usr/src that use bsd.*.mk. : > : : > : They should use something besides bsd.*.mk, aka ts.*.mk? :) : > : > We do wrap them in tsc.*.mk, but use the underlying bsd.*.mk because : > there's no need to reinvent the wheen. : : This is a convience for a few that seems to be causing more pain for : more, if we don't take the position bsd.*.mk is for /usr/src I'm afraid that I violently disagree with this position and will fight it tooth and nail every step of the way. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 12 11:38:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from molly.straylight.com (molly.straylight.com [209.68.199.242]) by hub.freebsd.org (Postfix) with ESMTP id A2E7137B71F for ; Mon, 12 Mar 2001 11:38:35 -0800 (PST) (envelope-from jonathan@graehl.org) Received: from dickie (case.straylight.com [209.68.199.244]) by molly.straylight.com (8.11.0/8.10.0) with SMTP id f2CJcUw28496 for ; Mon, 12 Mar 2001 11:38:30 -0800 From: "Jonathan Graehl" To: "freebsd-Arch" Subject: RE: Breaking up make.conf Date: Mon, 12 Mar 2001 11:38:56 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-reply-to: <200103121913.f2CJDtI38620@harmony.village.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have a side question about the bsd.*.mk files: the documentation says that they cannot easily handle programs with sources in subdirectories; shouldn't the VPATH directive allow for this? I recently (using GNU make; BSD make docs indicate support also) used VPATH to build two servers including common source from ../shared/ (but the generated objects were different because of -Ddefines and compiler flags, and were nicely generated and found in the build directory, since they could be referenced by "shared.o" rather than "../shared/shared.o" due to the VPATH directive). Does BSD make support this behavior? Could a Makefile including bsd.prog.mk make use of it? I suppose I am supposed to simply write my own makefiles (and that is what I did), but I originally had thought that the bsd.*.mk had a nice, uniform system, and would have used them if not for my inability to build a program from non-flat-sources using them. -- Jonathan Graehl email: jonathan@graehl.org web: http://jonathan.graehl.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 12 11:40:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from molly.straylight.com (molly.straylight.com [209.68.199.242]) by hub.freebsd.org (Postfix) with ESMTP id EE9A537B722 for ; Mon, 12 Mar 2001 11:40:13 -0800 (PST) (envelope-from jonathan@graehl.org) Received: from dickie (case.straylight.com [209.68.199.244]) by molly.straylight.com (8.11.0/8.10.0) with SMTP id f2CJe9w28509 for ; Mon, 12 Mar 2001 11:40:09 -0800 From: "Jonathan Graehl" To: "freebsd-Arch" Subject: RE: Breaking up make.conf Date: Mon, 12 Mar 2001 11:40:35 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-reply-to: <200103121935.f2CJZoI38879@harmony.village.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I wouldn't go that far, but /usr/share is obviously not for private /usr/src files. The bsd.*.mk files were indeed documented as public, and should not be removed, regardless of what you wish to add to /usr/src. -Jonathan > I'm afraid that I violently disagree with this position and will fight > it tooth and nail every step of the way. > > Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 12 11:41:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 1CF2B37B719 for ; Mon, 12 Mar 2001 11:41:48 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2CJfhJ22102; Mon, 12 Mar 2001 11:41:43 -0800 (PST) (envelope-from obrien) Date: Mon, 12 Mar 2001 11:41:42 -0800 From: "David O'Brien" To: Warner Losh Cc: arch@FreeBSD.ORG Subject: Re: Breaking up make.conf Message-ID: <20010312114142.B21989@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <200103090430.f294Ucs04824@billy-club.village.org> <20010308201422.A94052@mollari.cthul.hu> <200103090241.SAA27525@gndrsh.dnsmgr.net> <200103090349.f293nGs04577@billy-club.village.org> <200103090430.f294Ucs04824@billy-club.village.org> <200103090449.f294nUs06142@billy-club.village.org> <20010310170844.C36413@dragon.nuxi.com> <200103110145.f2B1jOI23270@harmony.village.org> <20010312112939.E21123@dragon.nuxi.com> <200103121934.f2CJYZI38844@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103121934.f2CJYZI38844@harmony.village.org>; from imp@harmony.village.org on Mon, Mar 12, 2001 at 12:34:35PM -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 X-Loop: FreeBSD.ORG On Mon, Mar 12, 2001 at 12:34:35PM -0700, Warner Losh wrote: > We install them on the system, and document them bsd.README. "XXX This document is seriously out of date, it is currenly being revised." > No where in bsd.README has there ever eben a warning that FreeBSD or > anybdoy else would make these private to the build world process. "This is the README file for the new make "include" files for the BSD source tree." I point out the _BSD_source_tree_ part. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 12 11:44:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 5C20E37B719 for ; Mon, 12 Mar 2001 11:44:08 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2CJi0n22160; Mon, 12 Mar 2001 11:44:00 -0800 (PST) (envelope-from obrien) Date: Mon, 12 Mar 2001 11:44:00 -0800 From: "David O'Brien" To: Jonathan Graehl Cc: freebsd-Arch Subject: Re: Breaking up make.conf Message-ID: <20010312114400.C21989@dragon.nuxi.com> Reply-To: freebsd-arch@FreeBSD.ORG References: <200103121935.f2CJZoI38879@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jonathan@graehl.org on Mon, Mar 12, 2001 at 11:40:35AM -0800 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 X-Loop: FreeBSD.ORG On Mon, Mar 12, 2001 at 11:40:35AM -0800, Jonathan Graehl wrote: > I wouldn't go that far, but /usr/share is obviously not for private /usr/src > files. The bsd.*.mk files were indeed documented as public, and should not be > removed, regardless of what you wish to add to /usr/src. No one ever said they should be deleted. The issue is should we state they are for use in building the world. If you want the same processing and semantics you are free to use them for your own. Warner is saying he wants almost the same processing (if we added an /etc/make-world.conf), but doesn't want to have change, edit, create any new .mk files. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 12 11:45:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id B457537B719 for ; Mon, 12 Mar 2001 11:45:26 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f2CJjPI39044 for ; Mon, 12 Mar 2001 12:45:26 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200103121945.f2CJjPI39044@harmony.village.org> To: arch@FreeBSD.ORG Subject: Re: Breaking up make.conf In-reply-to: Your message of "Mon, 12 Mar 2001 11:41:42 PST." <20010312114142.B21989@dragon.nuxi.com> References: <20010312114142.B21989@dragon.nuxi.com> <200103090430.f294Ucs04824@billy-club.village.org> <20010308201422.A94052@mollari.cthul.hu> <200103090241.SAA27525@gndrsh.dnsmgr.net> <200103090349.f293nGs04577@billy-club.village.org> <200103090430.f294Ucs04824@billy-club.village.org> <200103090449.f294nUs06142@billy-club.village.org> <20010310170844.C36413@dragon.nuxi.com> <200103110145.f2B1jOI23270@harmony.village.org> <20010312112939.E21123@dragon.nuxi.com> <200103121934.f2CJYZI38844@harmony.village.org> Date: Mon, 12 Mar 2001 12:45:25 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010312114142.B21989@dragon.nuxi.com> "David O'Brien" writes: : On Mon, Mar 12, 2001 at 12:34:35PM -0700, Warner Losh wrote: : > We install them on the system, and document them bsd.README. : : "XXX This document is seriously out of date, it is currenly being revised." Ture. : > No where in bsd.README has there ever eben a warning that FreeBSD or : > anybdoy else would make these private to the build world process. : : "This is the README file for the new make "include" files for the BSD : source tree." : : I point out the _BSD_source_tree_ part. Then why are they installed in /usr/share/mk? It does not say they are private to the BSD source tree, only that the BSD source tree uses them. The itnerface has been basically stable since 1.0 FreeBSD. Outwise folks are using them. There's no need to screw them gratuitously. But this is pointless. Unless you go and include a new file at the start of every makefile in the tree changing the bsd.*.mk files to include the global config file is meaningless because it is too late. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 12 11:49: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 8E3F637B719 for ; Mon, 12 Mar 2001 11:48:57 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f2CJmuI39086; Mon, 12 Mar 2001 12:48:56 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200103121948.f2CJmuI39086@harmony.village.org> To: freebsd-arch@FreeBSD.ORG Subject: Re: Breaking up make.conf Cc: Jonathan Graehl In-reply-to: Your message of "Mon, 12 Mar 2001 11:44:00 PST." <20010312114400.C21989@dragon.nuxi.com> References: <20010312114400.C21989@dragon.nuxi.com> <200103121935.f2CJZoI38879@harmony.village.org> Date: Mon, 12 Mar 2001 12:48:56 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010312114400.C21989@dragon.nuxi.com> "David O'Brien" writes: : Warner is saying he wants almost the same processing (if we added an : /etc/make-world.conf), but doesn't want to have change, edit, create any : new .mk files. Warner is saying that he doesn't want bsd.*.mk changed such that they can't be used by outside projects. Warner is also saying that these files were intended to be public and not private to /usr/src and we shouldn't hard code something that could only be used for /usr/src into them. Warner is also poitning out that the bsd.*.mk files are included last in most makefiles, which makes it too late to include anything to control the makefile's choices of what/how to build. Warner is willing to roll with the punches and make minor tweaks to his wrapper .mk files, where his private tsc specific stuff resides, but is generally opposed to making these public files explicitly private to the building of /usr/src. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 12 11:57:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 9963A37B718 for ; Mon, 12 Mar 2001 11:57:09 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f2CJv5I39157; Mon, 12 Mar 2001 12:57:09 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200103121957.f2CJv5I39157@harmony.village.org> Subject: Re: Breaking up make.conf Cc: freebsd-arch@FreeBSD.ORG, Jonathan Graehl In-reply-to: Your message of "Mon, 12 Mar 2001 12:48:56 MST." <200103121948.f2CJmuI39086@harmony.village.org> References: <200103121948.f2CJmuI39086@harmony.village.org> <20010312114400.C21989@dragon.nuxi.com> <200103121935.f2CJZoI38879@harmony.village.org> Date: Mon, 12 Mar 2001 12:57:05 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200103121948.f2CJmuI39086@harmony.village.org> Warner Losh writes: : Warner is saying that he doesn't want bsd.*.mk changed such that they Warner also thinks Warner revers to referring to Warner in the third person when stress out. Warner should get more recreation in Warner's life to prevent that. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 12 12:22:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id CCF2C37B718 for ; Mon, 12 Mar 2001 12:22:47 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2CKMib27026; Mon, 12 Mar 2001 12:22:44 -0800 (PST) (envelope-from obrien) Date: Mon, 12 Mar 2001 12:22:43 -0800 From: "David O'Brien" To: Warner Losh Cc: arch@FreeBSD.ORG Subject: Re: Breaking up make.conf Message-ID: <20010312122243.A26946@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <200103090241.SAA27525@gndrsh.dnsmgr.net> <200103090349.f293nGs04577@billy-club.village.org> <200103090430.f294Ucs04824@billy-club.village.org> <200103090449.f294nUs06142@billy-club.village.org> <20010310170844.C36413@dragon.nuxi.com> <200103110145.f2B1jOI23270@harmony.village.org> <20010312112939.E21123@dragon.nuxi.com> <200103121934.f2CJYZI38844@harmony.village.org> <20010312114142.B21989@dragon.nuxi.com> <200103121945.f2CJjPI39044@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103121945.f2CJjPI39044@harmony.village.org>; from imp@harmony.village.org on Mon, Mar 12, 2001 at 12:45:25PM -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 X-Loop: FreeBSD.ORG On Mon, Mar 12, 2001 at 12:45:25PM -0700, Warner Losh wrote: > : I point out the _BSD_source_tree_ part. > > Then why are they installed in /usr/share/mk? Open source. :-) Same reason we all trade code -- the code may work great for us As-is. Or to be the basis for one's own hack. > It does not say they are private to the BSD source tree, only that the > BSD source tree uses them. I'm not sure what people keep meaning by "private". I am talking about the position that that they contain assumptions needed by /usr/src. bsd.port.mk certainly assumes the needs of FreeBSD's /usr/ports. It cannot be reused by anyone else w/o tweaks. It was only moved to /usr/ports/Mk because it is the easiest way to keep it in-sync with the rest of /usr/ports. > But this is pointless. Unless you go and include a new file at the > start of every makefile in the tree changing the bsd.*.mk files to > include the global config file is meaningless because it is too late. Not pointless. A required first step, if we decided we do want to move the change the Makefiles. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 12 12:30:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 361EE37B71A for ; Mon, 12 Mar 2001 12:30:32 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id HAA08338; Tue, 13 Mar 2001 07:30:22 +1100 Date: Tue, 13 Mar 2001 07:30:08 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Jonathan Graehl Cc: freebsd-Arch Subject: RE: Breaking up make.conf In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 12 Mar 2001, Jonathan Graehl wrote: > I have a side question about the bsd.*.mk files: the documentation says that > they cannot easily handle programs with sources in subdirectories; It actually says almost the opposite: that they cannot easily handle multiple programs in a single directory. There should be subdirectories somewhere to contain separate Makefiles. Various somewhere's are used: 1) (best) in src/*bin (etc.). The sources may be with the Makefiles (best) or in far-flung contrib dirs where they are harder to manage. 2) in subdirs of source directories in src/*bin (etc.). E.g., src/usr.sbin/mrouted. 3) in subdirs of non-source directories in src/*bin (etc.). E.g., src/gnu/usr.bin/cc. > shouldn't the > VPATH directive allow for this? I recently (using GNU make; BSD make docs > indicate support also) used VPATH to build two servers including common source > from ../shared/ (but the generated objects were different because of -Ddefines > and compiler flags, and were nicely generated and found in the build directory, > since they could be referenced by "shared.o" rather than "../shared/shared.o" > due to the VPATH directive). Does BSD make support this behavior? Could a > Makefile including bsd.prog.mk make use of it? VPATH and .PATH can be used to handle sources files all over the place. VPATH is a style bug in BSD makefiles; use .PATH instead. .PATH gives more control, at least for the .PATH form of it. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 12 12:33:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 6D2CA37B71C for ; Mon, 12 Mar 2001 12:33:24 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f2CKXJI39387 for ; Mon, 12 Mar 2001 13:33:23 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200103122033.f2CKXJI39387@harmony.village.org> To: arch@FreeBSD.ORG Subject: Re: Breaking up make.conf In-reply-to: Your message of "Mon, 12 Mar 2001 12:22:43 PST." <20010312122243.A26946@dragon.nuxi.com> References: <20010312122243.A26946@dragon.nuxi.com> <200103090241.SAA27525@gndrsh.dnsmgr.net> <200103090349.f293nGs04577@billy-club.village.org> <200103090430.f294Ucs04824@billy-club.village.org> <200103090449.f294nUs06142@billy-club.village.org> <20010310170844.C36413@dragon.nuxi.com> <200103110145.f2B1jOI23270@harmony.village.org> <20010312112939.E21123@dragon.nuxi.com> <200103121934.f2CJYZI38844@harmony.village.org> <20010312114142.B21989@dragon.nuxi.com> <200103121945.f2CJjPI39044@harmony.village.org> Date: Mon, 12 Mar 2001 13:33:19 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010312122243.A26946@dragon.nuxi.com> "David O'Brien" writes: : > But this is pointless. Unless you go and include a new file at the : > start of every makefile in the tree changing the bsd.*.mk files to : > include the global config file is meaningless because it is too late. : : Not pointless. A required first step, if we decided we do want to move : the change the Makefiles. IF you want to add .include I'd be OK with that from a bsd.*.mk point of view. It is likely tedious and error prone, and only really needed for about 20 Makefiles in the tree. Most of the rest can cope without needed to go into and do that. The rest could include this indirectly from bsd.{prog,lib,subdir}.mk. Something like that would allow us to have bsd.conf.mk look like .if !target(__bsd_conf_mk) WORLD_CONF?=/etc/make.world.conf .include "${WORLD_CONF}" .include __bsd_conf_mk: .endif and allow third parties to also have their own definition of WORLD_CONF, either in their environment or as part of their wrappers. There would then be issues with . We could avoid those issues by removing bsd.cpu.mk from sys.mk and putting it in bsd.conf.mk like I've done above. Also, there might need to be some makefile foo done to prevent __bsd_conf_mk: from becoming the default target. Something like this serves the needs of the world build, but is also hackable/extensible for others using the system. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 12 14:52:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 666E637B718 for ; Mon, 12 Mar 2001 14:52:28 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2CMqCA91593; Mon, 12 Mar 2001 14:52:12 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010312114142.B21989@dragon.nuxi.com> Date: Mon, 12 Mar 2001 14:51:54 -0800 (PST) From: John Baldwin To: "David O'Brien" Subject: Re: Breaking up make.conf Cc: arch@FreeBSD.org, Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 12-Mar-01 David O'Brien wrote: > On Mon, Mar 12, 2001 at 12:34:35PM -0700, Warner Losh wrote: >> We install them on the system, and document them bsd.README. > > "XXX This document is seriously out of date, it is currenly being revised." Yeah, now it has grown the new meaning that it is a generic set of Makefiles. >> No where in bsd.README has there ever eben a warning that FreeBSD or >> anybdoy else would make these private to the build world process. > > "This is the README file for the new make "include" files for the BSD > source tree." > > I point out the _BSD_source_tree_ part. And the document is out of date. This is a case of tradition overtaking things. This is the same reason that the change to the queue(3) macros to remove the explicit 'struct's didn't fly. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - 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 Mon Mar 12 22:47:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by hub.freebsd.org (Postfix) with ESMTP id 037C337B720 for ; Mon, 12 Mar 2001 22:47:36 -0800 (PST) (envelope-from marcel@cup.hp.com) Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.0.100.30]) by palrel3.hp.com (Postfix) with ESMTP id D4735146; Mon, 12 Mar 2001 22:47:26 -0800 (PST) Received: from cup.hp.com (p1000180.nsr.hp.com [15.109.0.180]) by adlmail.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id WAA10485; Mon, 12 Mar 2001 22:47:26 -0800 (PST) Message-ID: <3AADC27D.8E7FEDA@cup.hp.com> Date: Mon, 12 Mar 2001 22:47:25 -0800 From: Marcel Moolenaar Organization: Hewlett-Packard X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Warner Losh Cc: arch@FreeBSD.ORG Subject: Re: Breaking up make.conf References: <20010312113106.F21123@dragon.nuxi.com> <15021.5742.621060.580501@nomad.yogotech.com> <20010310170844.C36413@dragon.nuxi.com> <200103090430.f294Ucs04824@billy-club.village.org> <20010308201422.A94052@mollari.cthul.hu> <200103090241.SAA27525@gndrsh.dnsmgr.net> <200103090349.f293nGs04577@billy-club.village.org> <200103090449.f294nUs06142@billy-club.village.org> <200103110145.f2B1jOI23270@harmony.village.org> <15021.5742.621060.580501@nomad.yogotech.com> <200103121913.f2CJDtI38620@harmony.village.org> <200103121935.f2CJZoI38879@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > > : This is a convience for a few that seems to be causing more pain for > : more, if we don't take the position bsd.*.mk is for /usr/src > > I'm afraid that I violently disagree with this position and will fight > it tooth and nail every step of the way. I'll be less violent, will probably bail out earlier (I like to keep my teeth) and also keep away from nails as much a possible, but I'll fight on Warner's side :-) I admit we already have too much FreeBSD-ism in the *.mk files, but I don't think we should monopolize it's use. What we do in our source tree is not radically different from what everybody else is doing, which is to build libraries and/or binaries. I suspect we put the *.mk files in /usr/share for a reason as well... -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 13 9:10:55 2001 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 C731237B718 for ; Tue, 13 Mar 2001 09:10:52 -0800 (PST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.2/8.11.0) with ESMTP id f2DHApX71930; Tue, 13 Mar 2001 10:10:51 -0700 (MST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.2/8.8.3) with ESMTP id f2DH84Z13815; Tue, 13 Mar 2001 10:08:04 -0700 (MST) Message-Id: <200103131708.f2DH84Z13815@billy-club.village.org> To: Marcel Moolenaar Subject: Re: Breaking up make.conf Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Mon, 12 Mar 2001 22:47:25 PST." <3AADC27D.8E7FEDA@cup.hp.com> References: <3AADC27D.8E7FEDA@cup.hp.com> <20010312113106.F21123@dragon.nuxi.com> <15021.5742.621060.580501@nomad.yogotech.com> <20010310170844.C36413@dragon.nuxi.com> <200103090430.f294Ucs04824@billy-club.village.org> <20010308201422.A94052@mollari.cthul.hu> <200103090241.SAA27525@gndrsh.dnsmgr.net> <200103090349.f293nGs04577@billy-club.village.org> <200103090449.f294nUs06142@billy-club.village.org> <200103110145.f2B1jOI23270@harmony.village.org> <15021.5742.621060.580501@nomad.yogotech.com> <200103121913.f2CJDtI38620@harmony.village.org> <200103121935.f2CJZoI38879@harmony.village.org> Date: Tue, 13 Mar 2001 10:08:03 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3AADC27D.8E7FEDA@cup.hp.com> Marcel Moolenaar writes: : I'll be less violent, will probably bail out earlier (I like to keep my : teeth) and also keep away from nails as much a possible, but I'll fight : on Warner's side :-) Nails are what makes this fun. Oh, wait, I'm posting to the wrong list again... : I admit we already have too much FreeBSD-ism in the *.mk files, but I : don't think we should monopolize it's use. What we do in our source tree : is not radically different from what everybody else is doing, which is : to build libraries and/or binaries. I suspect we put the *.mk files in : /usr/share for a reason as well... Yes. I think that my bsd.conf.mk might have some legs in that it would be a fairly unintrusive change. We have too much goo in sys.mk right now and it is time to start cleaning that up. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 13 11:16:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id 1107937B721 for ; Tue, 13 Mar 2001 11:16:23 -0800 (PST) (envelope-from roam@orbitel.bg) Received: (qmail 19483 invoked by uid 1000); 13 Mar 2001 19:15:44 -0000 Date: Tue, 13 Mar 2001 21:15:44 +0200 From: Peter Pentchev To: freebsd-arch@FreeBSD.org Subject: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010313211544.B17733@ringworld.oblivion.bg> Mail-Followup-To: freebsd-arch@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, A recent thread about Bill Fenner's distfiles-checking scripts set me thinking about easy detection of MD5 checksum mismatches. Bill Fenner pointed out that these checks are not done because of the sheer volume of the network traffic needed to download all the distfiles from all the distsites. I know that adding a ``SITE MD5 filename'' command to our ftpd is a *very* little step in a possibly wrong direction (this will not automagically make all the ftp daemons on all the distsites implement this command), but IMHO, it's a start.. I'm thinking of adding similar functionality to wu-ftpd and ProFTPd soon, and submitting patches to the authors, in the hope of starting a ball rolling :) G'luck, Peter -- because I didn't think of a good beginning of it. Index: src/libexec/ftpd/ftpcmd.y =================================================================== RCS file: /home/ncvs/src/libexec/ftpd/ftpcmd.y,v retrieving revision 1.21 diff -u -r1.21 ftpcmd.y --- src/libexec/ftpd/ftpcmd.y 2001/02/19 21:51:26 1.21 +++ src/libexec/ftpd/ftpcmd.y 2001/03/13 18:48:54 @@ -58,6 +58,7 @@ #include #include #include +#include #include #include #include @@ -92,6 +93,7 @@ extern char tmpline[]; extern int readonly; extern int noepsv; +extern int nomd5; off_t restart_point; @@ -126,7 +128,7 @@ CDUP STOU SMNT SYST SIZE MDTM LPRT LPSV EPRT EPSV - UMASK IDLE CHMOD + UMASK IDLE CHMOD MD5 LEXERR @@ -648,6 +650,34 @@ } } } + | SITE SP check_login MD5 SP pathname CRLF + { + if ($3) { + struct stat stbuf; + char hash[33]; + + if (nomd5) + reply(500, + "SITE MD5 command disabled", + $6); + else if (stat($6, &stbuf) < 0) + reply(550, + "%s: %s", + $6, strerror(errno)); + else if (!S_ISREG(stbuf.st_mode)) + reply(550, + "%s: not a plain file", + $6); + else if (MD5File($6, hash) == NULL) + reply(550, + "%s: %s", + $6, strerror(errno)); + else + reply(200, + "MD5 %s %s", + hash, $6); + } + } | STOU check_login_ro SP pathname CRLF { if ($2 && $4 != NULL) @@ -1088,6 +1118,7 @@ { "IDLE", IDLE, ARGS, 1, "[ maximum-idle-time ]" }, { "CHMOD", CHMOD, NSTR, 1, " mode file-name" }, { "HELP", HELP, OSTR, 1, "[ ]" }, + { "MD5", MD5, STR1, 1, " file-name" }, { NULL, 0, 0, 0, 0 } }; Index: src/libexec/ftpd/ftpd.8 =================================================================== RCS file: /home/ncvs/src/libexec/ftpd/ftpd.8,v retrieving revision 1.36 diff -u -r1.36 ftpd.8 --- src/libexec/ftpd/ftpd.8 2000/12/18 08:33:25 1.36 +++ src/libexec/ftpd/ftpd.8 2001/03/13 18:48:54 @@ -42,6 +42,7 @@ .Sh SYNOPSIS .Nm .Op Fl 4 +.Op Fl 5 .Op Fl 6 .Op Fl d .Op Fl l Op Fl l @@ -153,6 +154,10 @@ When .Fl 6 is not specified, accept IPv4 connection via AF_INET socket. +.It Fl 5 +Disable the SITE MD5 command. +This is useful for preventing possible denial of service attacks, +especially on servers allowing anonymous ftp access. .It Fl A Allow only anonymous ftp access. .It Fl r Index: src/libexec/ftpd/ftpd.c =================================================================== RCS file: /home/ncvs/src/libexec/ftpd/ftpd.c,v retrieving revision 1.73 diff -u -r1.73 ftpd.c --- src/libexec/ftpd/ftpd.c 2001/03/11 13:20:44 1.73 +++ src/libexec/ftpd/ftpd.c 2001/03/13 18:48:56 @@ -150,6 +150,7 @@ int pdata = -1; /* for passive mode */ int readonly=0; /* Server is in readonly mode. */ int noepsv=0; /* EPSV command is disabled. */ +int nomd5=0; /* SITE MD5 command is disabled. */ sig_atomic_t transflag; off_t file_size; off_t byte_count; @@ -292,7 +293,7 @@ #endif /* OLD_SETPROCTITLE */ - while ((ch = getopt(argc, argv, "AdlDESURrt:T:u:va:p:46")) != -1) { + while ((ch = getopt(argc, argv, "AdlDESURrt:T:u:va:p:456")) != -1) { switch (ch) { case 'D': daemon_mode++; @@ -369,6 +370,10 @@ enable_v4 = 1; if (family == AF_UNSPEC) family = AF_INET; + break; + + case '5': + nomd5 = 1; break; case '6': To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 13 11:35: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from phk.freebsd.dk (phk.freebsd.dk [212.242.86.136]) by hub.freebsd.org (Postfix) with ESMTP id 2A4C637B726 for ; Tue, 13 Mar 2001 11:35:01 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by phk.freebsd.dk (8.9.3/8.9.3) with ESMTP id UAA47944; Tue, 13 Mar 2001 20:34:59 +0100 (CET) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f2DJZHp09873; Tue, 13 Mar 2001 20:35:17 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Peter Pentchev Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd In-Reply-To: Your message of "Tue, 13 Mar 2001 21:15:44 +0200." <20010313211544.B17733@ringworld.oblivion.bg> Date: Tue, 13 Mar 2001 20:35:17 +0100 Message-ID: <9871.984512117@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >I know that adding a ``SITE MD5 filename'' command to our ftpd >is a *very* little step in a possibly wrong direction (this will >not automagically make all the ftp daemons on all the distsites >implement this command), but IMHO, it's a start. That's actually very clever thinking. You may want to make the command take two more arguments: SITE MD5 filename [offset [length]] That could be used to improve mirroring software a fair bit... -- 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 Mar 13 11:38:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id 54B1D37B723 for ; Tue, 13 Mar 2001 11:38:40 -0800 (PST) (envelope-from roam@orbitel.bg) Received: (qmail 19701 invoked by uid 1000); 13 Mar 2001 19:38:01 -0000 Date: Tue, 13 Mar 2001 21:38:01 +0200 From: Peter Pentchev To: Poul-Henning Kamp Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010313213801.A19658@ringworld.oblivion.bg> Mail-Followup-To: Poul-Henning Kamp , freebsd-arch@FreeBSD.ORG References: <20010313211544.B17733@ringworld.oblivion.bg> <9871.984512117@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9871.984512117@critter>; from phk@critter.freebsd.dk on Tue, Mar 13, 2001 at 08:35:17PM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Mar 13, 2001 at 08:35:17PM +0100, Poul-Henning Kamp wrote: > > >I know that adding a ``SITE MD5 filename'' command to our ftpd > >is a *very* little step in a possibly wrong direction (this will > >not automagically make all the ftp daemons on all the distsites > >implement this command), but IMHO, it's a start. > > That's actually very clever thinking. > > You may want to make the command take two more arguments: > > SITE MD5 filename [offset [length]] > > That could be used to improve mirroring software a fair bit... Will do tomorrow; have to rush to a b-day party I'm already late for :) G'luck, Peter -- This would easier understand fewer had omitted. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 13 13:43:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 7414137B718 for ; Tue, 13 Mar 2001 13:43:22 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2DLeVt84049; Tue, 13 Mar 2001 13:40:31 -0800 (PST) (envelope-from obrien) Date: Tue, 13 Mar 2001 13:39:09 -0800 From: "David O'Brien" To: Peter Pentchev Cc: freebsd-arch@FreeBSD.org Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010313133909.A83966@dragon.nuxi.com> Reply-To: freebsd-arch@FreeBSD.org References: <20010313211544.B17733@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010313211544.B17733@ringworld.oblivion.bg>; from roam@orbitel.bg on Tue, Mar 13, 2001 at 09:15:44PM +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 X-Loop: FreeBSD.ORG On Tue, Mar 13, 2001 at 09:15:44PM +0200, Peter Pentchev wrote: > I know that adding a ``SITE MD5 filename'' command to our ftpd > is a *very* little step in a possibly wrong direction (this will I am very against adding Yet One More inconsistency (read local hack) that takes our ftpd farther from the other BSD's. Some of us have hopes of using the LukeM/NetBSD ftpd in FreeBSD. This hack will be more more thing that the nay sayers use to prevent this from happening. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 13 13:54:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-59.dsl.lsan03.pacbell.net [63.207.60.59]) by hub.freebsd.org (Postfix) with ESMTP id 857E537B719 for ; Tue, 13 Mar 2001 13:54:40 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 2A69866B6C; Tue, 13 Mar 2001 13:54:40 -0800 (PST) Date: Tue, 13 Mar 2001 13:54:40 -0800 From: Kris Kennaway To: freebsd-arch@FreeBSD.org Cc: Peter Pentchev Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010313135440.A18045@mollari.cthul.hu> References: <20010313211544.B17733@ringworld.oblivion.bg> <20010313133909.A83966@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010313133909.A83966@dragon.nuxi.com>; from TrimYourCc@NUXI.com on Tue, Mar 13, 2001 at 01:39:09PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 13, 2001 at 01:39:09PM -0800, David O'Brien wrote: > On Tue, Mar 13, 2001 at 09:15:44PM +0200, Peter Pentchev wrote: > > I know that adding a ``SITE MD5 filename'' command to our ftpd > > is a *very* little step in a possibly wrong direction (this will >=20 > I am very against adding Yet One More inconsistency (read local hack) > that takes our ftpd farther from the other BSD's. Some of us have hopes > of using the LukeM/NetBSD ftpd in FreeBSD. This hack will be more more > thing that the nay sayers use to prevent this from happening. Add the code to lukemftpd too :-) You've already got quite a bit of merge work to do, so this shouldn't be used as an argument to stifle development on the current ftpd. Kris --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6rpcfWry0BWjoQKURAuqtAJ4wP/QDKFGAJrKHowWqxtsBS6V+sQCgp1d8 W8u6x+zuWbQxkgHjl/g3q3c= =TIK6 -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 13 13:56:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gvr.gvr.org (gvr.gvr.org [212.61.40.17]) by hub.freebsd.org (Postfix) with ESMTP id A21E537B718 for ; Tue, 13 Mar 2001 13:56:20 -0800 (PST) (envelope-from guido@gvr.org) Received: by gvr.gvr.org (Postfix, from userid 657) id 570EA5808; Tue, 13 Mar 2001 22:56:12 +0100 (CET) Date: Tue, 13 Mar 2001 22:56:12 +0100 From: Guido van Rooij To: freebsd-arch@FreeBSD.org Cc: Peter Pentchev Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010313225612.A37102@gvr.gvr.org> References: <20010313211544.B17733@ringworld.oblivion.bg> <20010313133909.A83966@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010313133909.A83966@dragon.nuxi.com>; from TrimYourCc@NUXI.com on Tue, Mar 13, 2001 at 01:39:09PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Mar 13, 2001 at 01:39:09PM -0800, David O'Brien wrote: > On Tue, Mar 13, 2001 at 09:15:44PM +0200, Peter Pentchev wrote: > > I know that adding a ``SITE MD5 filename'' command to our ftpd > > is a *very* little step in a possibly wrong direction (this will > > I am very against adding Yet One More inconsistency (read local hack) > that takes our ftpd farther from the other BSD's. Some of us have hopes > of using the LukeM/NetBSD ftpd in FreeBSD. This hack will be more more > thing that the nay sayers use to prevent this from happening. So? If Peter is willing to port his code over? Since this is a plain addition, that should be fairly trivial. I think it is not a bad idea and if he is willing to implement it, let him. Your line of thinking is IMHO a block of progress. -Guido To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 13 15:28:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 83CCF37B718 for ; Tue, 13 Mar 2001 15:28:41 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id QAA90969 for arch@FreeBSD.org; Tue, 13 Mar 2001 16:28:40 -0700 (MST) (envelope-from ken) Date: Tue, 13 Mar 2001 16:28:40 -0700 From: "Kenneth D. Merry" To: arch@FreeBSD.org Subject: sbufs in userland, proposed solution Message-ID: <20010313162840.A90872@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well, the way I'm planning on going with putting sbufs in userland is to create a new library, libsbuf. libcam will be complied with a dependency on libsbuf, so libsbuf will automatically get pulled in for applications that dynamically link with libcam. Since most all the ports that use libcam that I know about (xmcd, tosha, cdrecord, cdda2wav, SANE) link dynamically, they should continue to work without recompilation. (The same would be true with preexisting static binaries.) They will also work without source patches when recompiled. I will probably go ahead and send patches to the various authors to add libsbuf to the link line if it exists, just in case they decide to link statically at some point. As for applications that link statically (e.g. camcontrol), they'll have to add libsbuf to the link line in order to compile. There is apparantly no way around the static link problem, so this is something that has to be done, unless I go with one of the other two alternatives -- putting sbufs in libc or in libcam. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 13 16:11: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id DFF2D37B71B for ; Tue, 13 Mar 2001 16:11:04 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2E08HH85964; Tue, 13 Mar 2001 16:08:17 -0800 (PST) (envelope-from obrien) Date: Tue, 13 Mar 2001 16:06:55 -0800 From: "David O'Brien" To: Guido van Rooij Cc: freebsd-arch@FreeBSD.org, Peter Pentchev Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010313160655.A85900@dragon.nuxi.com> Reply-To: freebsd-arch@FreeBSD.org References: <20010313211544.B17733@ringworld.oblivion.bg> <20010313133909.A83966@dragon.nuxi.com> <20010313225612.A37102@gvr.gvr.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010313225612.A37102@gvr.gvr.org>; from guido@gvr.org on Tue, Mar 13, 2001 at 10:56:12PM +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 X-Loop: FreeBSD.ORG On Tue, Mar 13, 2001 at 10:56:12PM +0100, Guido van Rooij wrote: > On Tue, Mar 13, 2001 at 01:39:09PM -0800, David O'Brien wrote: > > On Tue, Mar 13, 2001 at 09:15:44PM +0200, Peter Pentchev wrote: > > > I know that adding a ``SITE MD5 filename'' command to our ftpd > > > is a *very* little step in a possibly wrong direction (this will > > > > I am very against adding Yet One More inconsistency (read local hack) > > that takes our ftpd farther from the other BSD's. Some of us have hopes > > of using the LukeM/NetBSD ftpd in FreeBSD. This hack will be more more > > thing that the nay sayers use to prevent this from happening. > > So? If Peter is willing to port his code over? I don't quite parse this. Peter is going to do the work of merging LukeM ftpd and getting LukeM to accept all the changes? Ie, the hope is to put LukeM ftpd into src/contrib/ and treat it as typical src/contrib/ software. > Since this is a plain addition, that should be fairly trivial. I think > it is not a bad idea and if he is willing to implement it, let him. Think src/contrib/ .... > Your line of thinking is IMHO a block of progress. I guess your line of thinking will be the death wish of any code shareing then. IMHO no new local hacks should be introduced w/o talking to LukeM first to see if he would accept such changes back. Or is one of you guys going to offer to add all the _WONDERFUL_ enhancements that he has made to the BSD ftpd that makes it so 90% of the proftpd and wu-ftpd users need those very vulnerability ridden and crufty pieces of software? -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 13 16:13:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id B99C037B718 for ; Tue, 13 Mar 2001 16:13:23 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2E0AcY85978; Tue, 13 Mar 2001 16:10:38 -0800 (PST) (envelope-from obrien) Date: Tue, 13 Mar 2001 16:09:17 -0800 From: "David O'Brien" To: Kris Kennaway Cc: freebsd-arch@FreeBSD.org, Peter Pentchev Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010313160916.B85900@dragon.nuxi.com> Reply-To: freebsd-arch@FreeBSD.org References: <20010313211544.B17733@ringworld.oblivion.bg> <20010313133909.A83966@dragon.nuxi.com> <20010313135440.A18045@mollari.cthul.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010313135440.A18045@mollari.cthul.hu>; from kris@obsecurity.org on Tue, Mar 13, 2001 at 01:54:40PM -0800 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 X-Loop: FreeBSD.ORG On Tue, Mar 13, 2001 at 01:54:40PM -0800, Kris Kennaway wrote: > > Add the code to lukemftpd too :-) Let it go thru him first then. > You've already got quite a bit of merge work to do, so this shouldn't > be used as an argument to stifle development on the current ftpd. B.S. There is a limit to how much work one is willing to do. As you mention it already isn't at a "fun" level. Much more and it will be at the imposible level and for no good reason. Look, just how many sites MASTER_SITES is this change going to cover? I would take a SWAG of 10%. Whoopie! Excuse me if that figure doesn't excite me considering the extra merge and maintance work this change would bring on. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 13 19:10:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id C29FC37B71A; Tue, 13 Mar 2001 19:10:37 -0800 (PST) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net (client-151-198-117-206.nnj.dialup.bellatlantic.net [151.198.117.206]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id WAA01314; Tue, 13 Mar 2001 22:10:33 -0500 (EST) Message-ID: <3AAEE129.43C6ECBB@bellatlantic.net> Date: Tue, 13 Mar 2001 22:10:33 -0500 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: Robert Watson , Mike Smith , freebsd-arch@freebsd.org, Alfred Perlstein Subject: Re: how do I get sysctl node names ? References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've moved it to -arch instead of developers. Robert Watson wrote: > > On Mon, 12 Mar 2001, Sergey Babkin wrote: > > > I want to commit PR kern/14584. My original patch uses a sysctl variable > > to optionally enable the feature of unified UID&GID space. So I wonder > I have no problem with you adding the vfs.ufs sysctl tree. I would object > strongly to committing the UID/GID code without substantial architectural > discussion and review on at least freebsd-fs and freebsd-arch. I've discussed this idea shortly with Kirk McKusick at Usenix-2000 at the BSD BOF and he generally liked it and suggested to discuss it with you. I've sent you a personal e-mail but got no answer. Then I got distracted with other things and got back to it only now. (And yes, I wrote about it a couple of times in -hackers, with the only response from a guy who wanted to get and use my patch). > developers@FreeBSD.org is not an adequate forum for review for pretty much > anything except a developers- or commit-related policy question -- it's Well, I supposed that the sysctl namespace distribution policy is one of such policies. I'm sorry if I was wrong. > Given that I'm about go commit setfacl and getfacl, and related kernel > code to 5.0-CURRENT, and that ACLs are only marginally more confusing than > a combined uid/gid namespace, I suspect that while this is a cute > work-around to UNIX permission scariness, it's not the right long-term > solution. I'd welcome discussion on freebsd-arch/fs/et al, needless to > say, as there are some nice properties to the patch. The problem I see with ACLs is that they break all the standard Unix commands dealing with displaying or storing the permissions, such as ls, tar, cpio and others of this sort. Probably the ACLs are _the_ way to go for the high-security environments. But from my personal experience with systems administration of HP-UX and NetWare in not-so-high-security environments, the careless application of ACLs tends to cause quite a systems administration nighmare. So I personally would avoid them for as long as possible and use only when really neccessary. And that seems to be not only my experience. For example, in UnixWare the ACLs were implemented and then essentially scrapped (never ported to VxFS and left working only as remnants in SFS, a version of FFS with ACLs which does not seem to be used by anyone any more and which may not be used as a root filesystem any more). This is the reason why I think that the classic Unix permissions still have a long live ahead, so some backwards-compatible extensions to them might be quite usable. I made my patch conditionally compiled and if compiled then still disabled by default and configurable with sysctl to ensure full backwards compatibility in the default configuration. NetWare seems to have worked for quite a long time with ACLs and I think that they have found a great solution that makes the ACLs a lot cleaner: inheritance of the ACLs down the directories. But obviously the implementation of the inheritance is not so cheap. Another thing I liked in Netware is the hierarchies of groups: a group may be made a member of another group, and the control over the group permissions can be delegated to other users. This part seems to be easy enough to implement over the classic Unix model at the user level. Mike Smith wrote: > > > I want to commit PR kern/14584. My original patch uses a sysctl > > Can you elaborate on the "unified UID & GID space" concept? Basically, I It has a rather long description in the PR. In short, the idea is that all the IDs above some value get shared by both users and groups. That is, not only two users can't have the same IDs (unless they are just aliases like root and toor) and two groups can't have the same ID, but an user and a group can't have the same ID as well. This allows to use the UID field in the inodes to give permissions in the unified UID&GID space, and thus give two groups (say, "writers" and "readers") different permissions to the file wtihout resorting to trickery with subdirectories. > think you're in the right general area, but I'm not sure about "commonid" > (I'd prefer common_id, but suspect that maybe base_ugid etc. might be > more appropriate, depending on what this actually does...) common_id is fine with me. Or if there is a strong feeling that it should be something like base_ugid, that's OK too. Alfred Perlstein wrote: > > I might have missed something, but what about making it a mount > option? I think that this should be a system-wide option: the /etc/passwd ang /etc/group files are common for the whole OS, and this option describes their contents. So setting this value per filesystem makes no sense and may cause unobvious errors when different filesystems get mounted by mistake with different values of common ID. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 13 20:59:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 86BA737B71A for ; Tue, 13 Mar 2001 20:59:36 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id VAA28496; Tue, 13 Mar 2001 21:56:17 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpdAAAqRa4H3; Tue Mar 13 21:56:06 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id VAA03061; Tue, 13 Mar 2001 21:59:22 -0700 (MST) From: Terry Lambert Message-Id: <200103140459.VAA03061@usr05.primenet.com> Subject: Re: [PATCH] add a SITE MD5 command to ftpd To: roam@orbitel.bg (Peter Pentchev) Date: Wed, 14 Mar 2001 04:59:22 +0000 (GMT) Cc: freebsd-arch@FreeBSD.ORG In-Reply-To: <20010313211544.B17733@ringworld.oblivion.bg> from "Peter Pentchev" at Mar 13, 2001 09:15:44 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > A recent thread about Bill Fenner's distfiles-checking scripts > set me thinking about easy detection of MD5 checksum mismatches. > Bill Fenner pointed out that these checks are not done because > of the sheer volume of the network traffic needed to download > all the distfiles from all the distsites. > > I know that adding a ``SITE MD5 filename'' command to our ftpd > is a *very* little step in a possibly wrong direction (this will > not automagically make all the ftp daemons on all the distsites > implement this command), but IMHO, it's a start.. I'm thinking > of adding similar functionality to wu-ftpd and ProFTPd soon, and > submitting patches to the authors, in the hope of starting a ball > rolling :) The point of the MD5 is to provide a locally uncorruptable, verifiable crosscheck between the image on a remote side and the contents of a local ports Makefile. People also use MD5 for inage verification; this only works when you can establish an SA (Security Association) between the value of the checksum and the signature, so that a binary with the same signature is considered valid. The DNS, sendmail, and other people normally do this by signing email containing the signature announcement. It seems to me that if Iwere to rely on a "SITE MD5 filename" command as my crosscheck, that it doesn't really matter what the real MD5 would be, if computed locally, the remote site can lie, and tell me that it's anything it wants to tell me, in order to get me to accept the validity of the binary. In other words, we are back to sites being trusted for their content, rather than a distrust of content. Indeed, I can see "Bob's super fast FTP daemon" (or whatever) using a cached list of filename/MD5 pairs to be able to more quickly answer such requests, should these things become popular, for some reason (per above, that reason won't be security, obviously). I can see this happening also for FTP servers which want to be able to handle higher loads, with the MD5 overhead reducing overall load that you could expect a server to handle. Clearly, "Cached Data Considered Harmful" very quickly comes into play here. So before doing this, ask yourself: 1) Why do we have MD5's at all, in the first place? 2) Does this new extension threaten that reason for them existing in the first place? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 13 21: 4:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 5F25237B718 for ; Tue, 13 Mar 2001 21:04:08 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id VAA04203; Tue, 13 Mar 2001 21:58:07 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpdAAASUaW8h; Tue Mar 13 21:57:48 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id WAA03185; Tue, 13 Mar 2001 22:03:41 -0700 (MST) From: Terry Lambert Message-Id: <200103140503.WAA03185@usr05.primenet.com> Subject: Re: sbufs in userland, proposed solution To: ken@kdm.org (Kenneth D. Merry) Date: Wed, 14 Mar 2001 05:03:40 +0000 (GMT) Cc: arch@FreeBSD.ORG In-Reply-To: <20010313162840.A90872@panzer.kdm.org> from "Kenneth D. Merry" at Mar 13, 2001 04:28:40 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > libcam will be complied with a dependency on libsbuf, so libsbuf will > automatically get pulled in for applications that dynamically link with > libcam. [ ... ] > As for applications that link statically (e.g. camcontrol), they'll have to > add libsbuf to the link line in order to compile. > > There is apparantly no way around the static link problem, so this is > something that has to be done, unless I go with one of the other two > alternatives -- putting sbufs in libc or in libcam. The "library A depends on library B" approach is _supposed_ to work with both static and dynamic linking. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 13 21: 7:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 4EC4C37B719 for ; Tue, 13 Mar 2001 21:07:51 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id WAA93442; Tue, 13 Mar 2001 22:07:39 -0700 (MST) (envelope-from ken) Date: Tue, 13 Mar 2001 22:07:39 -0700 From: "Kenneth D. Merry" To: Terry Lambert Cc: arch@FreeBSD.ORG Subject: Re: sbufs in userland, proposed solution Message-ID: <20010313220739.A93412@panzer.kdm.org> References: <20010313162840.A90872@panzer.kdm.org> <200103140503.WAA03185@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200103140503.WAA03185@usr05.primenet.com>; from tlambert@primenet.com on Wed, Mar 14, 2001 at 05:03:40AM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Mar 14, 2001 at 05:03:40 +0000, Terry Lambert wrote: > > libcam will be complied with a dependency on libsbuf, so libsbuf will > > automatically get pulled in for applications that dynamically link with > > libcam. > > [ ... ] > > > As for applications that link statically (e.g. camcontrol), they'll have to > > add libsbuf to the link line in order to compile. > > > > There is apparantly no way around the static link problem, so this is > > something that has to be done, unless I go with one of the other two > > alternatives -- putting sbufs in libc or in libcam. > > The "library A depends on library B" approach is _supposed_ to > work with both static and dynamic linking. Outside the FreeBSD tree? From talking to John Polstra, it only works automatically with dynamic linking. There are some makefile tricks to make it sort-of happen with static linking (see the MINUSLPAM stuff in share/mk/bsd.libnames.mk) but nothing that I know of that'll make the it work automatically. If there is a way to do it, I'd like to know how, since that would save me from modifying all the ports that use libcam. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 13 21:33:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 48E4237B718; Tue, 13 Mar 2001 21:33:16 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id WAA11649; Tue, 13 Mar 2001 22:27:16 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpdAAAZBayVw; Tue Mar 13 22:27:08 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id WAA03974; Tue, 13 Mar 2001 22:33:07 -0700 (MST) From: Terry Lambert Message-Id: <200103140533.WAA03974@usr05.primenet.com> Subject: Re: how do I get sysctl node names ? To: babkin@bellatlantic.net (Sergey Babkin) Date: Wed, 14 Mar 2001 05:33:07 +0000 (GMT) Cc: rwatson@FreeBSD.ORG (Robert Watson), msmith@FreeBSD.ORG (Mike Smith), freebsd-arch@FreeBSD.ORG, bright@wintelcom.net (Alfred Perlstein) In-Reply-To: <3AAEE129.43C6ECBB@bellatlantic.net> from "Sergey Babkin" at Mar 13, 2001 10:10:33 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > NetWare seems to have worked for quite a long time with ACLs and I > think that they have found a great solution that makes the ACLs a lot > cleaner: inheritance of the ACLs down the directories. But obviously > the implementation of the inheritance is not so cheap. > > Another thing I liked in Netware is the hierarchies of groups: a > group may be made a member of another group, and the control over > the group permissions can be delegated to other users. This part > seems to be easy enough to implement over the classic Unix > model at the user level. I implemented this in UnixWare; I'm the primary author of NXFS, the NetWare eXtended File System, and attributed FS that was used to provide these semantics on NetWare for UNIX running on UnixWare, AIX, and Solaris. I have to say that the implementation I used was much simpler: I defined a "secondary inode" field using spare space in the main inode, and put a second file fork in it. Then I modified the directory reference code in "fsck" to not require directory entries for it, and instead require primaries to point to the secondary. Secondary inodes don't have any lonk count issues. You can also include a primary pointer in the secondary, as a backwards reference. To deal with the inheritance, which is actually really reverse inheritance, given the NetWare semantics, I disallowed hard links on directories. This made parent pointers for directories possible, and unambiguous. For file attributes, you can just look at the parent reference path for the file. This is known (and cached in the DNLC) on lookup. You can also be more sneaky about hard link implementation, which would let you maintain parent pointers correctly for any link access path, but since FreeBSD has vm_object_t issues with the vnode being owned by the system instead of the FS, you won't be able to do this without a bit more work than it first appears it would take. Looking up the files isn't that hard, since there is locality. Plus, if you can get at the file, the attributes would inherit up for any path, and let you get at the file anyway, so you don't care about the files when it comes to inheritance, only the operations where you link an attributed file into a directory where it wasn't before, and want to propagate rights upward. For backup, I cheated: I could set a variable which would make the directory lookups return the fork name of files with forks; this wasn't strictly necessary, but it works. For the forks themselves, I attempted to use a POSIX namespace incursion. I settled on using a ^A as the first character to select the fork on the terminal object; this was driven both by the fact that I only needed 128 character file names, and the fact that the lookup routine in SVR4 derived systems can't correctly propagate a POSIX namespace escape ("///") on a per component basis. FreeBSD has this same design flaw, but on FreeBSD, it's easily fixable, so you don't have to eat the first character of each component, like I did. We had to do an FS at the time to resolve the local application vs. client application coherency problem; not only for mandatory and advisory locking, but also for client cache invalidation. My ideal approach would be to fold the namespace, and turn each file into a directory, and use the namespace escape to select real files in the directory ("data", "rsrc", etc.), but the stacking in FreeBSD isn't quite up to snuff, though the 5.x developement branch, which isn't at all useful for anything you need to put on a production server, IMO, is coming quite close to stacking finally being happy. Backup in the folded namespace case would be done on an exposed view of the underlying ("unfolded") FS namespace, and so would be pretty trivial, actually: expose, backup, hide, or just put the exposure in a publically inaccessable subtree, and use the upper layer mount to expose it somewhere globally accessible. PS: the problems that have been noted elsewhere apply doubly to NFS mounts: no way to deal with ACL stuff there. The namespace escape may or may not work (depends on if the leading "//" is incorrectly compressed to just "/" before being proxied, or if the OS doing the proxying is POSIX compliant). My recommendation is to use a descriptor proxy (see the FICUS papers by John Heidemann), since this would let you proxy ACL operations and anything else your heart desired to proxy, after adding it to an FS. PS: If you wanted to add an fcntl() for directory reading that could do globbing in the kernel, return only matching entries, prefault all inodes returned for the inevitable stat(), etc., you could achieve a 70% speedup on directory operations for SAMBA. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 13 21:47:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id 40DC837B718 for ; Tue, 13 Mar 2001 21:47:29 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id WAA90846; Tue, 13 Mar 2001 22:47:12 -0700 Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp10.phx.gblx.net, id smtpdG31sUa; Tue Mar 13 22:47:10 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id WAA04393; Tue, 13 Mar 2001 22:47:24 -0700 (MST) From: Terry Lambert Message-Id: <200103140547.WAA04393@usr05.primenet.com> Subject: Re: sbufs in userland, proposed solution To: ken@kdm.org (Kenneth D. Merry) Date: Wed, 14 Mar 2001 05:47:24 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), arch@FreeBSD.ORG In-Reply-To: <20010313220739.A93412@panzer.kdm.org> from "Kenneth D. Merry" at Mar 13, 2001 10:07:39 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > The "library A depends on library B" approach is _supposed_ to > > work with both static and dynamic linking. > > Outside the FreeBSD tree? Only if the objects are ELF objects. > From talking to John Polstra, it only works automatically with dynamic > linking. There are some makefile tricks to make it sort-of happen with > static linking (see the MINUSLPAM stuff in share/mk/bsd.libnames.mk) but > nothing that I know of that'll make the it work automatically. > > If there is a way to do it, I'd like to know how, since that would save me > from modifying all the ports that use libcam. There is supposed to be an ELF "depends on" section added to the dependent library, which the linker then uses to load the depended upon library. For dynamic libraries, this is handled by the ld.so doing the dirty work. In the static case, this is supposed to be done by ld, instead. I wouldn't be surprised if there was a bug here. The GCC people seem intent on abandoning static linking entirely, steadfastly leaving the system call ABI selector for Linux vs. FreeBSD vs. whatever, as "undefined", in the hope that people won't make it work anyway. Last time I checked, the bugs in ld were exactly the opposite way around: the link itself should force all symbols to be resolved (as in "RTLD_NOW"), but didn't flag links against libraries that depended on other libraries which weren't explicitly there, and for which there was not a dependency of the type you are making for the shared case (program A links against library B that calls a function defined by library C, but library C is not implicitly or explicitly called for, and the linker flags it on a static link, and fails only at runtime for a dynamic link). Fixing that particular ld bug was very, very hard. It might be easier now, but I ran into a couple of places where ld decided it was "OK" to forget symbol counting across several function calls at the same level. In any case, if it doesn't work with static, it's a violation of the specification, and needs to be fixed. My answer to the libresolv begin jammed into libc has always been to set up a library dependency, without any real symbol references, and let the linker follow the dependency to get the resolver functions from a libresolv. There are a lot of things you can fix by doing this, particularly if the linker "promotes" the library, and only uses the dependency as a factor when deciding precedence for symbol definitions to let users replace library functions with their own functions. It would mean a program linked dynamically on Linux would be able to run on FreeBSD, even though FreeBSD has different system call entry points, and FreeBSD has an implicit inclusion of a libresolv, while Linux has an explicit one (yes, before anyone jumps at me, I know that the manifest constant parameters and structures passed as arguments to the system calls would have to be the same for this to work, too). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 13 22: 3:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [207.154.226.10]) by hub.freebsd.org (Postfix) with ESMTP id 3A0FE37B719 for ; Tue, 13 Mar 2001 22:03:52 -0800 (PST) (envelope-from billf@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1098) id C77F481D01; Wed, 14 Mar 2001 00:03:51 -0600 (CST) Date: Wed, 14 Mar 2001 00:03:51 -0600 From: Bill Fumerola To: freebsd-arch@FreeBSD.org Cc: Peter Pentchev Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010314000351.N31752@elvis.mu.org> References: <20010313211544.B17733@ringworld.oblivion.bg> <20010313133909.A83966@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010313133909.A83966@dragon.nuxi.com>; from TrimYourCc@NUXI.com on Tue, Mar 13, 2001 at 01:39:09PM -0800 X-Operating-System: FreeBSD 4.2-FEARSOME-20010209 i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Mar 13, 2001 at 01:39:09PM -0800, David O'Brien wrote: > I am very against adding Yet One More inconsistency (read local hack) > that takes our ftpd farther from the other BSD's. Some of us have hopes > of using the LukeM/NetBSD ftpd in FreeBSD. This hack will be more more > thing that the nay sayers use to prevent this from happening. Some might argue that in this case you are the nay sayer preventing this from happening simply based on something that might happen.... someday.... maybe. Sounds like a nice feature to me, btw. -- Bill Fumerola - security yahoo / Yahoo! inc. - fumerola@yahoo-inc.com / billf@FreeBSD.org ps. it wouldn't exactly be hard to add it to lukemftpd. he may even possibly do it himself if suggested. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 13 22:27:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from moby.geekhouse.net (moby.geekhouse.net [64.81.6.36]) by hub.freebsd.org (Postfix) with ESMTP id DEFC037B71F for ; Tue, 13 Mar 2001 22:27:41 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@dhcp152.geekhouse.net [192.168.1.152]) by moby.geekhouse.net (8.11.0/8.9.3) with ESMTP id f2E6TP169183; Tue, 13 Mar 2001 22:29:26 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010314000351.N31752@elvis.mu.org> Date: Tue, 13 Mar 2001 22:27:10 -0800 (PST) From: John Baldwin To: Bill Fumerola Subject: Re: [PATCH] add a SITE MD5 command to ftpd Cc: Peter Pentchev , freebsd-arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 14-Mar-01 Bill Fumerola wrote: > On Tue, Mar 13, 2001 at 01:39:09PM -0800, David O'Brien wrote: > >> I am very against adding Yet One More inconsistency (read local hack) >> that takes our ftpd farther from the other BSD's. Some of us have hopes >> of using the LukeM/NetBSD ftpd in FreeBSD. This hack will be more more >> thing that the nay sayers use to prevent this from happening. > > Some might argue that in this case you are the nay sayer preventing > this from happening simply based on something that might happen.... > someday.... maybe. > > Sounds like a nice feature to me, btw. As Terry points out, however, this isn't secure, which makes it less useful than first appears. His 2 questions at the end are good ones. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - 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 Mar 13 22:47:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id 5913C37B719 for ; Tue, 13 Mar 2001 22:47:30 -0800 (PST) (envelope-from roam@orbitel.bg) Received: (qmail 23202 invoked by uid 1000); 14 Mar 2001 06:46:51 -0000 Date: Wed, 14 Mar 2001 08:46:51 +0200 From: Peter Pentchev To: Terry Lambert Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010314084651.A23104@ringworld.oblivion.bg> Mail-Followup-To: Terry Lambert , freebsd-arch@FreeBSD.ORG References: <20010313211544.B17733@ringworld.oblivion.bg> <200103140459.VAA03061@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103140459.VAA03061@usr05.primenet.com>; from tlambert@primenet.com on Wed, Mar 14, 2001 at 04:59:22AM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Mar 14, 2001 at 04:59:22AM +0000, Terry Lambert wrote: > > A recent thread about Bill Fenner's distfiles-checking scripts > > set me thinking about easy detection of MD5 checksum mismatches. > > Bill Fenner pointed out that these checks are not done because > > of the sheer volume of the network traffic needed to download > > all the distfiles from all the distsites. > > > > I know that adding a ``SITE MD5 filename'' command to our ftpd > > is a *very* little step in a possibly wrong direction (this will > > not automagically make all the ftp daemons on all the distsites > > implement this command), but IMHO, it's a start.. I'm thinking > > of adding similar functionality to wu-ftpd and ProFTPd soon, and > > submitting patches to the authors, in the hope of starting a ball > > rolling :) > > The point of the MD5 is to provide a locally uncorruptable, > verifiable crosscheck between the image on a remote side and > the contents of a local ports Makefile. [snip] > > Clearly, "Cached Data Considered Harmful" very quickly comes > into play here. > > So before doing this, ask yourself: > > 1) Why do we have MD5's at all, in the first place? > > 2) Does this new extension threaten that reason for them > existing in the first place? This is NOT meant as a replacement for the local security check that is there for a very good reason. It is only meant to provide some kind of an 'early warning' in those rare, but VERY annoying cases when the distributors reroll the dist tarballs without a version number bumping. If the distributor wants to fool the FreeBSD Ports collection by using an ftpd that pretends to support this, yet does not, then we're absolutely no worse than we are now - the notification for changed checksums only comes when somebody tries to build the port and ends up sending a PR instead. However, if this were to be implemented, on however few of the sites, then it *could* provide a great opportunity even for the maintainers themselves - it is very easy to imagine a remote FTP MD5 checksum tool, that is run by each port maintainer on a regular basis for each of his ports, so things do not get to the point that annoyed users blame the maintainers, the Ports Collection and the FreeBSD project for the deeds of dumb authors. Again, this is not - and can never be - a replacement for the local crosscheck. G'luck, Peter -- This sentence claims to be an Epimenides paradox, but it is lying. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 13 22:49:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id AF65C37B78A for ; Tue, 13 Mar 2001 22:49:12 -0800 (PST) (envelope-from roam@orbitel.bg) Received: (qmail 23214 invoked by uid 1000); 14 Mar 2001 06:48:35 -0000 Date: Wed, 14 Mar 2001 08:48:35 +0200 From: Peter Pentchev To: freebsd-arch@FreeBSD.org Cc: Guido van Rooij Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010314084835.B23104@ringworld.oblivion.bg> Mail-Followup-To: freebsd-arch@FreeBSD.org, Guido van Rooij References: <20010313211544.B17733@ringworld.oblivion.bg> <20010313133909.A83966@dragon.nuxi.com> <20010313225612.A37102@gvr.gvr.org> <20010313160655.A85900@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010313160655.A85900@dragon.nuxi.com>; from TrimYourCc@NUXI.com on Tue, Mar 13, 2001 at 04:06:55PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Mar 13, 2001 at 04:06:55PM -0800, David O'Brien wrote: > On Tue, Mar 13, 2001 at 10:56:12PM +0100, Guido van Rooij wrote: > > On Tue, Mar 13, 2001 at 01:39:09PM -0800, David O'Brien wrote: > > > On Tue, Mar 13, 2001 at 09:15:44PM +0200, Peter Pentchev wrote: > > > > I know that adding a ``SITE MD5 filename'' command to our ftpd > > > > is a *very* little step in a possibly wrong direction (this will > > > > > > I am very against adding Yet One More inconsistency (read local hack) > > > that takes our ftpd farther from the other BSD's. Some of us have hopes > > > of using the LukeM/NetBSD ftpd in FreeBSD. This hack will be more more > > > thing that the nay sayers use to prevent this from happening. > > > > So? If Peter is willing to port his code over? > > I don't quite parse this. Peter is going to do the work of merging LukeM > ftpd and getting LukeM to accept all the changes? Ie, the hope is to put > LukeM ftpd into src/contrib/ and treat it as typical src/contrib/ > software. I am (and I had this on my mind yesterday, even before I posted the first version of the patch) actually going to submit a patch to LukeM's ftpd, too. I wondered if this was worth mentioning in my original e-mail; now I see that I should have said it. G'luck, Peter -- If the meanings of 'true' and 'false' were switched, then this sentence wouldn't be false. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 1:25:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id D285B37B71C for ; Wed, 14 Mar 2001 01:25:40 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2E9Msj92118; Wed, 14 Mar 2001 01:22:54 -0800 (PST) (envelope-from obrien) Date: Wed, 14 Mar 2001 01:21:33 -0800 From: "David O'Brien" To: Peter Pentchev Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010314012132.A91957@dragon.nuxi.com> Reply-To: freebsd-arch@FreeBSD.ORG References: <20010313211544.B17733@ringworld.oblivion.bg> <200103140459.VAA03061@usr05.primenet.com> <20010314084651.A23104@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010314084651.A23104@ringworld.oblivion.bg>; from roam@orbitel.bg on Wed, Mar 14, 2001 at 08:46:51AM +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 X-Loop: FreeBSD.ORG On Wed, Mar 14, 2001 at 08:46:51AM +0200, Peter Pentchev wrote: > > > I know that adding a ``SITE MD5 filename'' command to our ftpd > > > is a *very* little step in a possibly wrong direction (this will ..snip.. > This is NOT meant as a replacement for the local security check > that is there for a very good reason. It is only meant to > provide some kind of an 'early warning' in those rare, but VERY > annoying cases when the distributors reroll the dist tarballs > without a version number bumping. If the distributor wants to > fool the FreeBSD Ports collection by using an ftpd that pretends > to support this, yet does not, then we're absolutely no worse > than we are now - the notification for changed checksums only > comes when somebody tries to build the port and ends up sending > a PR instead. Perhaps you should fill in the details then. First you say "SITE MD5 filename" will keep us from having to download a binary to check it. Then that the check will not really be used for anything. So _exactly_ how do you propose this feature to be used? Only by the fenner script? If so, I think we can provide suffient bandwidth for that w/o this "feature". How will a site that pretends to have this capability yet does not; not make things worse than today? The only way for that to be the case is for nothing/one to trust the result of "SITE MD5 filename" for *any* purpose. If that is the case, why have the "feature"? -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 1:26:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 65A5B37B71A for ; Wed, 14 Mar 2001 01:26:54 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2E9Nxd92173; Wed, 14 Mar 2001 01:23:59 -0800 (PST) (envelope-from obrien) Date: Wed, 14 Mar 2001 01:22:38 -0800 From: "David O'Brien" To: Bill Fumerola Cc: freebsd-arch@FreeBSD.org Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010314012238.B91957@dragon.nuxi.com> Reply-To: freebsd-arch@FreeBSD.org References: <20010313211544.B17733@ringworld.oblivion.bg> <20010313133909.A83966@dragon.nuxi.com> <20010314000351.N31752@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010314000351.N31752@elvis.mu.org>; from billf@mu.org on Wed, Mar 14, 2001 at 12:03:51AM -0600 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 X-Loop: FreeBSD.ORG On Wed, Mar 14, 2001 at 12:03:51AM -0600, Bill Fumerola wrote: > Some might argue that in this case you are the nay sayer preventing > this from happening simply based on something that might happen.... > someday.... maybe. I and another did actually start it and put work into it. Others bogged it down. > Sounds like a nice feature to me, btw. And here I thought you never trusted anything from a remote site... -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 1:27:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id 2CDD937B718 for ; Wed, 14 Mar 2001 01:27:31 -0800 (PST) (envelope-from roam@orbitel.bg) Received: (qmail 77477 invoked by uid 1000); 14 Mar 2001 09:26:51 -0000 Date: Wed, 14 Mar 2001 11:26:51 +0200 From: Peter Pentchev To: freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010314112651.C23104@ringworld.oblivion.bg> Mail-Followup-To: freebsd-arch@FreeBSD.ORG References: <20010313211544.B17733@ringworld.oblivion.bg> <200103140459.VAA03061@usr05.primenet.com> <20010314084651.A23104@ringworld.oblivion.bg> <20010314012132.A91957@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010314012132.A91957@dragon.nuxi.com>; from TrimYourCc@NUXI.com on Wed, Mar 14, 2001 at 01:21:33AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Mar 14, 2001 at 01:21:33AM -0800, David O'Brien wrote: > On Wed, Mar 14, 2001 at 08:46:51AM +0200, Peter Pentchev wrote: > > > > I know that adding a ``SITE MD5 filename'' command to our ftpd > > > > is a *very* little step in a possibly wrong direction (this will > ..snip.. > > This is NOT meant as a replacement for the local security check > > that is there for a very good reason. It is only meant to > > provide some kind of an 'early warning' in those rare, but VERY > > annoying cases when the distributors reroll the dist tarballs > > without a version number bumping. If the distributor wants to > > fool the FreeBSD Ports collection by using an ftpd that pretends > > to support this, yet does not, then we're absolutely no worse > > than we are now - the notification for changed checksums only > > comes when somebody tries to build the port and ends up sending > > a PR instead. > > Perhaps you should fill in the details then. First you say > "SITE MD5 filename" will keep us from having to download a binary to > check it. Then that the check will not really be used for anything. > So _exactly_ how do you propose this feature to be used? Only by the > fenner script? If so, I think we can provide suffient bandwidth for that > w/o this "feature". > > How will a site that pretends to have this capability yet does not; not > make things worse than today? The only way for that to be the case is > for nothing/one to trust the result of "SITE MD5 filename" for *any* > purpose. If that is the case, why have the "feature"? Yes, this is only intended for fenner-like scripts, with the added benefit that a server-side MD5 checksum calculation would give individual port maintainers the ability to easily check their own ports often. G'luck, Peter -- Do you think anybody has ever had *precisely this thought* before? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 8:14:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id 019BD37B71B for ; Wed, 14 Mar 2001 08:14:45 -0800 (PST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.11.3/8.11.1) id f2EGEf920229; Wed, 14 Mar 2001 10:14:41 -0600 (CST) (envelope-from dan) Date: Wed, 14 Mar 2001 10:14:40 -0600 From: Dan Nelson To: Peter Pentchev Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010314101440.A5965@dan.emsphone.com> References: <20010313211544.B17733@ringworld.oblivion.bg> <200103140459.VAA03061@usr05.primenet.com> <20010314084651.A23104@ringworld.oblivion.bg> <20010314012132.A91957@dragon.nuxi.com> <20010314112651.C23104@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.14i In-Reply-To: <20010314112651.C23104@ringworld.oblivion.bg>; from "Peter Pentchev" on Wed Mar 14 11:26:51 GMT 2001 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Mar 14), Peter Pentchev said: > Yes, this is only intended for fenner-like scripts, with the added > benefit that a server-side MD5 checksum calculation would give > individual port maintainers the ability to easily check their own > ports often. Why not just use SIZE and MDTM, then? It serves the same purpose (simply checking to see if the file has changed), and is already implemented in most ftpds. -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 8:21:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id 97B1937B719 for ; Wed, 14 Mar 2001 08:21:47 -0800 (PST) (envelope-from roam@orbitel.bg) Received: (qmail 8696 invoked by uid 1000); 14 Mar 2001 16:21:06 -0000 Date: Wed, 14 Mar 2001 18:21:06 +0200 From: Peter Pentchev To: Dan Nelson Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010314182106.A422@ringworld.oblivion.bg> Mail-Followup-To: Dan Nelson , freebsd-arch@FreeBSD.ORG References: <20010313211544.B17733@ringworld.oblivion.bg> <200103140459.VAA03061@usr05.primenet.com> <20010314084651.A23104@ringworld.oblivion.bg> <20010314012132.A91957@dragon.nuxi.com> <20010314112651.C23104@ringworld.oblivion.bg> <20010314101440.A5965@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010314101440.A5965@dan.emsphone.com>; from dnelson@emsphone.com on Wed, Mar 14, 2001 at 10:14:40AM -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Mar 14, 2001 at 10:14:40AM -0600, Dan Nelson wrote: > In the last episode (Mar 14), Peter Pentchev said: > > Yes, this is only intended for fenner-like scripts, with the added > > benefit that a server-side MD5 checksum calculation would give > > individual port maintainers the ability to easily check their own > > ports often. > > Why not just use SIZE and MDTM, then? It serves the same purpose > (simply checking to see if the file has changed), and is already > implemented in most ftpds. Hmm.. because we do not record this in our port metadata? Actually, after a discussion with David O'Brien on IRC today, I'm having second thoughts about this feature. Maybe in a day or two, after I've slept on it, I'll change my mind about it :) G'luck, Peter -- This sentence claims to be an Epimenides paradox, but it is lying. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 11:16: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id E350637B71A for ; Wed, 14 Mar 2001 11:16:06 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2EJGUh01042 for freebsd-arch@freebsd.org; Wed, 14 Mar 2001 11:16:30 -0800 (PST) (envelope-from obrien) Date: Wed, 14 Mar 2001 11:16:29 -0800 From: "David O'Brien" To: freebsd-arch@freebsd.org Subject: flags settings for modules Message-ID: <20010314111629.A1018@dragon.nuxi.com> Reply-To: freebsd-arch@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i 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 X-Loop: FreeBSD.ORG I committed a change sys/conf/kmod.mk such that modules are now installed with flags "schg" as the kernel has been forever. It was asked of me if the "schg" flags do much more than get in the way now? Some feel we're really using "schg" mainly to inhibit foot shooting. It doesn't really help security or we would set it on more libraries than libc.so.* and a couple of crypto shared libraries. So the question is do we want to keep my change? If so, shouldn't we use "schg" in a *lot* more places? Otherwise it's use is nebulous -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 11:18: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from roaming.cacheboy.net (roaming.cacheboy.net [203.56.168.69]) by hub.freebsd.org (Postfix) with ESMTP id 7CD5B37B718 for ; Wed, 14 Mar 2001 11:17:55 -0800 (PST) (envelope-from adrian@roaming.cacheboy.net) Received: (from adrian@localhost) by roaming.cacheboy.net (8.11.1/8.11.1) id f2E9xMN05233; Wed, 14 Mar 2001 10:59:22 +0100 (CET) (envelope-from adrian) Date: Wed, 14 Mar 2001 10:59:18 +0100 From: Adrian Chadd To: freebsd-arch@FreeBSD.ORG Cc: Peter Pentchev Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010314105918.A5204@roaming.cacheboy.net> References: <20010313211544.B17733@ringworld.oblivion.bg> <200103140459.VAA03061@usr05.primenet.com> <20010314084651.A23104@ringworld.oblivion.bg> <20010314012132.A91957@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010314012132.A91957@dragon.nuxi.com>; from TrimYourCc@NUXI.com on Wed, Mar 14, 2001 at 01:21:33AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Mar 14, 2001, David O'Brien wrote: > Perhaps you should fill in the details then. First you say > "SITE MD5 filename" will keep us from having to download a binary to > check it. Then that the check will not really be used for anything. > So _exactly_ how do you propose this feature to be used? Only by the > fenner script? If so, I think we can provide suffient bandwidth for that > w/o this "feature". > > How will a site that pretends to have this capability yet does not; not > make things worse than today? The only way for that to be the case is > for nothing/one to trust the result of "SITE MD5 filename" for *any* > purpose. If that is the case, why have the "feature"? "Throw more Bandwidth at it" is a short-sighted answer. When we have say, 30,000 ports in our collection, how do you scale having to download each one to check? Lets see. If it were me, I'd take a bunch of machines, distribute them around the world at strategic network points, run a little "mapper" to map each box to the closest URLs in the ports collection, and have each box download them locally. *OR*, someone can write a patch to add something like SITE MD5 to the bsd ftpd, perhaps someone can then do the same to wu-ftpd and proftpd, and then write a small RFC snippet explaining why its a good idea and see if they can get it ratified. Then, you can have a single box at yahoo handle 30,000 ports by simply doing MD5 checks, rather than 30,000 ports by downloading each tarball. Adrian -- Adrian Chadd "Programming is like sex: One mistake and you have to support for a lifetime." -- rec.humor.funny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 11:23:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from phk.freebsd.dk (phk.freebsd.dk [212.242.86.136]) by hub.freebsd.org (Postfix) with ESMTP id BF51937B718; Wed, 14 Mar 2001 11:23:02 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by phk.freebsd.dk (8.9.3/8.9.3) with ESMTP id UAA68764; Wed, 14 Mar 2001 20:23:00 +0100 (CET) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f2EJN0p35529; Wed, 14 Mar 2001 20:23:00 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Adrian Chadd Cc: freebsd-arch@FreeBSD.ORG, Peter Pentchev Subject: Re: [PATCH] add a SITE MD5 command to ftpd In-Reply-To: Your message of "Wed, 14 Mar 2001 10:59:18 +0100." <20010314105918.A5204@roaming.cacheboy.net> Date: Wed, 14 Mar 2001 20:22:59 +0100 Message-ID: <35525.984597779@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010314105918.A5204@roaming.cacheboy.net>, Adrian Chadd writes: >On Wed, Mar 14, 2001, David O'Brien wrote: >*OR*, someone can write a patch to add something like SITE MD5 to the >bsd ftpd, perhaps someone can then do the same to wu-ftpd and proftpd, >and then write a small RFC snippet explaining why its a good idea and >see if they can get it ratified. Then, you can have a single box at >yahoo handle 30,000 ports by simply doing MD5 checks, rather than 30,000 >ports by downloading each tarball. Adrian, That SITE MD5 would amount to innovation and progress. We don't do that in FreeBSD (any more). I think SITE MD5 should be added, so we can get some experience with it. If it isn't a good idea, we'll drop it again, if it is, we will propagate it. The only argument I've seen against was "Uhm, we want to loose our current ftpd in favour of XXX" for some value of XXX. I don't think it is important which version of ftpd we implement it in, so that is hardly an argument against. -- 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 Wed Mar 14 11:43: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 6787137B71A for ; Wed, 14 Mar 2001 11:42:58 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f2EJgw305556 for freebsd-arch@FreeBSD.ORG; Wed, 14 Mar 2001 11:42:58 -0800 (PST) Date: Wed, 14 Mar 2001 11:42:58 -0800 From: Alfred Perlstein To: freebsd-arch@FreeBSD.ORG Subject: Re: flags settings for modules Message-ID: <20010314114258.H29888@fw.wintelcom.net> References: <20010314111629.A1018@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010314111629.A1018@dragon.nuxi.com>; from TrimYourCc@NUXI.com on Wed, Mar 14, 2001 at 11:16:29AM -0800 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * David O'Brien [010314 11:17] wrote: > I committed a change sys/conf/kmod.mk such that modules are now installed > with flags "schg" as the kernel has been forever. > > It was asked of me if the "schg" flags do much more than get in the > way now? Some feel we're really using "schg" mainly to inhibit foot > shooting. It doesn't really help security or we would set it on more > libraries than libc.so.* and a couple of crypto shared libraries. > > So the question is do we want to keep my change? If so, shouldn't we use > "schg" in a *lot* more places? Otherwise it's use is nebulous I see this as being really useful for kernel and modules. As far as using it in other places, it's a bit premature. I had the idea that a system utility that could enable a "highly secure/paraniod" mode could walk the fs adding 'schg' and stripping 'setuid' and 'setgid' on most installed binaries as well as adding the securelevel hooks to the system. The tool had better be able to undo this change as well when in single user mode. I don't see coding this tool as being a major excersize, it just could/ought to be done. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@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 Mar 14 12: 7: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from roaming.cacheboy.net (roaming.cacheboy.net [203.56.168.69]) by hub.freebsd.org (Postfix) with ESMTP id B4A1F37B718 for ; Wed, 14 Mar 2001 12:06:58 -0800 (PST) (envelope-from adrian@roaming.cacheboy.net) Received: (from adrian@localhost) by roaming.cacheboy.net (8.11.1/8.11.1) id f2EK7wP02550; Wed, 14 Mar 2001 21:07:58 +0100 (CET) (envelope-from adrian) Date: Wed, 14 Mar 2001 21:07:58 +0100 From: Adrian Chadd To: Poul-Henning Kamp Cc: freebsd-arch@freebsd.org Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010314210758.A2405@roaming.cacheboy.net> References: <20010314105918.A5204@roaming.cacheboy.net> <35525.984597779@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <35525.984597779@critter>; from phk@critter.freebsd.dk on Wed, Mar 14, 2001 at 08:22:59PM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Mar 14, 2001, Poul-Henning Kamp wrote: > Adrian, > > That SITE MD5 would amount to innovation and progress. We don't do > that in FreeBSD (any more). > hah. > I think SITE MD5 should be added, so we can get some experience with > it. If it isn't a good idea, we'll drop it again, if it is, we > will propagate it. > > The only argument I've seen against was "Uhm, we want to loose our > current ftpd in favour of XXX" for some value of XXX. I don't think > it is important which version of ftpd we implement it in, so that > is hardly an argument against. I think o'brien and a few other irc people pointed out that you can't trust the md5 coming back from the user, so the only thing you *can* do is download the file and check it yourself. Ok, I've thought about this. Assume you trust the ports. If you trust the ports, you trust the URL(s) and MD5(s) in the port. But you don't trust the sites hosting the file. So, you can't trust that the returned filename, size, mtime or md5 are "real". Therefore, you have to download the file to verify. Ok, I understand that. So, working with an untrusted md5. If you don't trust the server itself for whatever reason (black/grey admin or hacker, or some "md5 caching" gone wrong) you can either ignore what it tells you, or treat what it tells you as a "hint". So, if you're downloading files for a port, you don't trust the md5 returned by the server - you md5 it and check it yourself. But, if you're mirroring and/or consistency checking, by trusting a returned md5 you're simply getting a false hit (or miss) and so you either download a new file, or you don't download a file at all. Think of those last two consequences. If you're consistency checking, you either end up wasting bandwidth, or recording a false positive. If you're wasting bandwidth, you still end up MD5ing the file. You would have downloaded it anyway, so there is no loss. Ok, that path is solved. If you record a false positive, then your automatic scripts don't pick up the inconsistency. So, when a user makes a port, he downloads the file, md5s it, finds it inconsistent. No change there. If you're mirroring, then consider the last two consequences again. If you're consistency checking, you either end up wasting bandwidth, or you keep your local copy. Since your local copy is already untrusted to start with, you haven't gained or lost trust. So, if you waste bandwidth- as mentioned before, you would have wasted the bandwidth to start with, so there's no loss. Next, if you recorded a false positive, then you don't change the local copy you already have. An black/grey admin or hacker could do this on a "master server" to propagate a bugged version, and then prevent the newer, perhaps bugfree version from propagating. *this* could pose a bit of a problem. However, the file is untrusted to start with, in the case of "ports" making the port already has an MD5, and without our MD5 checking the bad file will still stay there until someone fixes the server and uploads clean files. In the case of a black or grey admin, you're still screwed to begin with, because the servers aren't trusted. Hence, SITE MD5 doesn't make anything worse. The situation is already untrusted. Please, someone destroy my argument. Adrian -- Adrian Chadd "Programming is like sex: One mistake and you have to support for a lifetime." -- rec.humor.funny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 12:17:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from phk.freebsd.dk (phk.freebsd.dk [212.242.86.136]) by hub.freebsd.org (Postfix) with ESMTP id 7A3C337B718; Wed, 14 Mar 2001 12:17:17 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by phk.freebsd.dk (8.9.3/8.9.3) with ESMTP id VAA69542; Wed, 14 Mar 2001 21:17:16 +0100 (CET) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f2EKHGp36426; Wed, 14 Mar 2001 21:17:16 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Adrian Chadd Cc: freebsd-arch@freebsd.org Subject: Re: [PATCH] add a SITE MD5 command to ftpd In-Reply-To: Your message of "Wed, 14 Mar 2001 21:07:58 +0100." <20010314210758.A2405@roaming.cacheboy.net> Date: Wed, 14 Mar 2001 21:17:16 +0100 Message-ID: <36424.984601036@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >So, you can't trust that the returned filename, size, mtime or md5 >are "real". Heck, you can't even trust that you are talking to the server you think you are talking to. The point here is not to solve all problems in the world, the point here is to improve a common case enough to make life simpler for the majority of us. You will notice that my proposal was SITE MD5 filename [offset [length]] If you are paranoid you issue two MD5 commands: SITE MD5 somesoftware.tgz gets you the entire files MD5, which is easy to fake. Next you select a random piece of the file and ask for the MD5 of that bit: SITE MD5 somesoftware.tgz 383273 283744 Now, unless the other end has the actual file, or a very large database of potential MD5's for that file, they will not be able to answer your question correctly... Hows that... -- 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 Wed Mar 14 12:18: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id F23C837B718; Wed, 14 Mar 2001 12:17:56 -0800 (PST) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id NAA17898; Wed, 14 Mar 2001 13:17:52 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id NAA27218; Wed, 14 Mar 2001 13:17:51 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15023.53743.215996.538067@nomad.yogotech.com> Date: Wed, 14 Mar 2001 13:17:51 -0700 (MST) To: Adrian Chadd Cc: Poul-Henning Kamp , freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd In-Reply-To: <20010314210758.A2405@roaming.cacheboy.net> References: <20010314105918.A5204@roaming.cacheboy.net> <35525.984597779@critter> <20010314210758.A2405@roaming.cacheboy.net> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > That SITE MD5 would amount to innovation and progress. We don't do > > that in FreeBSD (any more). > > > > hah. > > > I think SITE MD5 should be added, so we can get some experience with > > it. If it isn't a good idea, we'll drop it again, if it is, we > > will propagate it. > > > > The only argument I've seen against was "Uhm, we want to loose our > > current ftpd in favour of XXX" for some value of XXX. I don't think > > it is important which version of ftpd we implement it in, so that > > is hardly an argument against. > > I think o'brien and a few other irc people pointed out that you can't > trust the md5 coming back from the user, so the only thing you *can* > do is download the file and check it yourself. I think everyone's is forgetting the 'real' reason for SITE-MD5. It's existance is not one of 'trust', but the reason to do this is because it allows the ports checker (and mirrors) to determine if a file has changed. Not whether or not it's trustable, not whether or not someone has hacked the server, but whether it has changed or not. The current check only sees if the file exists, but has no way of checking to see if the file has changed and the filename is the same. The ports system itself takes care of the 'trust' issue, but the mirror and ports checkers are less worried about security, and are more interested in checking to see if a file is the same. We have the security mechanism in place to make sure the file is 'trustworthy' (at least, a minimal check anyway). SITE-MD5 fixes this problem. It doesn't try to be all things to all people, but it's not trying to solve world-hunger, just make the existing mirroring and check scripts more intelligent w/out requiring massive amounts of wasted bandwidth. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 12:22:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from roaming.cacheboy.net (roaming.cacheboy.net [203.56.168.69]) by hub.freebsd.org (Postfix) with ESMTP id A61D837B719 for ; Wed, 14 Mar 2001 12:22:10 -0800 (PST) (envelope-from adrian@roaming.cacheboy.net) Received: (from adrian@localhost) by roaming.cacheboy.net (8.11.1/8.11.1) id f2EKN0r02759; Wed, 14 Mar 2001 21:23:00 +0100 (CET) (envelope-from adrian) Date: Wed, 14 Mar 2001 21:23:00 +0100 From: Adrian Chadd To: Nate Williams Cc: freebsd-arch@freebsd.org Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010314212300.A2747@roaming.cacheboy.net> References: <20010314105918.A5204@roaming.cacheboy.net> <35525.984597779@critter> <20010314210758.A2405@roaming.cacheboy.net> <15023.53743.215996.538067@nomad.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15023.53743.215996.538067@nomad.yogotech.com>; from nate@yogotech.com on Wed, Mar 14, 2001 at 01:17:51PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Mar 14, 2001, Nate Williams wrote: > I think everyone's is forgetting the 'real' reason for SITE-MD5. It's > existance is not one of 'trust', but the reason to do this is because it > allows the ports checker (and mirrors) to determine if a file has > changed. Not whether or not it's trustable, not whether or not someone > has hacked the server, but whether it has changed or not. I agree. the reasoning for me mentioning trust here is that it was the basis for the entire irc discussion earlier on this (UTC+1) morning as to why it was bad. Some people would say "use rsync!" :-) Adrian -- Adrian Chadd "Programming is like sex: One mistake and you have to support for a lifetime." -- rec.humor.funny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 12:23:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 81CC337B718; Wed, 14 Mar 2001 12:23:56 -0800 (PST) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id NAA18022; Wed, 14 Mar 2001 13:23:55 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id NAA27556; Wed, 14 Mar 2001 13:23:54 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15023.54105.813938.948558@nomad.yogotech.com> Date: Wed, 14 Mar 2001 13:23:53 -0700 (MST) To: Adrian Chadd Cc: Nate Williams , freebsd-arch@freebsd.org Subject: Re: [PATCH] add a SITE MD5 command to ftpd In-Reply-To: <20010314212300.A2747@roaming.cacheboy.net> References: <20010314105918.A5204@roaming.cacheboy.net> <35525.984597779@critter> <20010314210758.A2405@roaming.cacheboy.net> <15023.53743.215996.538067@nomad.yogotech.com> <20010314212300.A2747@roaming.cacheboy.net> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I think everyone's is forgetting the 'real' reason for SITE-MD5. It's > > existance is not one of 'trust', but the reason to do this is because it > > allows the ports checker (and mirrors) to determine if a file has > > changed. Not whether or not it's trustable, not whether or not someone > > has hacked the server, but whether it has changed or not. > > I agree. the reasoning for me mentioning trust here is that it was the > basis for the entire irc discussion earlier on this (UTC+1) morning > as to why it was bad. > > Some people would say "use rsync!" :-) Except that also misses the point. If you can spoof MD5, you can spoof rsync just as easily. SITE-MD5 is an 'advisory' feature, and not a security feature. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 12:24:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [207.154.226.10]) by hub.freebsd.org (Postfix) with ESMTP id 5397A37B719; Wed, 14 Mar 2001 12:24:42 -0800 (PST) (envelope-from billf@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1098) id C9D3D81D01; Wed, 14 Mar 2001 14:24:31 -0600 (CST) Date: Wed, 14 Mar 2001 14:24:31 -0600 From: Bill Fumerola To: John Baldwin Cc: Peter Pentchev , freebsd-arch@FreeBSD.org Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010314142431.P31752@elvis.mu.org> References: <20010314000351.N31752@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Tue, Mar 13, 2001 at 10:27:10PM -0800 X-Operating-System: FreeBSD 4.2-FEARSOME-20010209 i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Mar 13, 2001 at 10:27:10PM -0800, John Baldwin wrote: > As Terry points out, however, this isn't secure, which makes it less useful > than first appears. His 2 questions at the end are good ones. Who would use it to mean "secure"? I'd want clients to use it to determine if they downloaded the file w/o error. Other things like fenner's scripts could use it to see if the file changed (which is pretty handy, as someone pointed out, for mirroring software). Any software author that did use it would have to realize that they'd have to take the server's answer with a truckload of salt. The only thing that is minorly unpleasant about this is how non-standard of a change it is. -- Bill Fumerola - security yahoo / Yahoo! inc. - fumerola@yahoo-inc.com / billf@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 Mar 14 12:29:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [207.154.226.10]) by hub.freebsd.org (Postfix) with ESMTP id 0382737B718 for ; Wed, 14 Mar 2001 12:29:15 -0800 (PST) (envelope-from billf@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1098) id B607781D01; Wed, 14 Mar 2001 14:29:14 -0600 (CST) Date: Wed, 14 Mar 2001 14:29:14 -0600 From: Bill Fumerola To: freebsd-arch@FreeBSD.org Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010314142914.Q31752@elvis.mu.org> References: <20010313211544.B17733@ringworld.oblivion.bg> <20010313133909.A83966@dragon.nuxi.com> <20010314000351.N31752@elvis.mu.org> <20010314012238.B91957@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010314012238.B91957@dragon.nuxi.com>; from TrimYourCc@NUXI.com on Wed, Mar 14, 2001 at 01:22:38AM -0800 X-Operating-System: FreeBSD 4.2-FEARSOME-20010209 i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Mar 14, 2001 at 01:22:38AM -0800, David O'Brien wrote: > > Sounds like a nice feature to me, btw. > > And here I thought you never trusted anything from a remote site... I would trust that if my md5 checksum of a file is the same as the checksum returned by this command that I have the same file that the ftp server has (or I'm no better, without it I would have hoped that anyways, now I just have a little more data). I would also trust that if my checksum is different at a later date, that the file has changed and I need to update my copy. I wouldn't use it in place of a list of known good md5s signed by a trustworthy key because that would be silly. -- Bill Fumerola - security yahoo / Yahoo! inc. - fumerola@yahoo-inc.com / billf@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 Mar 14 12:44:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id CA6E637B719 for ; Wed, 14 Mar 2001 12:44:36 -0800 (PST) (envelope-from nectar@nectar.com) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 86AA418C94; Wed, 14 Mar 2001 14:44:35 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.3/8.9.3) id f2EKiZT50474; Wed, 14 Mar 2001 14:44:35 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Wed, 14 Mar 2001 14:44:35 -0600 From: "Jacques A. Vidrine" To: Peter Pentchev Cc: Dan Nelson , freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010314144434.A2658@hamlet.nectar.com> Mail-Followup-To: "Jacques A. Vidrine" , Peter Pentchev , Dan Nelson , freebsd-arch@FreeBSD.ORG References: <20010313211544.B17733@ringworld.oblivion.bg> <200103140459.VAA03061@usr05.primenet.com> <20010314084651.A23104@ringworld.oblivion.bg> <20010314012132.A91957@dragon.nuxi.com> <20010314112651.C23104@ringworld.oblivion.bg> <20010314101440.A5965@dan.emsphone.com> <20010314182106.A422@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010314182106.A422@ringworld.oblivion.bg>; from roam@orbitel.bg on Wed, Mar 14, 2001 at 06:21:06PM +0200 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Mar 14, 2001 at 06:21:06PM +0200, Peter Pentchev wrote: > Hmm.. because we do not record this in our port metadata? > > Actually, after a discussion with David O'Brien on IRC today, > I'm having second thoughts about this feature. Maybe in a day > or two, after I've slept on it, I'll change my mind about it :) It sounds reasonable to me. At a minimum, it could be used by the ports system to avoid downloading files that appear like they will not match the MD5 checksum anyway. This would be very handy when the distfile changes, but the maintainer has not yet caught on, e.g. % cd /usr/ports/devel/foo && make >> foo-8.32.tar.gz doesn't seem to exist in /usr/ports/distfiles/. >> Attempting to fetch from ftp://ftp.fooland.com/pub/superfoo/ SITE MD5 reports checksum mismatch, moving on >> Attempting to fetch from ftp://ftp.mirror.com/pub/mirrors/fooland/superfoo/ SITE MD5 reports checksum mismatch, moving on >> Attempting to fetch from ftp://ftp.freebsd.org/pub/distfiles/ Receiving foo-8.32.tar.gz: 100% 4294967295 bytes transferred in 2678401 seconds (1.56 kBps) ===> Extracting for foo-8.32.tar.gz >> Checksum OK for foo-8.32.tar.gz The way it works today, you'll download foo from the first site, and the checksum will fail, which is annoying. OTOH, more and more distfiles are distributed via HTTP, and not FTP, marginalizing the payback of adding this functionality to ftpd. HTTP/1.1 has Content-MD5, but the standard is mostly broken. Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@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 Mar 14 13: 0:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id ED20437B719 for ; Wed, 14 Mar 2001 13:00:34 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2EL0Q303206; Wed, 14 Mar 2001 13:00:26 -0800 (PST) (envelope-from obrien) Date: Wed, 14 Mar 2001 13:00:26 -0800 From: "David O'Brien" To: Nate Williams Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010314130025.A3031@dragon.nuxi.com> Reply-To: freebsd-arch@FreeBSD.ORG References: <20010314105918.A5204@roaming.cacheboy.net> <35525.984597779@critter> <20010314210758.A2405@roaming.cacheboy.net> <15023.53743.215996.538067@nomad.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15023.53743.215996.538067@nomad.yogotech.com>; from nate@yogotech.com on Wed, Mar 14, 2001 at 01:17:51PM -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 X-Loop: FreeBSD.ORG On Wed, Mar 14, 2001 at 01:17:51PM -0700, Nate Williams wrote: > I think everyone's is forgetting the 'real' reason for SITE-MD5. It's > existance is not one of 'trust', but the reason to do this is because it > allows the ports checker (and mirrors) to determine if a file has > changed. Not whether or not it's trustable, not whether or not someone > has hacked the server, but whether it has changed or not. The checker can *easily* keep a list of files sizes and date stamps and compare that. One would get as much trust from `ls -l' as they would "SITE MD5 filename". -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 13: 2:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 4DABC37B718 for ; Wed, 14 Mar 2001 13:02:27 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2EL2QZ03223 for freebsd-arch@FreeBSD.ORG; Wed, 14 Mar 2001 13:02:26 -0800 (PST) (envelope-from obrien) Date: Wed, 14 Mar 2001 13:02:26 -0800 From: "David O'Brien" To: freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010314130226.B3031@dragon.nuxi.com> Reply-To: freebsd-arch@FreeBSD.ORG References: <20010313211544.B17733@ringworld.oblivion.bg> <200103140459.VAA03061@usr05.primenet.com> <20010314084651.A23104@ringworld.oblivion.bg> <20010314012132.A91957@dragon.nuxi.com> <20010314112651.C23104@ringworld.oblivion.bg> <20010314101440.A5965@dan.emsphone.com> <20010314182106.A422@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010314182106.A422@ringworld.oblivion.bg>; from roam@orbitel.bg on Wed, Mar 14, 2001 at 06:21:06PM +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 X-Loop: FreeBSD.ORG On Wed, Mar 14, 2001 at 06:21:06PM +0200, Peter Pentchev wrote: > > Why not just use SIZE and MDTM, then? It serves the same purpose > > (simply checking to see if the file has changed), and is already > > implemented in most ftpds. > > Hmm.. because we do not record this in our port metadata? Then add it! Many have asked over the ages for the distfiles' size to be recorded. That is one reason why files/MD5 -> distfile in the reorg. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 13:37:25 2001 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 2D9C237B718 for ; Wed, 14 Mar 2001 13:37:22 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id WAA56770; Wed, 14 Mar 2001 22:37:21 +0100 (CET) (envelope-from des@ofug.org) 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: freebsd-arch@FreeBSD.ORG Cc: Nate Williams Subject: Re: [PATCH] add a SITE MD5 command to ftpd References: <20010314105918.A5204@roaming.cacheboy.net> <35525.984597779@critter> <20010314210758.A2405@roaming.cacheboy.net> <15023.53743.215996.538067@nomad.yogotech.com> <20010314130025.A3031@dragon.nuxi.com> From: Dag-Erling Smorgrav Date: 14 Mar 2001 22:37:20 +0100 In-Reply-To: "David O'Brien"'s message of "Wed, 14 Mar 2001 13:00:26 -0800" Message-ID: Lines: 11 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "David O'Brien" writes: > The checker can *easily* keep a list of files sizes and date stamps and > compare that. Date stamps are useless. They'd be different on different master sites anyway. File size is almost as bad, as two files can very easily be totally different and still have the same size. 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 Wed Mar 14 13:38:51 2001 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 5CC9A37B719 for ; Wed, 14 Mar 2001 13:38:48 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id WAA56785; Wed, 14 Mar 2001 22:38:43 +0100 (CET) (envelope-from des@ofug.org) 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: "Jacques A. Vidrine" Cc: Peter Pentchev , Dan Nelson , freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd References: <20010313211544.B17733@ringworld.oblivion.bg> <200103140459.VAA03061@usr05.primenet.com> <20010314084651.A23104@ringworld.oblivion.bg> <20010314012132.A91957@dragon.nuxi.com> <20010314112651.C23104@ringworld.oblivion.bg> <20010314101440.A5965@dan.emsphone.com> <20010314182106.A422@ringworld.oblivion.bg> <20010314144434.A2658@hamlet.nectar.com> From: Dag-Erling Smorgrav Date: 14 Mar 2001 22:38:42 +0100 In-Reply-To: "Jacques A. Vidrine"'s message of "Wed, 14 Mar 2001 14:44:35 -0600" Message-ID: Lines: 11 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Jacques A. Vidrine" writes: > It sounds reasonable to me. At a minimum, it could be used by the > ports system to avoid downloading files that appear like they will > not match the MD5 checksum anyway. If someone adds the 'SITE MD5' command to FreeBSD's ftpd, I'll add code to libfetch and fetch(1) to check the MD5 before downloading. 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 Wed Mar 14 14: 0:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id DAC5237B71D for ; Wed, 14 Mar 2001 14:00:19 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2EM0EG82015; Wed, 14 Mar 2001 14:00:14 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010314142431.P31752@elvis.mu.org> Date: Wed, 14 Mar 2001 13:59:53 -0800 (PST) From: John Baldwin To: Bill Fumerola Subject: Re: [PATCH] add a SITE MD5 command to ftpd Cc: freebsd-arch@FreeBSD.org, Peter Pentchev Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 14-Mar-01 Bill Fumerola wrote: > On Tue, Mar 13, 2001 at 10:27:10PM -0800, John Baldwin wrote: > >> As Terry points out, however, this isn't secure, which makes it less useful >> than first appears. His 2 questions at the end are good ones. > > Who would use it to mean "secure"? I'd want clients to use it to > determine if they downloaded the file w/o error. Other things > like fenner's scripts could use it to see if the file changed (which > is pretty handy, as someone pointed out, for mirroring software). As long as the MD5 is confirmed by the local machine if the file is downloaded (fenner's script wouldn't need this, but paranoid mirroring software might) then I guess that should cover most bases. I didn't say it was useless, just less useful than first appears, which might be better stated as less useful than it might first appear, since different people will have different first perceptions. > Any software author that did use it would have to realize that > they'd have to take the server's answer with a truckload of salt. Yes, it can't be used to avoid a local md5 check of the file, for example. > The only thing that is minorly unpleasant about this is how non-standard > of a change it is. It lives under SITE. If it becomes widespread enough in use, then it might one day end up in the standard. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - 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 Wed Mar 14 14:17: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id 65E8537B72D for ; Wed, 14 Mar 2001 14:16:51 -0800 (PST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.11.3/8.11.1) id f2EMGkZ25692; Wed, 14 Mar 2001 16:16:47 -0600 (CST) (envelope-from dan) Date: Wed, 14 Mar 2001 16:16:46 -0600 From: Dan Nelson To: Dag-Erling Smorgrav Cc: freebsd-arch@FreeBSD.ORG, Nate Williams Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010314161646.A1482@dan.emsphone.com> References: <20010314105918.A5204@roaming.cacheboy.net> <35525.984597779@critter> <20010314210758.A2405@roaming.cacheboy.net> <15023.53743.215996.538067@nomad.yogotech.com> <20010314130025.A3031@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.14i In-Reply-To: ; from "Dag-Erling Smorgrav" on Wed Mar 14 22:37:20 GMT 2001 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Mar 14), Dag-Erling Smorgrav said: > "David O'Brien" writes: > > The checker can *easily* keep a list of files sizes and date stamps > > and compare that. > > Date stamps are useless. They'd be different on different master > sites anyway. File size is almost as bad, as two files can very > easily be totally different and still have the same size. But how often do port distfiles change, but keep their size? Pretty low, I'd say, at least compared to the number of times the size changes and the filename stays the same. Another thing to consider before adding SITE MD5 as a command is that it's an extremely slow operation. md5'ing a 10MB file takes about 1/3rd of a second on my pIII/600. It would take 5 minutes of CPU time to md5 1-gig worth of sources, and that's assuming that the FTP server is idle. ftpd would have to cache the md5 checksum somewhere for it to be acceptable, and then you've got the same caching problem (how does ftpd know when the file has changed to is can update its cached md5?). -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 14:19:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id CB26D37B719 for ; Wed, 14 Mar 2001 14:19:53 -0800 (PST) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id PAA19996; Wed, 14 Mar 2001 15:19:37 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id PAA01352; Wed, 14 Mar 2001 15:19:31 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15023.61042.768406.854325@nomad.yogotech.com> Date: Wed, 14 Mar 2001 15:19:30 -0700 (MST) To: Dan Nelson Cc: Dag-Erling Smorgrav , freebsd-arch@FreeBSD.ORG, Nate Williams Subject: Re: [PATCH] add a SITE MD5 command to ftpd In-Reply-To: <20010314161646.A1482@dan.emsphone.com> References: <20010314105918.A5204@roaming.cacheboy.net> <35525.984597779@critter> <20010314210758.A2405@roaming.cacheboy.net> <15023.53743.215996.538067@nomad.yogotech.com> <20010314130025.A3031@dragon.nuxi.com> <20010314161646.A1482@dan.emsphone.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > The checker can *easily* keep a list of files sizes and date stamps > > > and compare that. > > > > Date stamps are useless. They'd be different on different master > > sites anyway. File size is almost as bad, as two files can very > > easily be totally different and still have the same size. > > But how often do port distfiles change, but keep their size? Often enough that it's been seen. > Pretty low, I'd say, at least compared to the number of times the size > changes and the filename stays the same. True, but now we'd have to modify every port to include both the MD5 *AND* filesize information in the port. Right now the MD5 is part of the port, so all the information is necessary in the ports tree to do the SITE-MD5, except for the ftp infrastructure. > Another thing to consider before adding SITE MD5 as a command is that > it's an extremely slow operation. md5'ing a 10MB file takes about > 1/3rd of a second on my pIII/600. It would take 5 minutes of CPU time > to md5 1-gig worth of sources, and that's assuming that the FTP server > is idle. ftpd would have to cache the md5 checksum somewhere for it > to be acceptable, and then you've got the same caching problem (how > does ftpd know when the file has changed to is can update its cached > md5?). Is that cost greater than the cost of sending the data out over the wire? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 14:57:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id F141F37B718 for ; Wed, 14 Mar 2001 14:57:35 -0800 (PST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.11.3/8.11.1) id f2EMvSh11825; Wed, 14 Mar 2001 16:57:28 -0600 (CST) (envelope-from dan) Date: Wed, 14 Mar 2001 16:57:27 -0600 From: Dan Nelson To: Nate Williams Cc: Dag-Erling Smorgrav , freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010314165727.A2240@dan.emsphone.com> References: <20010314105918.A5204@roaming.cacheboy.net> <35525.984597779@critter> <20010314210758.A2405@roaming.cacheboy.net> <15023.53743.215996.538067@nomad.yogotech.com> <20010314130025.A3031@dragon.nuxi.com> <20010314161646.A1482@dan.emsphone.com> <15023.61042.768406.854325@nomad.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.14i In-Reply-To: <15023.61042.768406.854325@nomad.yogotech.com>; from "Nate Williams" on Wed Mar 14 15:19:30 GMT 2001 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Mar 14), Nate Williams said: > > Another thing to consider before adding SITE MD5 as a command is > > that it's an extremely slow operation. md5'ing a 10MB file takes > > about 1/3rd of a second on my pIII/600. It would take 5 minutes of > > CPU time to md5 1-gig worth of sources, and that's assuming that > > the FTP server is idle. ftpd would have to cache the md5 checksum > > somewhere for it to be acceptable, and then you've got the same > > caching problem (how does ftpd know when the file has changed to is > > can update its cached md5?). > > Is that cost greater than the cost of sending the data out over the > wire? Depends. Are we planning on only using the MD5 feature in Bill Fenner's port-checking scripts, or are we going to put it in bsd.port.mk? Do we want a thousand people doing "SITE MD5" commands every time a new copy of Netscape/Apache/kde/whatever comes out? You have to balance the cost of forcing an MD5 calc for every port fetch against the chance of a SIZE check returning a false-positive match. -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 15:10:28 2001 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 A820637B744 for ; Wed, 14 Mar 2001 15:10:17 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id AAA57195; Thu, 15 Mar 2001 00:10:13 +0100 (CET) (envelope-from des@ofug.org) 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: Dan Nelson Cc: Nate Williams , freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd References: <20010314105918.A5204@roaming.cacheboy.net> <35525.984597779@critter> <20010314210758.A2405@roaming.cacheboy.net> <15023.53743.215996.538067@nomad.yogotech.com> <20010314130025.A3031@dragon.nuxi.com> <20010314161646.A1482@dan.emsphone.com> <15023.61042.768406.854325@nomad.yogotech.com> <20010314165727.A2240@dan.emsphone.com> From: Dag-Erling Smorgrav Date: 15 Mar 2001 00:10:12 +0100 In-Reply-To: Dan Nelson's message of "Wed, 14 Mar 2001 16:57:27 -0600" Message-ID: Lines: 17 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dan Nelson writes: > Depends. Are we planning on only using the MD5 feature in Bill > Fenner's port-checking scripts, or are we going to put it in > bsd.port.mk? Do we want a thousand people doing "SITE MD5" commands > every time a new copy of Netscape/Apache/kde/whatever comes out? Hmm, I've been thinking for a long time of writing a VFS layer that reports the MD5 of a file as an extended attribute or something, and automatically recomputes it if the file is written to. Could be real useful for cvsup, too. Unfortunately, I'm not sure VFS layering works well enough for this to work. 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 Wed Mar 14 15:10:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id DBC1F37B71A for ; Wed, 14 Mar 2001 15:10:27 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2ENAMt05357; Wed, 14 Mar 2001 15:10:22 -0800 (PST) (envelope-from obrien) Date: Wed, 14 Mar 2001 15:10:22 -0800 From: "David O'Brien" To: Nate Williams Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010314151022.B5250@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20010314105918.A5204@roaming.cacheboy.net> <35525.984597779@critter> <20010314210758.A2405@roaming.cacheboy.net> <15023.53743.215996.538067@nomad.yogotech.com> <20010314130025.A3031@dragon.nuxi.com> <20010314161646.A1482@dan.emsphone.com> <15023.61042.768406.854325@nomad.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15023.61042.768406.854325@nomad.yogotech.com>; from nate@yogotech.com on Wed, Mar 14, 2001 at 03:19:30PM -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 X-Loop: FreeBSD.ORG On Wed, Mar 14, 2001 at 03:19:30PM -0700, Nate Williams wrote: > > > > The checker can *easily* keep a list of files sizes and date stamps > > > > and compare that. > > > > > > Date stamps are useless. They'd be different on different master > > > sites anyway. File size is almost as bad, as two files can very > > > easily be totally different and still have the same size. > > > > But how often do port distfiles change, but keep their size? > > Often enough that it's been seen. > > > Pretty low, I'd say, at least compared to the number of times the size > > changes and the filename stays the same. > > True, but now we'd have to modify every port to include both the MD5 > *AND* filesize information in the port. Right now the MD5 is part of > the port, so all the information is necessary in the ports tree to do > the SITE-MD5, except for the ftp infrastructure. Can you address the fact that the majority of MASTERSITES either use HTTP, or offer it and is thus given perference by all maintainers (except me). Thus this hack has pretty low coverage, *even* if you get the native Linux, wu-ftpd, and ProFTPd to accept it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 15:13:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id C32AB37B718 for ; Wed, 14 Mar 2001 15:13:26 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2ENDJB05421; Wed, 14 Mar 2001 15:13:19 -0800 (PST) (envelope-from obrien) Date: Wed, 14 Mar 2001 15:13:18 -0800 From: "David O'Brien" To: Poul-Henning Kamp Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010314151318.C5250@dragon.nuxi.com> Reply-To: freebsd-arch@FreeBSD.ORG References: <20010314105918.A5204@roaming.cacheboy.net> <35525.984597779@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <35525.984597779@critter>; from phk@critter.freebsd.dk on Wed, Mar 14, 2001 at 08:22:59PM +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 X-Loop: FreeBSD.ORG On Wed, Mar 14, 2001 at 08:22:59PM +0100, Poul-Henning Kamp wrote: > That SITE MD5 would amount to innovation and progress. We don't do > that in FreeBSD (any more). > One person's "innovation" is another's "total hack". You certainly push to keep hacks out of the kernel. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 15:38:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by hub.freebsd.org (Postfix) with ESMTP id 5FD2B37B718 for ; Wed, 14 Mar 2001 15:38:46 -0800 (PST) (envelope-from marcel@cup.hp.com) Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.0.100.30]) by palrel3.hp.com (Postfix) with ESMTP id ADD96DA4; Wed, 14 Mar 2001 15:38:45 -0800 (PST) Received: from cup.hp.com (gauss.cup.hp.com [15.28.97.152]) by adlmail.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id PAA25758; Wed, 14 Mar 2001 15:38:41 -0800 (PST) Message-ID: <3AB00101.DD771066@cup.hp.com> Date: Wed, 14 Mar 2001 15:38:41 -0800 From: Marcel Moolenaar Organization: Hewlett-Packard X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: "Kenneth D. Merry" , arch@FreeBSD.ORG Subject: Re: sbufs in userland, proposed solution References: <200103140547.WAA04393@usr05.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > There is supposed to be an ELF "depends on" section added to > the dependent library, which the linker then uses to load the > depended upon library. > > For dynamic libraries, this is handled by the ld.so doing the > dirty work. In the static case, this is supposed to be done > by ld, instead. Static libraries aren't ELF objects themselves and thus won't ever contain a "depends on" section. The (possible) ELF objects in the archive can't have "depends on" sections, because those don't exist for relocatable objects if the objects are ELF in the first place. -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 15:43: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 1B66C37B718 for ; Wed, 14 Mar 2001 15:42:57 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id QAA27573; Wed, 14 Mar 2001 16:36:16 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpdAAAfCaGU1; Wed Mar 14 16:36:04 2001 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id QAA09233; Wed, 14 Mar 2001 16:42:41 -0700 (MST) From: Terry Lambert Message-Id: <200103142342.QAA09233@usr08.primenet.com> Subject: Re: [PATCH] add a SITE MD5 command to ftpd To: roam@orbitel.bg (Peter Pentchev) Date: Wed, 14 Mar 2001 23:42:36 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), freebsd-arch@FreeBSD.ORG In-Reply-To: <20010314084651.A23104@ringworld.oblivion.bg> from "Peter Pentchev" at Mar 14, 2001 08:46:51 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ ... avoid downloading wrong file when name has not changed ... ] I think it would be better to put metadata in the archive, at the front, and just downloa tthat, and abort the transfer if it's the wrong one. I now understand that this is intended to handle that very special case, and only that case, even though people will probably depend on it for "security" anyway, if it's there. > However, if this were to be implemented, on however few of the sites, > then it *could* provide a great opportunity even for the maintainers > themselves - it is very easy to imagine a remote FTP MD5 checksum > tool, that is run by each port maintainer on a regular basis for each > of his ports, so things do not get to the point that annoyed users > blame the maintainers, the Ports Collection and the FreeBSD project > for the deeds of dumb authors. I'm of the opinion that if you were a site, and you supported a large number of connections, it would not be in your best interests to implement this feature: it has dubious value at best, and it costs you resources to do the calculation. Put another way, for 5,000 clients, I'd rather have each one run the checksum locally, rather than me having to run it 5,000 times, only to have it accepted and downloaded anyway. I think this would end up making my FTP server CPU bound instead of I/O bound. It's already memory bound, so it would steal some memory from me, which I could otherwise use to support additional client machines. Also, since FTP transfers are linear without reuse, reading once for the sum and again for the transfer is going to thrash my buffer cache, costing me even more CPU and latency to thrash them back in. If you had to have this, it would be much better, since large FTP servers are generally write-mostly, to build the MD5 into the FS metadata, and calculate it each time a file is closed after having been modified/created. This would let the ftpd do a low cost fcntl()/stat() operation to get the information, instead of making it run an expensive calculation. I think it's like GNUtella: if a few people have it, it's good; if everone has it, it falls apart under load. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 15:52:43 2001 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 6E34A37B718; Wed, 14 Mar 2001 15:52:37 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id AAA57483; Thu, 15 Mar 2001 00:46:15 +0100 (CET) (envelope-from des@ofug.org) 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: Sergey Babkin Cc: obrien@FreeBSD.org, arch@FreeBSD.org Subject: Re: how do I get sysctl node names ? References: <3AAD7529.9F964E6E@bellatlantic.net> <20010312225530.A35431@dragon.nuxi.com> <3AAED48E.822BB6BF@bellatlantic.net> From: Dag-Erling Smorgrav Date: 15 Mar 2001 00:46:15 +0100 In-Reply-To: Sergey Babkin's message of "Tue, 13 Mar 2001 21:16:46 -0500" Message-ID: Lines: 11 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [redirected from -developers] Sergey Babkin writes: > Asking about the policy of the sysctl namespace seemed to me > as something belonging to this list, i.e. an organisational issue. No, it's -arch fodder. -developers is only for matters that concern noone but the committers. 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 Wed Mar 14 16: 1:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 6858837B71C for ; Wed, 14 Mar 2001 16:01:49 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id QAA09211; Wed, 14 Mar 2001 16:47:51 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpdAAAz9aqYr; Wed Mar 14 16:47:34 2001 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id QAA09476; Wed, 14 Mar 2001 16:53:24 -0700 (MST) From: Terry Lambert Message-Id: <200103142353.QAA09476@usr08.primenet.com> Subject: Re: [PATCH] add a SITE MD5 command to ftpd To: nate@yogotech.com Date: Wed, 14 Mar 2001 23:53:19 +0000 (GMT) Cc: dnelson@emsphone.com (Dan Nelson), des@ofug.org (Dag-Erling Smorgrav), freebsd-arch@FreeBSD.ORG In-Reply-To: <15023.61042.768406.854325@nomad.yogotech.com> from "Nate Williams" at Mar 14, 2001 03:19:30 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Another thing to consider before adding SITE MD5 as a command is that > > it's an extremely slow operation. md5'ing a 10MB file takes about > > 1/3rd of a second on my pIII/600. It would take 5 minutes of CPU time > > to md5 1-gig worth of sources, and that's assuming that the FTP server > > is idle. ftpd would have to cache the md5 checksum somewhere for it > > to be acceptable, and then you've got the same caching problem (how > > does ftpd know when the file has changed to is can update its cached > > md5?). > > Is that cost greater than the cost of sending the data out over the > wire? Depends; do we know any FTP servers that trumpet the number of users they are currently supporting, where the marketing benefit of a larger number of users exceeds the benefit of not sending useless files? Remember that the only thing this is useful for is files that change without changing the filename (e.g. no version number in the name, etc.). I'd argue that that was pretty rare. Personally, I like the "SIZE" suggesion. Not only that, it would allow a precomputation of estimated time to completion of a download of a set of files, and could also be used to provide a meaningful "percentage complete" or other progress indicator. Plus it's already there; it's just that the port's aren't storing it when they store the MD5, but that can be changed. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 16: 3:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 73D7C37B719 for ; Wed, 14 Mar 2001 16:03:20 -0800 (PST) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id RAA21834; Wed, 14 Mar 2001 17:03:12 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id RAA02095; Wed, 14 Mar 2001 17:03:11 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15024.1726.752945.368097@nomad.yogotech.com> Date: Wed, 14 Mar 2001 17:03:10 -0700 (MST) To: Terry Lambert Cc: nate@yogotech.com, dnelson@emsphone.com (Dan Nelson), des@ofug.org (Dag-Erling Smorgrav), freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd In-Reply-To: <200103142353.QAA09476@usr08.primenet.com> References: <15023.61042.768406.854325@nomad.yogotech.com> <200103142353.QAA09476@usr08.primenet.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Remember that the only thing this is useful for is files that > change without changing the filename (e.g. no version number > in the name, etc.). > > I'd argue that that was pretty rare. It happens *alot*, if you follow the commit messages. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 16:16: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 3EA8937B718 for ; Wed, 14 Mar 2001 16:16:01 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f2F0FtQ07959; Wed, 14 Mar 2001 16:15:55 -0800 Date: Wed, 14 Mar 2001 16:15:55 -0800 From: Brooks Davis To: Terry Lambert Cc: Peter Pentchev , freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010314161555.A4984@Odin.AC.HMC.Edu> References: <20010314084651.A23104@ringworld.oblivion.bg> <200103142342.QAA09233@usr08.primenet.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200103142342.QAA09233@usr08.primenet.com>; from tlambert@primenet.com on Wed, Mar 14, 2001 at 11:42:36PM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 14, 2001 at 11:42:36PM +0000, Terry Lambert wrote: > I'm of the opinion that if you were a site, and you supported > a large number of connections, it would not be in your best > interests to implement this feature: it has dubious value at > best, and it costs you resources to do the calculation. This is a reasionable objection to the implemention in question, but not to the concept as a whole. If you just cache the MD5 and the mtime at the time of the MD5 you only pay for files that have never been MD5ed or have changed since you last MD5ed them. You could easily cache them either in files the ftp server ignores like .md5. or in a shared cache file. Neither would be all that difficult to implement. The VFS option someone else mentioned could work the same way except being more efficent. I'm frankly, completly mystified by the various comments about this not being a security feature. Of course it's not. That's blindly obvious. That's not the point. As long as it's an option I frankly don't see how it could possiably hurt things and I can't see any good reasion why a reasionably implementation wouldn't spread if people started using clients that could take advantage of it. As for the problem that many distfiles are distributed via HTTP, you could trivialy build an apache module to add a non-standard HTTP header so you could do a "HEAD /file/I/want/to/check HTTP/1.1" and get the MD5 from that. Obviously you wouldn't always want it on and it wouldn't work very well on dynamicaly generated content, but there doesn't seem to be any problem with using it on distfile directories. The comments above on caching the results apply here as well. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6sAm7XY6L6fI4GtQRAtIgAKDY5Dnvd4Wfcwt0DrgHuVFjJEPSDwCfTKl8 oLjVZqmEeOCzVS3rZ06hKCw= =ftV8 -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 18:18: 9 2001 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 8A33137B718 for ; Wed, 14 Mar 2001 18:18:06 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f2F2I5h87542 for ; Wed, 14 Mar 2001 21:18:05 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Wed, 14 Mar 2001 21:18:05 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: freebsd-arch@freebsd.org Subject: Re: flags settings for modules In-Reply-To: <20010314111629.A1018@dragon.nuxi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The effects of schg can be mitigated by circumventing securelevels, which is trivial in most installs, especially in our default installs. Enabling schg in the default install offers little benefit (in fact, it's rather inconvenient). There are hardened environments where schg can be useful, but ours is not one of them. I'd like schg turned off in the default install to unbreak various forms of NFS stuff, and because it's a royal pain to keep stripping schg from binaries, libraries, modules, and the kernel when I need to manually twiddle as opposed to using the Makefile, which happens with surprising frequency as a result of a still-too-small root partition relative to the size of (kernel + modules). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services On Wed, 14 Mar 2001, David O'Brien wrote: > I committed a change sys/conf/kmod.mk such that modules are now installed > with flags "schg" as the kernel has been forever. > > It was asked of me if the "schg" flags do much more than get in the > way now? Some feel we're really using "schg" mainly to inhibit foot > shooting. It doesn't really help security or we would set it on more > libraries than libc.so.* and a couple of crypto shared libraries. > > So the question is do we want to keep my change? If so, shouldn't we use > "schg" in a *lot* more places? Otherwise it's use is nebulous > > -- > -- David (obrien@FreeBSD.org) > GNU is Not Unix / Linux Is Not UniX > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 18:25:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from acampi.inet.it (acampi.inet.it [213.92.4.194]) by hub.freebsd.org (Postfix) with SMTP id 8F5DD37B71C for ; Wed, 14 Mar 2001 18:25:38 -0800 (PST) (envelope-from andrea@webcom.it) Received: (qmail 2820 invoked from network); 15 Mar 2001 03:24:52 -0000 Received: from unknown (HELO webcom.it) (212.239.10.243) by acampi.inet.it with SMTP; 15 Mar 2001 03:24:52 -0000 Received: (qmail 5142 invoked by uid 1000); 15 Mar 2001 02:22:16 -0000 Date: Thu, 15 Mar 2001 03:22:16 +0100 From: Andrea Campi To: Robert Watson Cc: freebsd-arch@freebsd.org Subject: Re: flags settings for modules Message-ID: <20010315032215.G3277@webcom.it> References: <20010314111629.A1018@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rwatson@freebsd.org on Wed, Mar 14, 2001 at 09:18:05PM -0500 X-Echelon: BND CIA NSA Mossad KGB MI6 IRA detonator nuclear assault strike Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Mar 14, 2001 at 09:18:05PM -0500, Robert Watson wrote: > > The effects of schg can be mitigated by circumventing securelevels, which > is trivial in most installs, especially in our default installs. Enabling > schg in the default install offers little benefit (in fact, it's rather > inconvenient). There are hardened environments where schg can be useful, > but ours is not one of them. I'd like schg turned off in the default > install to unbreak various forms of NFS stuff, and because it's a royal > pain to keep stripping schg from binaries, libraries, modules, and the > kernel when I need to manually twiddle as opposed to using the Makefile, > which happens with surprising frequency as a result of a still-too-small > root partition relative to the size of (kernel + modules). Why don't we make it a make(1) variable? Of course this would be in /etc/defaults/make.conf, or whatever comes out of the discussion... Bye, Andrea -- Loose bits sink chips. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 18:40:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 664) id 84A0637B719; Wed, 14 Mar 2001 18:40:51 -0800 (PST) Date: Wed, 14 Mar 2001 18:40:51 -0800 From: David O'Brien To: Andrea Campi Cc: freebsd-arch@freebsd.org Subject: Re: flags settings for modules Message-ID: <20010314184051.A64088@hub.freebsd.org> Reply-To: freebsd-arch@freebsd.org References: <20010314111629.A1018@dragon.nuxi.com> <20010315032215.G3277@webcom.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010315032215.G3277@webcom.it>; from andrea@webcom.it on Thu, Mar 15, 2001 at 03:22:16AM +0100 X-Operating-System: FreeBSD 4.2-STABLE 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 X-Loop: FreeBSD.ORG On Thu, Mar 15, 2001 at 03:22:16AM +0100, Andrea Campi wrote: > Why don't we make it a make(1) variable? I would like to fight the "lets make everything a tuneable knob" syndrom I think we've falling into lately. First lets see if anyone really needs or wants those flag values. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 18:50:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 777D937B719 for ; Wed, 14 Mar 2001 18:50:34 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2F2oQW07958; Wed, 14 Mar 2001 18:50:26 -0800 (PST) (envelope-from obrien) Date: Wed, 14 Mar 2001 18:50:26 -0800 From: "David O'Brien" To: Brooks Davis Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010314185026.C7683@dragon.nuxi.com> Reply-To: freebsd-arch@FreeBSD.ORG References: <20010314084651.A23104@ringworld.oblivion.bg> <200103142342.QAA09233@usr08.primenet.com> <20010314161555.A4984@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010314161555.A4984@Odin.AC.HMC.Edu>; from brooks@one-eyed-alien.net on Wed, Mar 14, 2001 at 04:15:55PM -0800 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 X-Loop: FreeBSD.ORG On Wed, Mar 14, 2001 at 04:15:55PM -0800, Brooks Davis wrote: > I'm frankly, completly mystified by the various comments about this not > being a security feature. Of course it's not. That's blindly obvious. I disagree it is blindly obvious. It wasn't to some I've talked to. We've ended up associating a "security nature" to MD5. Thus when people see that name, they make assumptions. > That's not the point. As long as it's an option I frankly don't see how > it could possibly hurt things and I can't see any good reason why a > reasonably implementation wouldn't spread if people started using > clients that could take advantage of it. How?? are clients going to take advantage of it? For the majority of FTP clients want to fetch the file, so why ask for an MD5 of it? Are you thinking about checking the xfer was OK? That's the only use I can think of. The other uses people have mentioned are very, very specific to a single task done by the FreeBSD Project. > As for the problem that many distfiles are distributed via HTTP, you > could trivialy build an apache module to add a non-standard HTTP header > so you could do a "HEAD /file/I/want/to/check HTTP/1.1" and get the MD5 > from that. Since making a loadable Apache module is so much less intrusive, I call on those wanting to experiment with this feature to do this thru this path. If you can get the Apache people to either bundle the module as a standard thing, or convince large sites to load it; THEN hack ftpd. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 18:56: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 7D39F37B718 for ; Wed, 14 Mar 2001 18:56:06 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f2F2u1b37896; Wed, 14 Mar 2001 18:56:01 -0800 (PST) (envelope-from dillon) Date: Wed, 14 Mar 2001 18:56:01 -0800 (PST) From: Matt Dillon Message-Id: <200103150256.f2F2u1b37896@earth.backplane.com> To: "David O'Brien" , Brooks Davis , freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd References: <20010314084651.A23104@ringworld.oblivion.bg> <200103142342.QAA09233@usr08.primenet.com> <20010314161555.A4984@Odin.AC.HMC.Edu> <20010314185026.C7683@dragon.nuxi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doesn't SITE MD5 introduce a race condition? What if someone does a SITE MD5 and someone else then renames or modifies the file before the first person proceeds to download it? Also, why bother doing an MD5 on the remote site if 99.9% of the time you are going to get a match and download the file anyway? You might as well download it first. Or perhaps simply check the size of the file for a match (e.g. enhance ports to include the file size to check against in addition to the MD5), then download it, then do the MD5 on the local box. I just don't see much point in adding a command to FTP that isn't going to be generally useful and has security holes in it to boot. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 19: 6:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from acampi.inet.it (acampi.inet.it [213.92.4.194]) by hub.freebsd.org (Postfix) with SMTP id EF15F37B718 for ; Wed, 14 Mar 2001 19:06:37 -0800 (PST) (envelope-from andrea@webcom.it) Received: (qmail 2904 invoked from network); 15 Mar 2001 04:05:51 -0000 Received: from unknown (HELO webcom.it) (212.239.10.243) by acampi.inet.it with SMTP; 15 Mar 2001 04:05:51 -0000 Received: (qmail 5697 invoked by uid 1000); 15 Mar 2001 03:03:15 -0000 Date: Thu, 15 Mar 2001 04:03:14 +0100 From: Andrea Campi To: freebsd-arch@freebsd.org Subject: Re: flags settings for modules Message-ID: <20010315040314.H3277@webcom.it> References: <20010314111629.A1018@dragon.nuxi.com> <20010315032215.G3277@webcom.it> <20010314184051.A64088@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010314184051.A64088@hub.freebsd.org>; from TrimYourCC@nuxi.com on Wed, Mar 14, 2001 at 06:40:51PM -0800 X-Echelon: BND CIA NSA Mossad KGB MI6 IRA detonator nuclear assault strike Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Mar 14, 2001 at 06:40:51PM -0800, David O'Brien wrote: > On Thu, Mar 15, 2001 at 03:22:16AM +0100, Andrea Campi wrote: > > Why don't we make it a make(1) variable? > > I would like to fight the "lets make everything a tuneable knob" syndrom > I think we've falling into lately. First lets see if anyone really needs > or wants those flag values. Well, I understand your point of view, but in my opinion there are 2 user groups involved here: security conscious guys, who would like to have all "immutable" files, including all binaries on /, all libraries, whatever (heck, on production machines I'd have /etc/* schg), and more casual users (or users with particular needs) who don't want that because it incomodates that. Apart from the kernel, where I feel schg should stay no matter what, I feel both of these user groups have good reasons. Which one would you favor? Having a knob, probably defaulting to "only kernel schg" for POLA, would be perfect and trivial to implement. On the other hand, this kind of hardening is a candidate for ports/misc/harden... Bye, Andrea -- There's no place like ~ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 19: 9:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [207.154.226.10]) by hub.freebsd.org (Postfix) with ESMTP id F200F37B719 for ; Wed, 14 Mar 2001 19:09:45 -0800 (PST) (envelope-from billf@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1098) id 899E981D01; Wed, 14 Mar 2001 21:09:35 -0600 (CST) Date: Wed, 14 Mar 2001 21:09:35 -0600 From: Bill Fumerola To: freebsd-arch@FreeBSD.ORG Cc: Brooks Davis Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010314210935.Y31752@elvis.mu.org> References: <20010314084651.A23104@ringworld.oblivion.bg> <200103142342.QAA09233@usr08.primenet.com> <20010314161555.A4984@Odin.AC.HMC.Edu> <20010314185026.C7683@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010314185026.C7683@dragon.nuxi.com>; from TrimYourCc@NUXI.com on Wed, Mar 14, 2001 at 06:50:26PM -0800 X-Operating-System: FreeBSD 4.2-FEARSOME-20010209 i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Mar 14, 2001 at 06:50:26PM -0800, David O'Brien wrote: > On Wed, Mar 14, 2001 at 04:15:55PM -0800, Brooks Davis wrote: > > I'm frankly, completly mystified by the various comments about this not > > being a security feature. Of course it's not. That's blindly obvious. > > I disagree it is blindly obvious. It wasn't to some I've talked to. > We've ended up associating a "security nature" to MD5. Thus when people > see that name, they make assumptions. Misconception on security topics by some isn't a reason to limit functionality in our system. -- Bill Fumerola - security yahoo / Yahoo! inc. - fumerola@yahoo-inc.com / billf@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 Mar 14 20:29:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id C151637B719 for ; Wed, 14 Mar 2001 20:29:43 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id VAA00394; Wed, 14 Mar 2001 21:24:08 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp05.primenet.com, id smtpdAAA3RaWNa; Wed Mar 14 21:23:54 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id VAA00913; Wed, 14 Mar 2001 21:29:21 -0700 (MST) From: Terry Lambert Message-Id: <200103150429.VAA00913@usr05.primenet.com> Subject: Re: [PATCH] add a SITE MD5 command to ftpd To: nate@yogotech.com Date: Thu, 15 Mar 2001 04:29:21 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), dnelson@emsphone.com (Dan Nelson), des@ofug.org (Dag-Erling Smorgrav), freebsd-arch@FreeBSD.ORG In-Reply-To: <15024.1726.752945.368097@nomad.yogotech.com> from "Nate Williams" at Mar 14, 2001 05:03:10 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Remember that the only thing this is useful for is files that > > change without changing the filename (e.g. no version number > > in the name, etc.). > > > > I'd argue that that was pretty rare. > > It happens *alot*, if you follow the commit messages. What percentage of ports have been hit by this, according to the commit logs? In my experience, it's much more likely for the file to not be on any of the servers, like the ghostscript6 port in the 4.2 release. A better question might be "how many times has it happened, and the patches still applied successfully, after you made the !$%@! port ignore the MD5 checksum?"... So... is the FreeBSD FTP server going to have this "feature" added to it, or is DG putting his foot down? I still think the SIZE is an OK think; if everyone is in love with the SITE MD5 thing, at least make it so it will prefer the contents of a "site.md5" file in the directory to doing recomputation, or, even better, will cache MD5, filename, and timestamp, look at the timestamp for the name, or if the name doesn't exist, MD5 it, and cache the new value, and if the timestamp is equal, return the cached value. Even a cron job is a lot better than calculating an MD5 5000 times on the same file... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 20:39:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id CD2E537B718 for ; Wed, 14 Mar 2001 20:39:12 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id VAA43732; Wed, 14 Mar 2001 21:38:57 -0700 Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp10.phx.gblx.net, id smtpdePffUa; Wed Mar 14 21:38:56 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id VAA01217; Wed, 14 Mar 2001 21:39:09 -0700 (MST) From: Terry Lambert Message-Id: <200103150439.VAA01217@usr05.primenet.com> Subject: Re: [PATCH] add a SITE MD5 command to ftpd To: brooks@one-eyed-alien.net (Brooks Davis) Date: Thu, 15 Mar 2001 04:39:09 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), roam@orbitel.bg (Peter Pentchev), freebsd-arch@FreeBSD.ORG In-Reply-To: <20010314161555.A4984@Odin.AC.HMC.Edu> from "Brooks Davis" at Mar 14, 2001 04:15:55 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > This is a reasionable objection to the implemention in question, but not > to the concept as a whole. If you just cache the MD5 and the mtime at > the time of the MD5 you only pay for files that have never been MD5ed > or have changed since you last MD5ed them. You could easily cache them > either in files the ftp server ignores like .md5. or in a > shared cache file. Neither would be all that difficult to implement. > The VFS option someone else mentioned could work the same way except > being more efficent. I suggested both of these (see other posts). > I'm frankly, completly mystified by the various comments about this not > being a security feature. Of course it's not. That's blindly obvious. I've always taken it as a security feature. I have to override the enforcement for a number of ports, and the only ill effects I have seen is that ...I have to override the enforcement for a number of ports. I always took it for granted that getting /usr/ports from a known source meant that I had the MD5s -- cryptographic hashes -- that would vet "known good" code from a random source as being the unadulterated version of the code. I really haven't thought about it from a "validation" persepective before this thread, since bad code in one spot is going to be mirrored everywhere, and so is a version number change with a deletion of the old version. In my personal experience, the code that fails the MD5 isn't grabbed from a different server in hopes of getting a copy that doesn't fail the MD5, so I'm just as screwed as if it weren't there. > As for the problem that many distfiles are distributed via HTTP, you > could trivialy build an apache module to add a non-standard HTTP header > so you could do a "HEAD /file/I/want/to/check HTTP/1.1" and get the MD5 > from that. Obviously you wouldn't always want it on and it wouldn't > work very well on dynamicaly generated content, but there doesn't seem > to be any problem with using it on distfile directories. The comments > above on caching the results apply here as well. Better to archive the file as an archive + an MD5 of the archive part, and abort the transfer after getting the MD5 part, if it's the wrong part. If you don't want to get as complicated as a MIME multipart, you could return an MD5 in an XML hunk, and a redirect. The whole idea of HTTP protection like this is pretty inane, since we've all already agreed, I think, that it's really only useful for mirroring, or for offloading an MD5 calculation from my 800MHz Pentium III laptop onto a big, ballsy 66MHz 486 FTP server. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 20:47:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id DA07E37B718 for ; Wed, 14 Mar 2001 20:47:15 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id VAA05400; Wed, 14 Mar 2001 21:41:43 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp05.primenet.com, id smtpdAAAKBaWzk; Wed Mar 14 21:41:29 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id VAA01583; Wed, 14 Mar 2001 21:46:56 -0700 (MST) From: Terry Lambert Message-Id: <200103150446.VAA01583@usr05.primenet.com> Subject: Re: [PATCH] add a SITE MD5 command to ftpd To: billf@mu.org (Bill Fumerola) Date: Thu, 15 Mar 2001 04:46:56 +0000 (GMT) Cc: freebsd-arch@FreeBSD.ORG, brooks@one-eyed-alien.net (Brooks Davis) In-Reply-To: <20010314210935.Y31752@elvis.mu.org> from "Bill Fumerola" at Mar 14, 2001 09:09:35 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I disagree it is blindly obvious. It wasn't to some I've talked to. > > We've ended up associating a "security nature" to MD5. Thus when people > > see that name, they make assumptions. > > Misconception on security topics by some isn't a reason to limit > functionality in our system. Weren't you one of those guys who advocated disabling telnetd, rlogind, rcmd, etc., "proactively"? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 14 21: 8:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail-100baset.rpi.edu [128.113.26.45]) by hub.freebsd.org (Postfix) with ESMTP id 1C9FE37B718 for ; Wed, 14 Mar 2001 21:08:39 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id AAA99344; Thu, 15 Mar 2001 00:08:25 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200103150256.f2F2u1b37896@earth.backplane.com> References: <20010314084651.A23104@ringworld.oblivion.bg> <200103142342.QAA09233@usr08.primenet.com> <20010314161555.A4984@Odin.AC.HMC.Edu> <20010314185026.C7683@dragon.nuxi.com> <200103150256.f2F2u1b37896@earth.backplane.com> Date: Thu, 15 Mar 2001 00:08:23 -0500 To: Matt Dillon , "David O'Brien" , Brooks Davis , freebsd-arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: [PATCH] add a SITE MD5 command to ftpd Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 6:56 PM -0800 3/14/01, Matt Dillon wrote: > Doesn't SITE MD5 introduce a race condition? What if someone > does a SITE MD5 and someone else then renames or modifies the > file before the first person proceeds to download it? And what awful thing will happen then? You can still MD5 the result after you've received it. You will be no worse off than if you simply downloaded the file without doing the MD5. > Also, why bother doing an MD5 on the remote site if 99.9% of > the time you are going to get a match and download the file > anyway? You might as well download it first. If you're going to download it anyway, then there is zero point to doing the MD5. The way I'm reading this option, the ONLY reason to do an MD5 is to try and *-AVOID-* doing a download. That is all I want it for, at least. > Or perhaps simply check the size of the file for a match > (e.g. enhance ports to include the file size to check > against in addition to the MD5), then download it, then > do the MD5 on the local box. I do not agree that SIZE is an adequate check. I have had plenty of times where the size of a file did not change, even though the contents did. Therefore, when a file on a ftp server is the same size as a file I already have, I may still decide to download that file, "just in case it is different". I *have* done that in the past, and there are times when it *was* different, and therefore I keep downloading files. > I just don't see much point in adding a command to FTP that > isn't going to be generally useful and has security holes > in it to boot. The only "security hole" that I see in this is a possible DOS attack (or at least, reduction-in-service), by someone forcing an ftp server to MD5 a massive number of files. I must admit that I am a little uneasy about that. Perhaps implement it so the MD5 calculation is always done at minimum (nice) priority. People seeing this as some kind of security threat misunderstand what it's intent is. I want to know "is the file on the FTP server exactly the same as a file I already have?", and it would be nice to answer that question without having to download the entire file. If it IS exactly what I already have or already know about, then there is no point in me downloading it. If it is NOT, *then* I would want to download it. I would not blindly trust it after downloading it, as that is patently stooopid. I just want to know if it would be a waste of time to download the file before I type up my modem line for a half hour. That is all. Other than the concern about CPU time on the server, I don't see what the problem is. I have trouble believing that it will ever be less load on an ftp server to MD5 a file than it will be for the remote user to download the entire file. Remember, I want this to AVOID doing the download in the first place, and not just as some stupid waste-of-time extra step to do before every download that I intend to do. If I do not already have a file, then I'm going to download it. I am not going to MD5 it. I am puzzled by this thread, but then I also tried to put my shoes on the wrong feet this morning, so maybe I'm just having a bad day. Perhaps we need to use a different name for the option, as some people seem obsessed in thinking that this MD5 digest has something to do with security. I see it as having ABSOLUTELY NOTHING to do with "security". I just want to avoid a download if there is no point in me doing it. Call it: site md5toAvoidDoingADownload filename It seems to me that we could start out doing this as a 'site' command (as long as it isn't me who has to write it...), and see how it goes. If it sucks, then we'll drop it. If it is useful, then, well, it is useful. In a separate message, Terry Lambert wrote: >if everyone is in >love with the SITE MD5 thing, at least make it so it will >prefer the contents of a "site.md5" file in the directory >to doing recomputation, or, even better, will cache MD5, >filename, and timestamp, look at the timestamp for the name, >or if the name doesn't exist, MD5 it, and cache the new value, >and if the timestamp is equal, return the cached value. I like some of these ideas. As I say, my only misgiving about this MD5 idea is the potential for excessive CPU load on the server. Anything which reduces that would be welcome, I think. Er, when he says "prefer a site.md5 file", I assume that the ftp daemon itself would be keeping that md5 file up-to-date. I would not trust a person to do it. Ie, the daemon would basically cache the answers in some filename, instead of in virtual memory... The added benefit of that is some external process could just download that file, and get MD5's for all the files in that directory at one shot. The file might not really be in that directory on the ftp server, but it would look like it is to someone connecting via ftp. -- Garance Alistair Drosehn = gad@eclipse.acs.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 Wed Mar 14 22: 6:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 1E66C37B71E for ; Wed, 14 Mar 2001 22:06:48 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f2F66Vj38988; Wed, 14 Mar 2001 22:06:31 -0800 (PST) (envelope-from dillon) Date: Wed, 14 Mar 2001 22:06:31 -0800 (PST) From: Matt Dillon Message-Id: <200103150606.f2F66Vj38988@earth.backplane.com> To: Garance A Drosihn Cc: "David O'Brien" , Brooks Davis , freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd References: <20010314084651.A23104@ringworld.oblivion.bg> <200103142342.QAA09233@usr08.primenet.com> <20010314161555.A4984@Odin.AC.HMC.Edu> <20010314185026.C7683@dragon.nuxi.com> <200103150256.f2F2u1b37896@earth.backplane.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :If you're going to download it anyway, then there is zero point :to doing the MD5. The way I'm reading this option, the ONLY :reason to do an MD5 is to try and *-AVOID-* doing a download. :That is all I want it for, at least. I'm just trying to think of the situations where a user would do this on a regular basis, and I simply can't imagine that 'unnecessary downloads' would account for then a few percent of all the downloads made from a site. Or even 1%. As far as checking to see if a file has changed or not... insofar as any great use of ftp for synchronizing file trees the modification time and file size has been used for ages and has proven to work extremely well. MD5'ing isn't going to have any great effect on reducing bandwidth verses simply looking at the modification time and file size. I see no point in adding a command that has so little effect on the site's bandwidth useage, provides no significant enhancement of operations OR security, and is yet another thing for the site administrator to have to worry about in regards to abuse. Your comment about checking to see if a file has changed is a case in point.. someone could very easily use the feature to check whole directory trees for changes with insignificant impact on them, but a huge impact on the server if it doesn't cache the MD5's somewhere. A single user MD5ing hundreds of files would have a monsterous impact on an FTP server. On FTP servers, ls -lR is often disabled due to abuse. Many ftp servers still leave it disabled. Most large ftp respositories now run ls -lR as a cron job and store the results in an easily downloadable file precisely because of the abuse that occurs when users run ls -lR's. Frankly, I see no redeeming value for a SITE MD5 command. It would be a whole lot easier for a site administrator to simply generate MD5 lists nightly and store them in files on the ftp server itself for users to download, just like many do for ls -lR. And it doesn't require adding another command to the FTP server to make it work either. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 0:16:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 88D5537B71A for ; Thu, 15 Mar 2001 00:16:07 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f2F8G6920260 for ; Thu, 15 Mar 2001 01:16:06 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200103150816.f2F8G6920260@harmony.village.org> To: freebsd-arch@FreeBSD.ORG Subject: Re: flags settings for modules In-reply-to: Your message of "Wed, 14 Mar 2001 11:16:29 PST." <20010314111629.A1018@dragon.nuxi.com> References: <20010314111629.A1018@dragon.nuxi.com> Date: Thu, 15 Mar 2001 01:16:06 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010314111629.A1018@dragon.nuxi.com> "David O'Brien" writes: : So the question is do we want to keep my change? If so, shouldn't we use : "schg" in a *lot* more places? Otherwise it's use is nebulous I think the change is premature. Until such time as we have a convenient way to build a system that all vectors to compromise of schg have been plugged, setting it to gain "security" is at best folly. I do not argue that one could set schg on files by hand and might be able to not miss any, such an undertaking is still very very difficult. You have to make sure that all the rc scripts are schg. And then all scripts that are run before we raise secure level. And all binaries that are touched (and facist path policing of all scripts). And then there's all the libraries that are linked in against those binaries. And then there are all the modules loaded by default or by the loader. And you have to secure the loader agianst change in a similar way. And let's not forget any config files that all these files/programs use. Oh, and let's not forget those things that are too obscure for me to think of there. There are likely items in the list that I've forgotten. Since the list is still so long, and since there's no one working on tightening things up, I think that adding schg to modules is premature and will cause more hassles than it is worth. Before people think that I don't think that this is worth it, or that I have a negative attitude, I would like to point out that I think work in this area would be beneficial. Warmer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 6:20:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from buddha.automagic.org (buddha-nexxia.automagic.org [207.61.141.34]) by hub.freebsd.org (Postfix) with SMTP id 9037537B719 for ; Thu, 15 Mar 2001 06:20:53 -0800 (PST) (envelope-from jabley@buddha.automagic.org) Received: (qmail 4934 invoked by uid 100); 15 Mar 2001 14:20:47 -0000 Date: Thu, 15 Mar 2001 09:20:47 -0500 From: Joe Abley To: Adrian Chadd Cc: freebsd-arch@FreeBSD.ORG, Peter Pentchev Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010315092047.E8289@buddha.home.automagic.org> References: <20010313211544.B17733@ringworld.oblivion.bg> <200103140459.VAA03061@usr05.primenet.com> <20010314084651.A23104@ringworld.oblivion.bg> <20010314012132.A91957@dragon.nuxi.com> <20010314105918.A5204@roaming.cacheboy.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i In-Reply-To: <20010314105918.A5204@roaming.cacheboy.net>; from adrian@FreeBSD.ORG on Wed, Mar 14, 2001 at 10:59:18AM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Mar 14, 2001 at 10:59:18AM +0100, Adrian Chadd wrote: > On Wed, Mar 14, 2001, David O'Brien wrote: > > > How will a site that pretends to have this capability yet does not; not > > make things worse than today? The only way for that to be the case is > > for nothing/one to trust the result of "SITE MD5 filename" for *any* > > purpose. If that is the case, why have the "feature"? > > "Throw more Bandwidth at it" is a short-sighted answer. When we have say, > 30,000 ports in our collection, how do you scale having to download each > one to check? > > Lets see. If it were me, I'd take a bunch of machines, distribute them > around the world at strategic network points, run a little "mapper" to > map each box to the closest URLs in the ports collection, and have each > box download them locally. > > *OR*, someone can write a patch to add something like SITE MD5 to the > bsd ftpd, perhaps someone can then do the same to wu-ftpd and proftpd, > and then write a small RFC snippet explaining why its a good idea and > see if they can get it ratified. Then, you can have a single box at > yahoo handle 30,000 ports by simply doing MD5 checks, rather than 30,000 > ports by downloading each tarball. *OR* you could distribute the problem the way it is naturally distributed, and build a mechanism whereby a downloaded distfile that fails its MD5 check on any recent build of FreeBSD causes a notification to be sent back to the mother ship. You would make this an optional feature, and stick a question in sysinstall which explains the benefits of doing it. At the mother ship, you would discard all information from the incoming broken-md5 mail except for the origin of the distfile, its length, it's real MD5 and it's ports-MD5. Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 9:14:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id BF2B637B71D for ; Thu, 15 Mar 2001 09:14:50 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f2FHEoR00619 for freebsd-arch@FreeBSD.ORG; Thu, 15 Mar 2001 09:14:50 -0800 Date: Thu, 15 Mar 2001 09:14:50 -0800 From: Brooks Davis To: freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010315091450.B30551@Odin.AC.HMC.Edu> References: <20010314084651.A23104@ringworld.oblivion.bg> <200103142342.QAA09233@usr08.primenet.com> <20010314161555.A4984@Odin.AC.HMC.Edu> <20010314185026.C7683@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="nVMJ2NtxeReIH9PS" Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20010314185026.C7683@dragon.nuxi.com>; from TrimYourCc@NUXI.com on Wed, Mar 14, 2001 at 06:50:26PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --nVMJ2NtxeReIH9PS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 14, 2001 at 06:50:26PM -0800, David O'Brien wrote: > On Wed, Mar 14, 2001 at 04:15:55PM -0800, Brooks Davis wrote: > > I'm frankly, completly mystified by the various comments about this not > > being a security feature. Of course it's not. That's blindly obvious. >=20 > I disagree it is blindly obvious. It wasn't to some I've talked to. > We've ended up associating a "security nature" to MD5. Thus when people > see that name, they make assumptions. I'll give you that a number of smart people didn't get it very quickly, but I'll also say, and I'm still mystified that they thought this. If you tried to use it as one you wouldn't get very far since there's nothing to do. > How?? are clients going to take advantage of it? For the majority of FTP > clients want to fetch the file, so why ask for an MD5 of it? Are you > thinking about checking the xfer was OK? That's the only use I can think > of. The other uses people have mentioned are very, very specific to a > single task done by the FreeBSD Project. Checking distfiles for unnumbered re-rolls, mirroring files who's names don't change but who's contents does. Checking the xfer could also be useful, expecialy for people with truly crappy links. You're average client isn't going to have much if any use for it at all. > Since making a loadable Apache module is so much less intrusive, I call > on those wanting to experiment with this feature to do this thru this > path. If you can get the Apache people to either bundle the module as a > standard thing, or convince large sites to load it; THEN hack ftpd. I don't see why you are objecting. If it's added AND it actually turns out to be useful then it would have to be added to lukem ftpd before we used it, but we haven't proven it one way or another and it's not like it's a hugly complicated feature requiring a major restructuring of code. In many respects FreeBSD's ftpd is the perfect place to test a new feature because if the feature turns out to be less then useful the impending ftpd replacement is a perfect excuse to kill the feature. As far as I can tell, as long as you can turn it off to avoid trashing your underpowered, high useage system it's entierly harmless. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --nVMJ2NtxeReIH9PS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6sPiJXY6L6fI4GtQRAhmDAJ4vvhIz7jMmXzCIfCui3zYStcK5ggCeJWaJ OqaZNZxKhTbtK3STxQB4lto= =okyo -----END PGP SIGNATURE----- --nVMJ2NtxeReIH9PS-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 9:17:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 149CC37B718 for ; Thu, 15 Mar 2001 09:17:20 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=dbf0c3624768afaf5defd85ac8ee3e89) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14dbNJ-0000P3-00; Thu, 15 Mar 2001 10:17:21 -0700 Message-ID: <3AB0F921.3E8FC55C@softweyr.com> Date: Thu, 15 Mar 2001 10:17:21 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Matt Dillon Cc: Garance A Drosihn , David O'Brien , Brooks Davis , freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd References: <20010314084651.A23104@ringworld.oblivion.bg> <200103142342.QAA09233@usr08.primenet.com> <20010314161555.A4984@Odin.AC.HMC.Edu> <20010314185026.C7683@dragon.nuxi.com> <200103150256.f2F2u1b37896@earth.backplane.com> <200103150606.f2F66Vj38988@earth.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon wrote: > > :If you're going to download it anyway, then there is zero point > :to doing the MD5. The way I'm reading this option, the ONLY > :reason to do an MD5 is to try and *-AVOID-* doing a download. > :That is all I want it for, at least. > > I'm just trying to think of the situations where a user would do > this on a regular basis, and I simply can't imagine that Fetching ports distfiles or packages. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 9:27:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 3BAB837B71D for ; Thu, 15 Mar 2001 09:27:16 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f2FHR7b01825; Thu, 15 Mar 2001 09:27:07 -0800 Date: Thu, 15 Mar 2001 09:27:07 -0800 From: Brooks Davis To: Terry Lambert Cc: Peter Pentchev , freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010315092707.C30551@Odin.AC.HMC.Edu> References: <20010314161555.A4984@Odin.AC.HMC.Edu> <200103150439.VAA01217@usr05.primenet.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="f0KYrhQ4vYSV2aJu" Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200103150439.VAA01217@usr05.primenet.com>; from tlambert@primenet.com on Thu, Mar 15, 2001 at 04:39:09AM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --f0KYrhQ4vYSV2aJu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 15, 2001 at 04:39:09AM +0000, Terry Lambert wrote: > > I'm frankly, completly mystified by the various comments about this not > > being a security feature. Of course it's not. That's blindly obvious. >=20 > I've always taken it as a security feature. I have to override > the enforcement for a number of ports, and the only ill effects > I have seen is that ...I have to override the enforcement for a > number of ports. We miscommunicated here. The MD5 checksums in the ports tree are for security, but this change doens't impact that except that it could stop you from downloading files that didn't match the one in the port or allow you to download files which had changed (resulting in a portrevision bump) but which you had in your /usr/ports/distfiles directory. I think the problem is that everyone associates MD5 with security, when we all know (when we think about it enough, anyway) that MD5 checksums just that and have not inate security function. > I really haven't thought about it from a "validation" persepective > before this thread, since bad code in one spot is going to be > mirrored everywhere, and so is a version number change with a > deletion of the old version. In my personal experience, the code > that fails the MD5 isn't grabbed from a different server in hopes > of getting a copy that doesn't fail the MD5, so I'm just as > screwed as if it weren't there. With this change, I'd actually expect that if a server gave an MD5 that wasn't the one we wanted and we had another choice we'd go get it from there. > The whole idea of HTTP protection like this is pretty inane, since > we've all already agreed, I think, that it's really only useful > for mirroring, or for offloading an MD5 calculation from my 800MHz > Pentium III laptop onto a big, ballsy 66MHz 486 FTP server. We definatly don't want people doing it randomly, but I think it's a sufficently useful idea within it's limited realm to at least give it a shot. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --f0KYrhQ4vYSV2aJu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6sPtqXY6L6fI4GtQRAqaLAKDHdTt9AdakORe5wpSU6aiD1voRtACfV9AL 47bJwa1ahn0Zb12bDVy6jmk= =ztB+ -----END PGP SIGNATURE----- --f0KYrhQ4vYSV2aJu-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 10:45:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 81F4D37B719 for ; Thu, 15 Mar 2001 10:45:15 -0800 (PST) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id LAA09885; Thu, 15 Mar 2001 11:45:11 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id LAA05477; Thu, 15 Mar 2001 11:45:10 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15025.3509.496206.784802@nomad.yogotech.com> Date: Thu, 15 Mar 2001 11:45:09 -0700 (MST) To: freebsd-arch@FreeBSD.ORG Cc: Brooks Davis Subject: Re: [PATCH] add a SITE MD5 command to ftpd In-Reply-To: <20010314185026.C7683@dragon.nuxi.com> References: <20010314084651.A23104@ringworld.oblivion.bg> <200103142342.QAA09233@usr08.primenet.com> <20010314161555.A4984@Odin.AC.HMC.Edu> <20010314185026.C7683@dragon.nuxi.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I'm frankly, completly mystified by the various comments about this not > > being a security feature. Of course it's not. That's blindly obvious. > > I disagree it is blindly obvious. It wasn't to some I've talked to. > We've ended up associating a "security nature" to MD5. Thus when people > see that name, they make assumptions. > > > That's not the point. As long as it's an option I frankly don't see how > > it could possibly hurt things and I can't see any good reason why a > > reasonably implementation wouldn't spread if people started using > > clients that could take advantage of it. > > How?? are clients going to take advantage of it? For the majority of FTP > clients want to fetch the file, so why ask for an MD5 of it? To see if the file that they are looking for exists on the server? As someone pointed out already, the server may have an 'older' file, so there's no sense in downloading it unless the MD5's match. > Are you > thinking about checking the xfer was OK? That's the only use I can think > of. The other uses people have mentioned are very, very specific to a > single task done by the FreeBSD Project. The xfer would have been OK if the MD5 matched what the port listed. But, it would save a download. (A good example of files that never change their name are the named files). Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 10:46:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 3DEA537B719 for ; Thu, 15 Mar 2001 10:46:42 -0800 (PST) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id LAA09908; Thu, 15 Mar 2001 11:46:34 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id LAA05489; Thu, 15 Mar 2001 11:46:33 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15025.3593.230536.962890@nomad.yogotech.com> Date: Thu, 15 Mar 2001 11:46:33 -0700 (MST) To: Matt Dillon Cc: "David O'Brien" , Brooks Davis , freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd In-Reply-To: <200103150256.f2F2u1b37896@earth.backplane.com> References: <20010314084651.A23104@ringworld.oblivion.bg> <200103142342.QAA09233@usr08.primenet.com> <20010314161555.A4984@Odin.AC.HMC.Edu> <20010314185026.C7683@dragon.nuxi.com> <200103150256.f2F2u1b37896@earth.backplane.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Doesn't SITE MD5 introduce a race condition? What if someone does > a SITE MD5 and someone else then renames or modifies the file before > the first person proceeds to download it? > > Also, why bother doing an MD5 on the remote site if 99.9% of the time > you are going to get a match and download the file anyway? You might > as well download it first. Or perhaps simply check the size of the file > for a match (e.g. enhance ports to include the file size to check against > in addition to the MD5), then download it, then do the MD5 on the > local box. > > I just don't see much point in adding a command to FTP that isn't going > to be generally useful and has security holes in it to boot. If the MD5 signature is 'advisory', it's not going to introduce any security holes. Ultimately, the post must verify the MD5 locally, no matter what the remote site claims. It's a matter of saving bandwidth. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 10:50:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 23FD637B718 for ; Thu, 15 Mar 2001 10:50:52 -0800 (PST) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id LAA10000; Thu, 15 Mar 2001 11:50:46 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id LAA05535; Thu, 15 Mar 2001 11:50:45 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15025.3845.13790.411778@nomad.yogotech.com> Date: Thu, 15 Mar 2001 11:50:45 -0700 (MST) To: Terry Lambert Cc: brooks@one-eyed-alien.net (Brooks Davis), roam@orbitel.bg (Peter Pentchev), freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd In-Reply-To: <200103150439.VAA01217@usr05.primenet.com> References: <20010314161555.A4984@Odin.AC.HMC.Edu> <200103150439.VAA01217@usr05.primenet.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > This is a reasionable objection to the implemention in question, but not > > to the concept as a whole. If you just cache the MD5 and the mtime at > > the time of the MD5 you only pay for files that have never been MD5ed > > or have changed since you last MD5ed them. You could easily cache them > > either in files the ftp server ignores like .md5. or in a > > shared cache file. Neither would be all that difficult to implement. > > The VFS option someone else mentioned could work the same way except > > being more efficent. > > I suggested both of these (see other posts). > > > > I'm frankly, completly mystified by the various comments about this not > > being a security feature. Of course it's not. That's blindly obvious. > > I've always taken it as a security feature. The client MD5 matching *is* a security features. SITE-MD5 on an ftp/http server is not, because the client is doing the security for us. At the remote site, it's an 'optimization' to avoid having to download a file that isn't going to match anyway. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 11: 4:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id ABCC737B71A for ; Thu, 15 Mar 2001 11:04:24 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p60-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.125]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id EAA26177 for ; Fri, 16 Mar 2001 04:04:23 +0900 (JST) Message-ID: <3AB11181.668C2687@newsguy.com> Date: Fri, 16 Mar 2001 04:01:21 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: freebsd-arch@FreeBSD.ORG Subject: Re: flags settings for modules References: <20010314111629.A1018@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David O'Brien wrote: > > I committed a change sys/conf/kmod.mk such that modules are now installed > with flags "schg" as the kernel has been forever. * DaiBashi kills motminh -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@the.secret.bsdconspiracy.net It's a rewarding life, but hey, somebody has to have all the fun, right? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 11:20:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id F13C937B71F; Thu, 15 Mar 2001 11:20:15 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id MAA11418; Thu, 15 Mar 2001 12:16:53 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpdAAA7laWmw; Thu Mar 15 12:16:43 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id MAA18623; Thu, 15 Mar 2001 12:19:57 -0700 (MST) From: Terry Lambert Message-Id: <200103151919.MAA18623@usr05.primenet.com> Subject: Re: [PATCH] add a SITE MD5 command to ftpd To: jabley@automagic.org (Joe Abley) Date: Thu, 15 Mar 2001 19:19:57 +0000 (GMT) Cc: adrian@FreeBSD.ORG (Adrian Chadd), freebsd-arch@FreeBSD.ORG, roam@orbitel.bg (Peter Pentchev) In-Reply-To: <20010315092047.E8289@buddha.home.automagic.org> from "Joe Abley" at Mar 15, 2001 09:20:47 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > *OR* you could distribute the problem the way it is naturally > distributed, and build a mechanism whereby a downloaded distfile > that fails its MD5 check on any recent build of FreeBSD causes > a notification to be sent back to the mother ship. I like this idea, but it is orthogonal. However, it would be a useful thing to do first. I suggest that this be done _now_, and that statistics be collected on failures; people can subsequently use those statistics to decide whether a SITE MD5 capability is really justified, or if people are just for it because they have a better memory for failure than for success. I'd suggest instrumenting other information for statistical collection only, such as installation counts for all ports. This would also let us finally answer the "KDE vs. Gnome for default desktop?" question, as well as letting us know if some "xxx" utility should be part of the base installation instead of a port. It's worthwhile, so long as the information is statistical only, and that rereporting for a single system reinstall is somehow supressed to keep people from "stacking the deck" in favor of having the Ada compiler installed by default (as an extreme example). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 11:52:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from molly.straylight.com (molly.straylight.com [209.68.199.242]) by hub.freebsd.org (Postfix) with ESMTP id 5AC0737B719 for ; Thu, 15 Mar 2001 11:52:55 -0800 (PST) (envelope-from jonathan@graehl.org) Received: from dickie (case.straylight.com [209.68.199.244]) by molly.straylight.com (8.11.0/8.10.0) with SMTP id f2FJqoE23582 for ; Thu, 15 Mar 2001 11:52:50 -0800 From: "Jonathan Graehl" To: "freebsd-Arch" Subject: ftpd SITE MD5 and "really bad links" Date: Thu, 15 Mar 2001 11:52:26 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <200103151919.MAA18623@usr05.primenet.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG If the probability of errors (which pass 32-bit-1s-complement muster) on the net route between the client and FTP server is as high as once in a gigabyte, then SITE MD5 could save lives, not just make life easier for ports people. I see the odds of totally random bit errors aligning themselves on the same bit (say, so 1 is changed to 0 and vice versa) as incredibly low. However, the Internet checksum is not particularly robust against systematic failure - say that the MSB in a faulty 32-bit-chunk-router flips once every million, then you have some significant probability of more than one flip in the same 8000-bit interval comprising your single tcp fragment, quite possibly giving the same checksum. If actual data corruption in a TCP stream is a non-vanishing possibility due to some faulty equipment you are behind, then you will appreciate SITE MD5 as a valuable data integrity check, and not have to hope that the admin has manually placed the MD5sums somewhere for you. It would also allow you to be certain that your file has been uploaded without errors (no daily cron job is going to offer that immediate response). MD5 is also held to have some cryptographic weaknesses (compared to, say, SHA-1 or Tiger); is the feeling that it is more than sufficient against any conceivable systematic/accidental source of error not specifically designed to exploit what weaknesses MD5 has? p.s. follow up to freebsd-net? -- Jonathan Graehl email: jonathan@graehl.org web: http://jonathan.graehl.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 12: 3:57 2001 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 006A237B719 for ; Thu, 15 Mar 2001 12:03:54 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id PAA48601; Thu, 15 Mar 2001 15:03:16 -0500 (EST) (envelope-from wollman) Date: Thu, 15 Mar 2001 15:03:16 -0500 (EST) From: Garrett Wollman Message-Id: <200103152003.PAA48601@khavrinen.lcs.mit.edu> To: jonathan@graehl.org Subject: Re: ftpd SITE MD5 and "really bad links" In-Reply-To: References: <200103151919.MAA18623@usr05.primenet.com> Organization: MIT Laboratory for Computer Science Cc: arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you write: >MD5 is also held to have some cryptographic weaknesses (compared to, >say, SHA-1 or Tiger); is the feeling that it is more than sufficient >against any conceivable systematic/accidental source of error not >specifically designed to exploit what weaknesses MD5 has? If such a command were being officially standardized, it would probably be called "DIGEST [offset [length]]" to allow for other types of message-digest algorithms, with a command to show the available digest types. (Apparently many European concerns will object to any message digest-using protocol that doesn't allow for RIPEMD160, regardless of whether it's actually security-sensitive.) I'd be happy to write this up as an RFC and take it through the process, if someone wants to implement it. (Obviously, the initial implementation should be "SITE DIGEST" and then we can change it if the unqualified version makes it through the Internet Standards Process.) -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 12:22:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from molly.straylight.com (molly.straylight.com [209.68.199.242]) by hub.freebsd.org (Postfix) with ESMTP id ED66237B718 for ; Thu, 15 Mar 2001 12:22:18 -0800 (PST) (envelope-from jonathan@graehl.org) Received: from dickie (case.straylight.com [209.68.199.244]) by molly.straylight.com (8.11.0/8.10.0) with SMTP id f2FKMEE23805 for ; Thu, 15 Mar 2001 12:22:14 -0800 From: "Jonathan Graehl" To: "freebsd-Arch" Subject: RE: ftpd SITE MD5 and "really bad links" Date: Thu, 15 Mar 2001 12:21:50 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <200103152003.PAA48601@khavrinen.lcs.mit.edu> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG A digest of the file would be significantly more useful if the FTP server had a site key, and transmitted the digest plus the digest encrypted with that private key. Then you would actually *know* you got the right file, as opposed to knowing you got the file that somebody, not necessarily the FTP server, wanted you to get ;) RIPEMD160 looks credible at first glance, although I'm surprised it isn't an RFC (2857 specifies using it with HMAC, though). -Jon > In article you write: > >MD5 is also held to have some cryptographic weaknesses (compared to, > >say, SHA-1 or Tiger); is the feeling that it is more than sufficient > >against any conceivable systematic/accidental source of error not > >specifically designed to exploit what weaknesses MD5 has? > > If such a command were being officially standardized, it would > probably be called "DIGEST [offset [length]]" > to allow for other types of message-digest algorithms, with a command > to show the available digest types. (Apparently many European > concerns will object to any message digest-using protocol that doesn't > allow for RIPEMD160, regardless of whether it's actually > security-sensitive.) > > I'd be happy to write this up as an RFC and take it through the > process, if someone wants to implement it. (Obviously, the initial > implementation should be "SITE DIGEST" and then we can change it if > the unqualified version makes it through the Internet Standards > Process.) > > -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 13: 2:25 2001 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 6B48B37B719 for ; Thu, 15 Mar 2001 13:02:23 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id QAA49281; Thu, 15 Mar 2001 16:02:03 -0500 (EST) (envelope-from wollman) Date: Thu, 15 Mar 2001 16:02:03 -0500 (EST) From: Garrett Wollman Message-Id: <200103152102.QAA49281@khavrinen.lcs.mit.edu> To: jonathan@graehl.org Subject: Re: ftpd SITE MD5 and "really bad links" X-Newsgroups: mit.lcs.mail.freebsd-arch In-Reply-To: References: <200103152003.PAA48601@khavrinen.lcs.mit.edu> Organization: MIT Laboratory for Computer Science Cc: arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you write: >A digest of the file would be significantly more useful if the FTP >server had a site key Repeat after me: this is not, and is not intended to be, a security mechanism. There is already a security mechanism defined for FTP. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 13:10:10 2001 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 2372D37B71D for ; Thu, 15 Mar 2001 13:10:04 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f2FL9o101648; Thu, 15 Mar 2001 22:09:50 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Garrett Wollman Cc: jonathan@graehl.org, arch@FreeBSD.ORG Subject: Re: ftpd SITE MD5 and "really bad links" In-Reply-To: Your message of "Thu, 15 Mar 2001 16:02:03 EST." <200103152102.QAA49281@khavrinen.lcs.mit.edu> Date: Thu, 15 Mar 2001 22:09:50 +0100 Message-ID: <1646.984690590@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200103152102.QAA49281@khavrinen.lcs.mit.edu>, Garrett Wollman write s: >In article you write: > >>A digest of the file would be significantly more useful if the FTP >>server had a site key > >Repeat after me: this is not, and is not intended to be, a security >mechanism. > >There is already a security mechanism defined for FTP. Me notes that at this point "SITE MD5" has safely entered the territory of bikeshed building, but tries one last time to cut out in cardboard what the proposal is: SITE MD5 filename [offset [length]] This is meant as a way to optimize away a transfer which would be pointless because the file has the wrong contents. The optional offset and length arguments can be used by intelligent mirroring software to save needless transfers for partially transfered files. It is *STILL* the clients responsibility to check the MD5 checksum of the received file to verify that it got what it wanted to catch servers which lie about the MD5 checksum, binary/ascii transfer setting mistakes or even random transmission errors, NAT gateway malfunctions or man-in-the-middle attacks. -- 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 Thu Mar 15 13:10:29 2001 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 4D36437B718; Thu, 15 Mar 2001 13:10:24 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id WAA62013; Thu, 15 Mar 2001 22:10:21 +0100 (CET) (envelope-from des@ofug.org) 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: Garrett Wollman Cc: chat@FreeBSD.ORG Subject: Re: ftpd SITE MD5 and "really bad links" References: <200103152003.PAA48601@khavrinen.lcs.mit.edu> <200103152102.QAA49281@khavrinen.lcs.mit.edu> From: Dag-Erling Smorgrav Date: 15 Mar 2001 22:10:21 +0100 In-Reply-To: Garrett Wollman's message of "Thu, 15 Mar 2001 16:02:03 -0500 (EST)" Message-ID: Lines: 8 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Garrett Wollman writes: > There is already a security mechanism defined for FTP. What's that, "don't use FTP"? :) 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 Mar 15 13:20:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from molly.straylight.com (molly.straylight.com [209.68.199.242]) by hub.freebsd.org (Postfix) with ESMTP id 2A3C437B719 for ; Thu, 15 Mar 2001 13:20:44 -0800 (PST) (envelope-from jonathan@graehl.org) Received: from dickie (case.straylight.com [209.68.199.244]) by molly.straylight.com (8.11.0/8.10.0) with SMTP id f2FLKcE24211 for ; Thu, 15 Mar 2001 13:20:38 -0800 From: "Jonathan Graehl" To: "freebsd-Arch" Subject: RE: ftpd SITE MD5 and "really bad links" Date: Thu, 15 Mar 2001 13:20:16 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <200103152102.QAA49281@khavrinen.lcs.mit.edu> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In article you write: > > >A digest of the file would be significantly more useful if the FTP > >server had a site key > > Repeat after me: this is not, and is not intended to be, a security > mechanism. I didn't say it was, or was intended to be - I said it *would* also be useful as a security mechanism *if* ... > There is already a security mechanism defined for FTP. Do you mean ftp://ftp.isi.edu/in-notes/rfc2228.txt ? If not, clarify. -Jon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 13:26: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 99C9E37B719 for ; Thu, 15 Mar 2001 13:26:04 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f2FLOj046985; Thu, 15 Mar 2001 13:24:45 -0800 (PST) (envelope-from dillon) Date: Thu, 15 Mar 2001 13:24:45 -0800 (PST) From: Matt Dillon Message-Id: <200103152124.f2FLOj046985@earth.backplane.com> To: Wes Peters Cc: Garance A Drosihn , "David O'Brien" , Brooks Davis , freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd References: <20010314084651.A23104@ringworld.oblivion.bg> <200103142342.QAA09233@usr08.primenet.com> <20010314161555.A4984@Odin.AC.HMC.Edu> <20010314185026.C7683@dragon.nuxi.com> <200103150256.f2F2u1b37896@earth.backplane.com> <200103150606.f2F66Vj38988@earth.backplane.com> <3AB0F921.3E8FC55C@softweyr.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :> I'm just trying to think of the situations where a user would do :> this on a regular basis, and I simply can't imagine that : :Fetching ports distfiles or packages. : :Wes Peters Softweyr LLC :wes@softweyr.com http://softweyr.com/ Ports and distfiles are for the most part version based, as part of the filename. This handles 99.99% of the download checking requirement. It isn't perfect, but an MD5 check isn't going to magically solve the problem either. Frankly I do not see how a remote MD5 check would even come close to reducing the bandwidth of an ftp server in any significant way considering all the (correct) downloads going on anyway. An MD5 is simply not going to save enough bandwidth for it to be worth adding. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 14:23:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id AFC6F37B718 for ; Thu, 15 Mar 2001 14:23:48 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id PAA17880; Thu, 15 Mar 2001 15:17:08 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpdAAAIdaWQI; Thu Mar 15 15:16:52 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id PAA23296; Thu, 15 Mar 2001 15:23:29 -0700 (MST) From: Terry Lambert Message-Id: <200103152223.PAA23296@usr05.primenet.com> Subject: Re: ftpd SITE MD5 and "really bad links" To: jonathan@graehl.org (Jonathan Graehl) Date: Thu, 15 Mar 2001 22:23:29 +0000 (GMT) Cc: freebsd-arch@FreeBSD.ORG (freebsd-Arch) In-Reply-To: from "Jonathan Graehl" at Mar 15, 2001 11:52:26 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > If the probability of errors (which pass 32-bit-1s-complement muster) > on the net route between the client and FTP server is as high as once > in a gigabyte, then SITE MD5 could save lives, not just make life > easier for ports people. This is a specious argument. Such errors would occur only in the event that the file was transferred. A SITE MD5 would come out correct, and the error would occur anyway during subsequent file transfer. Which make me think of a good use for /dev/random: put it out there as an mp3 file named for a Metallica song, and lie about it's size. 8-). The cryptographic value of the SITE MD5 is nonexistant, as we all already agree; at best, it's cryptographically misleading to users who will equate it with security. It seems to me that it _might_ have limited utility in the case of a post-download verification of the file contents, in the case where you don't have a precalculated MD5 on hand, and you don't trust your transport to not have one of those near-magical errors that you describe (above). This wouldn't be useful in the "ports" case, since it doesn't care _why_ the MD5 failed, only that it invalidates the file from consideration (since the ports mechanism _is_ a security mechanism, based on the trust of the /usr/ports hierarchy you are using for the install). So the new limited utility would be: 1) download the file 2) SITE HASH MD5 foo 3) compare the local hash to the site hash 4) tell the user the 9 Terabytes they just spent the better part of their life downloading are "no good": sorry, there is a 4 bit error in that copy of "Sweet Child of Mine" that you just got from the mp3.com site. If you want to implement it for post-download checking, go ahead. Realize that any FTP server where I'm forced to support it, however, will be operating off of cached data, and it will be a cold day in hell before I let you DOS-attack my FTP server with the frigging thing operating on demand. I think your time would be better spent fixing the protocols you distrust, so that it would be unnecessary. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 17:12:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from molly.straylight.com (molly.straylight.com [209.68.199.242]) by hub.freebsd.org (Postfix) with ESMTP id 674B437B71C for ; Thu, 15 Mar 2001 17:12:55 -0800 (PST) (envelope-from jonathan@graehl.org) Received: from dickie (case.straylight.com [209.68.199.244]) by molly.straylight.com (8.11.0/8.10.0) with SMTP id f2G1CnE25596 for ; Thu, 15 Mar 2001 17:12:49 -0800 From: "Jonathan Graehl" To: "freebsd-Arch" Subject: RE: ftpd SITE MD5 and "really bad links" Date: Thu, 15 Mar 2001 17:12:29 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200103152223.PAA23296@usr05.primenet.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry said: > > If the probability of errors (which pass 32-bit-1s-complement muster) > > on the net route between the client and FTP server is as high as once > > in a gigabyte, then SITE MD5 could save lives, not just make life > > easier for ports people. > > This is a specious argument. Such errors would occur only in the > event that the file was transferred. A SITE MD5 would come out > correct, and the error would occur anyway during subsequent file > transfer. After downloading the file (with checksum-passing errors), I compute the MD5 checksum of it. I see that it does not match the SITE MD5 value, so I log into the server again and do another "SITE MD5". If that value matches what I computed for the file, I assume there was an error in the first "SITE MD5" I got, but the file is error free. If that value differs from what I computed for the file, then I assume that I do not have the file the server wants me to have, and repeat the process. If you wanted, you could even do SITE MD5 again until it is clear you are getting the correct value. This pattern is standard; I do not understand why we need to argue it. Without SITE MD5, I would have to resort to hoping that someone had (ad-hoc) made a checksum available for me to (ad-hoc) verify. I am asking the question: what is the probability of data errors which are undetected by the TCP checksum? I have had faulty ISP equipment choke on certain byte sequences, but the TCP checksum always happened to catch whatever the error was (so the transfer would simply stall). I don't see your "4 bits in error in your lossy-compressed media file is not so bad" argument as an answer to my question, nor are all file transfers sending lossy-compressed media where you don't care about errors. -Jon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 17:31:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id C676737B747 for ; Thu, 15 Mar 2001 17:31:46 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2G1Vg852917; Thu, 15 Mar 2001 17:31:42 -0800 (PST) (envelope-from obrien) Date: Thu, 15 Mar 2001 17:31:41 -0800 From: "David O'Brien" To: Garrett Wollman Cc: arch@freebsd.org Subject: Re: ftpd SITE MD5 and "really bad links" Message-ID: <20010315173141.A52889@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <200103151919.MAA18623@usr05.primenet.com> <200103152003.PAA48601@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103152003.PAA48601@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Thu, Mar 15, 2001 at 03:03:16PM -0500 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 X-Loop: FreeBSD.ORG On Thu, Mar 15, 2001 at 03:03:16PM -0500, Garrett Wollman wrote: > I'd be happy to write this up as an RFC and take it through the > process, if someone wants to implement it. I would be very happy to see this. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 17:43:42 2001 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 30F8837B718 for ; Thu, 15 Mar 2001 17:43:37 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id UAA53608; Thu, 15 Mar 2001 20:43:34 -0500 (EST) (envelope-from wollman) Date: Thu, 15 Mar 2001 20:43:34 -0500 (EST) From: Garrett Wollman Message-Id: <200103160143.UAA53608@khavrinen.lcs.mit.edu> To: jonathan@graehl.org Subject: Re: ftpd SITE MD5 and "really bad links" X-Newsgroups: mit.lcs.mail.freebsd-arch In-Reply-To: References: <200103152223.PAA23296@usr05.primenet.com> Organization: MIT Laboratory for Computer Science Cc: arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you write: [BTW, what MTA generates such *evil* Message-IDs?] >After downloading the file (with checksum-passing errors), I compute the MD5 >checksum of it. I see that it does not match the SITE MD5 value, [...] >This pattern is standard; I do not understand why we need to argue >it. Anyone who does argue needs to go back and read ``End-to-End Arguments in System Design'', the seminal paper by Jerry Saltzer, Dave Clark, and David Reed which explains this in explicit detail. (This happens to be one of the fundamental design ideas underlying the Internet protocol suite; Dave Clark was the Chief Protocol Architect for the Internet during the period when the switch from ARPANET to Internet was being made, and this article is one of the most cited in the field.) See . -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 18: 8:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 74C4F37B718; Thu, 15 Mar 2001 18:08:37 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f2G28b926085; Thu, 15 Mar 2001 18:08:37 -0800 (PST) Date: Thu, 15 Mar 2001 18:08:37 -0800 From: Alfred Perlstein To: arch@freebsd.org Cc: jkh@freebsd.org Subject: NO MORE '-BETA' Message-ID: <20010315180837.N29888@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Can we not have -BETA anymore? Apparently our users freak out each time the changeover happens. I've seen several emails each time this happens. It really serves no useful purpose that I can see. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@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 Mar 15 18:25:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 3C63A37B718 for ; Thu, 15 Mar 2001 18:25:54 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2G2PVG31849 for ; Thu, 15 Mar 2001 18:25:31 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Thu, 15 Mar 2001 18:25:30 -0800 (PST) From: John Baldwin To: arch@FreeBSD.org Subject: Proposal for the CPU interrupt API Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - 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 Thu Mar 15 18:27:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 7F10C37B719; Thu, 15 Mar 2001 18:27:14 -0800 (PST) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f2G2Nxu23750; Thu, 15 Mar 2001 20:23:59 -0600 (CST) (envelope-from jlemon) Date: Thu, 15 Mar 2001 20:23:59 -0600 From: Jonathan Lemon To: John Baldwin Cc: arch@FreeBSD.ORG Subject: Re: Proposal for the CPU interrupt API Message-ID: <20010315202359.K82645@prism.flugsvamp.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Mar 15, 2001 at 06:25:30PM -0800, John Baldwin wrote: > and the code above would become this instead: > > intrmask_t foo = intr_disable(); > ... > intr_restore(foo); > > Comments, objections? Sounds good to me. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 18:28:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id E409337B719; Thu, 15 Mar 2001 18:28:43 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f2G2Sgh26607; Thu, 15 Mar 2001 18:28:42 -0800 (PST) Date: Thu, 15 Mar 2001 18:28:42 -0800 From: Alfred Perlstein To: Jonathan Lemon Cc: John Baldwin , arch@FreeBSD.ORG Subject: Re: Proposal for the CPU interrupt API Message-ID: <20010315182842.P29888@fw.wintelcom.net> References: <20010315202359.K82645@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010315202359.K82645@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Thu, Mar 15, 2001 at 08:23:59PM -0600 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Jonathan Lemon [010315 18:27] wrote: > On Thu, Mar 15, 2001 at 06:25:30PM -0800, John Baldwin wrote: > > and the code above would become this instead: > > > > intrmask_t foo = intr_disable(); > > ... > > intr_restore(foo); > > > > Comments, objections? > > Sounds good to me. wait, bring back splhigh(). :) Seriously, using the mask is a good idea. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@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 Mar 15 18:29:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 5760F37B718; Thu, 15 Mar 2001 18:29:42 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id SAA20509; Thu, 15 Mar 2001 18:29:45 -0800 Date: Thu, 15 Mar 2001 18:29:41 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Baldwin Cc: arch@FreeBSD.ORG Subject: Re: Proposal for the CPU interrupt API In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sounds good to me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 18:32:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 822DC37B71A; Thu, 15 Mar 2001 18:32:48 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f2G2WgZ54833; Thu, 15 Mar 2001 18:32:42 -0800 (PST) (envelope-from dillon) Date: Thu, 15 Mar 2001 18:32:42 -0800 (PST) From: Matt Dillon Message-Id: <200103160232.f2G2WgZ54833@earth.backplane.com> To: Matthew Jacob Cc: John Baldwin , arch@FreeBSD.ORG Subject: Re: Proposal for the CPU interrupt API References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is this API going to disable interrupts physically or simply flag that interrupts are disabled in the per-cpu state, aka the way the old splhigh() mechanism used to? -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 18:36:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 346AB37B71A; Thu, 15 Mar 2001 18:36:51 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id SAA20530; Thu, 15 Mar 2001 18:36:49 -0800 Date: Thu, 15 Mar 2001 18:36:45 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Matt Dillon Cc: John Baldwin , arch@FreeBSD.ORG Subject: Re: Proposal for the CPU interrupt API In-Reply-To: <200103160232.f2G2WgZ54833@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I would hope it would actually disable interrupts. On Thu, 15 Mar 2001, Matt Dillon wrote: > Is this API going to disable interrupts physically or simply flag > that interrupts are disabled in the per-cpu state, aka the way the > old splhigh() mechanism used to? > > -Matt > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 18:42:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 6F39C37B71A; Thu, 15 Mar 2001 18:42:24 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f2G2gNS54923; Thu, 15 Mar 2001 18:42:23 -0800 (PST) (envelope-from dillon) Date: Thu, 15 Mar 2001 18:42:23 -0800 (PST) From: Matt Dillon Message-Id: <200103160242.f2G2gNS54923@earth.backplane.com> To: Matthew Jacob Cc: John Baldwin , arch@FreeBSD.ORG Subject: Re: Proposal for the CPU interrupt API References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I would hope it would actually disable interrupts. On all cpu's or just the current cpu? -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 18:46:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 2309337B718; Thu, 15 Mar 2001 18:46:40 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id SAA20606; Thu, 15 Mar 2001 18:46:41 -0800 Date: Thu, 15 Mar 2001 18:46:38 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Matt Dillon Cc: John Baldwin , arch@FreeBSD.ORG Subject: Re: Proposal for the CPU interrupt API In-Reply-To: <200103160242.f2G2gNS54923@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > :I would hope it would actually disable interrupts. > > On all cpu's or just the current cpu? Undefined. This depends on the architecture. Some architectures don't have a global interrupt lockout mechanism. Some architectures vary as to whether or not interrupts can be directed to one CPU, broadcast to all, or only for a specific CPU. I think it's safe to say that given your specific platform's interrupt mechanism, this disable_intr disables for this CPU only, or for all. This function should probably only be called from MD code. It's not very MI. The MI code has spin && adaptive locks and should be using just those. I can't imagine any case with the exception of debuggers and console I/O that might get terribly upset about this- in which case these subsystems have extensions into MD layers anyway. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 19: 1:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 044FE37B71A; Thu, 15 Mar 2001 19:01:52 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f2G31o955114; Thu, 15 Mar 2001 19:01:50 -0800 (PST) (envelope-from dillon) Date: Thu, 15 Mar 2001 19:01:50 -0800 (PST) From: Matt Dillon Message-Id: <200103160301.f2G31o955114@earth.backplane.com> To: Matthew Jacob Cc: John Baldwin , arch@FreeBSD.ORG Subject: Re: Proposal for the CPU interrupt API References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Undefined. This depends on the architecture. Some architectures don't have a :global interrupt lockout mechanism. Some architectures vary as to whether or :not interrupts can be directed to one CPU, broadcast to all, or only for a :specific CPU. : :I think it's safe to say that given your specific platform's interrupt :mechanism, this disable_intr disables for this CPU only, or for all. : :This function should probably only be called from MD code. It's not very MI. :The MI code has spin && adaptive locks and should be using just those. I can't :imagine any case with the exception of debuggers and console I/O that might :get terribly upset about this- in which case these subsystems have extensions :into MD layers anyway. : :-matt The functions wouldn't be all that useful if left undefined in this manner. Consider why one might have to call such a function in the first place... * Your code could deadlock with an interrupt if it were to occur on the same cpu, but it is ok for it to spin temporarily on another cpu (aka a spin mutex). * Your code could deadlock with an interrupt if it were to occur on any cpu (not a spin mutex, but something more severe) * Your code is time-sensitive and cannot suffer a long interruption (interrupt on current cpu. aka the IDE byte stuffing bug of several years ago). * Your code is time-sensitive and code sensitive because you wrote it badly and it cannot suffer any interruption (interrupt on any cpu) (lets not mention DMA here). Unless you define precisely what this API is supposed to do, even if it is intended to be a machine-dependant API, the procedures will be almost completely useless. At worst they will be used with assumptions that are incorrect, or may break in a port to another cpu (remember, a lot of the PCI driver code is machine-independant!), or other bad things might happen. Interrupt disablement code is not something which can be defined willy-nilly! You need to be precise. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 19: 3:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 78A9737B718; Thu, 15 Mar 2001 19:03:21 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id TAA20688; Thu, 15 Mar 2001 19:03:23 -0800 Date: Thu, 15 Mar 2001 19:03:19 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Matt Dillon Cc: John Baldwin , arch@FreeBSD.ORG Subject: Re: Proposal for the CPU interrupt API In-Reply-To: <200103160301.f2G31o955114@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thank you for your opinion. The functions currently exist, are useful, and will continue to be useful, and John's optimization makes sense. Next? On Thu, 15 Mar 2001, Matt Dillon wrote: > > :Undefined. This depends on the architecture. Some architectures don't have a > :global interrupt lockout mechanism. Some architectures vary as to whether or > :not interrupts can be directed to one CPU, broadcast to all, or only for a > :specific CPU. > : > :I think it's safe to say that given your specific platform's interrupt > :mechanism, this disable_intr disables for this CPU only, or for all. > : > :This function should probably only be called from MD code. It's not very MI. > :The MI code has spin && adaptive locks and should be using just those. I can't > :imagine any case with the exception of debuggers and console I/O that might > :get terribly upset about this- in which case these subsystems have extensions > :into MD layers anyway. > : > :-matt > > The functions wouldn't be all that useful if left undefined in this > manner. Consider why one might have to call such a function in the > first place... > > * Your code could deadlock with an interrupt if it were to occur > on the same cpu, but it is ok for it to spin temporarily on another > cpu (aka a spin mutex). > > * Your code could deadlock with an interrupt if it were to occur on > any cpu (not a spin mutex, but something more severe) > > * Your code is time-sensitive and cannot suffer a long interruption > (interrupt on current cpu. aka the IDE byte stuffing bug of > several years ago). > > * Your code is time-sensitive and code sensitive because you wrote > it badly and it cannot suffer any interruption (interrupt on any > cpu) (lets not mention DMA here). > > Unless you define precisely what this API is supposed to do, even if > it is intended to be a machine-dependant API, the procedures will be > almost completely useless. At worst they will be used with assumptions > that are incorrect, or may break in a port to another cpu (remember, > a lot of the PCI driver code is machine-independant!), or other bad > things might happen. Interrupt disablement code is not something which > can be defined willy-nilly! You need to be precise. > > -Matt > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 19: 5:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 877B537B719 for ; Thu, 15 Mar 2001 19:05:49 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2G35KG33601; Thu, 15 Mar 2001 19:05:20 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 15 Mar 2001 19:05:19 -0800 (PST) From: John Baldwin To: Matthew Jacob Subject: Re: Proposal for the CPU interrupt API Cc: arch@FreeBSD.org, Matt Dillon Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 16-Mar-01 Matthew Jacob wrote: > > >> >> :I would hope it would actually disable interrupts. >> >> On all cpu's or just the current cpu? > > Undefined. This depends on the architecture. Some architectures don't have a > global interrupt lockout mechanism. Some architectures vary as to whether or > not interrupts can be directed to one CPU, broadcast to all, or only for a > specific CPU. > > I think it's safe to say that given your specific platform's interrupt > mechanism, this disable_intr disables for this CPU only, or for all. Yep. I think that on the Alpha the IPL may be shared among all CPU's or may be per-CPU but I'm not sure. On the x86 it would only be for the local CPU, but all that any calling code should depend on is that it disables interrupts for the current CPU. > This function should probably only be called from MD code. It's not very MI. > The MI code has spin && adaptive locks and should be using just those. I > can't > imagine any case with the exception of debuggers and console I/O that might > get terribly upset about this- in which case these subsystems have extensions > into MD layers anyway. Yep. The primary offenders right now are the internals of the mutex code for spin locks (which disable interrupts to prevent preemption while holding a spinlock), some MD code for dealing with floating point state and various drivers living under sys/i386/isa/. Note that on the alpha, we used the CPU mask to implement spl()'s, so intr_disable() is (and has been) functionally equivalent to splhigh(), while on x86 they were two different things. > -matt -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - 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 Thu Mar 15 19: 6:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id D06CD37B71A for ; Thu, 15 Mar 2001 19:06:39 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2G36CG33657; Thu, 15 Mar 2001 19:06:12 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 15 Mar 2001 19:06:11 -0800 (PST) From: John Baldwin To: Matthew Jacob Subject: Re: Proposal for the CPU interrupt API Cc: arch@FreeBSD.org, Matt Dillon Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 16-Mar-01 Matthew Jacob wrote: > > >> >> :I would hope it would actually disable interrupts. >> >> On all cpu's or just the current cpu? > > Undefined. This depends on the architecture. Some architectures don't have a > global interrupt lockout mechanism. Some architectures vary as to whether or > not interrupts can be directed to one CPU, broadcast to all, or only for a > specific CPU. > > I think it's safe to say that given your specific platform's interrupt > mechanism, this disable_intr disables for this CPU only, or for all. Yep. I think that on the Alpha the IPL may be shared among all CPU's or may be per-CPU but I'm not sure. On the x86 it would only be for the local CPU, but all that any calling code should depend on is that it disables interrupts for the current CPU. > This function should probably only be called from MD code. It's not very MI. > The MI code has spin && adaptive locks and should be using just those. I > can't > imagine any case with the exception of debuggers and console I/O that might > get terribly upset about this- in which case these subsystems have extensions > into MD layers anyway. Yep. The primary offenders right now are the internals of the mutex code for spin locks (which disable interrupts to prevent preemption while holding a spinlock), some MD code for dealing with floating point state and various drivers living under sys/i386/isa/. Note that on the alpha, we used the CPU mask to implement spl()'s, so intr_disable() is (and has been) functionally equivalent to splhigh(), while on x86 they were two different things. > -matt -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - 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 Thu Mar 15 19:38:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 227C437B718; Thu, 15 Mar 2001 19:38:20 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f2G3cJs55363; Thu, 15 Mar 2001 19:38:19 -0800 (PST) (envelope-from dillon) Date: Thu, 15 Mar 2001 19:38:19 -0800 (PST) From: Matt Dillon Message-Id: <200103160338.f2G3cJs55363@earth.backplane.com> To: John Baldwin Cc: Matthew Jacob , arch@FreeBSD.org Subject: Re: Proposal for the CPU interrupt API References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Yep. I think that on the Alpha the IPL may be shared among all CPU's or may be :per-CPU but I'm not sure. On the x86 it would only be for the local CPU, but :all that any calling code should depend on is that it disables interrupts for :the current CPU. Well, if the IPL is shared amoung all CPU's then for disable_intr() or work as advertised it would have to keep a reference count, since you might have several cpu's disabling interrupts at the same time. That would imply that every call to disable_intr() or enable_intr() must be matched by a call to restore_intr(). The documentation of the API is very important. It's perfectly acceptable to document the api as "Always disables hard interrupts on the current cpu and may or may not also disable hard interrupts on other cpus. All calls to disable/enable must be matched with a restore". It is not acceptable to document the API to be completely different for one cpu or another. e.g. it is not acceptable to document the API as "Always disables hard interrupts on the current cpu for i386 and always disables hard interrupts for all cpu's for Alpha. You don't have to match up calls on i386 but you do have to match them up on Alpha". The procedure's implementation on specific cpu's could in fact allow that, but if programmers were to actually program to that in potentially shared code (and many device drivers are shared across cpu's), the result is going to be a huge mess. And as far as your inane comments go, Matt... if you stopped to actually read my posting you might have understood my issue a little better. I don't know where you got your attitude problem or why you are being so combative, and I'm not interested either. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 19:41:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id ED40B37B71C; Thu, 15 Mar 2001 19:41:39 -0800 (PST) (envelope-from jkh@osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.2/8.11.1) with ESMTP id f2G3eTH85495; Thu, 15 Mar 2001 19:40:29 -0800 (PST) (envelope-from jkh@osd.bsdi.com) To: bright@wintelcom.net Cc: arch@freebsd.org, jkh@freebsd.org Subject: Re: NO MORE '-BETA' In-Reply-To: <20010315180837.N29888@fw.wintelcom.net> References: <20010315180837.N29888@fw.wintelcom.net> X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010315194029C.jkh@osd.bsdi.com> Date: Thu, 15 Mar 2001 19:40:29 -0800 From: Jordan Hubbard X-Dispatcher: imput version 20000228(IM140) Lines: 8 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hmm. I've yet to get *any* mail about BETA scaring people, and we've been doing them for literally years at this point. I suspect you're overreacting somewhat to Saverio Perugini's recent mail in -stable, but I'll nonetheless entertain any suggestions on what I could call the "pre-RC" releases without confusing them with snapshots, which occur every day anyway, or the actual release. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 20:12:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by hub.freebsd.org (Postfix) with ESMTP id F336F37B718; Thu, 15 Mar 2001 20:12:13 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.11.3/8.11.3) id f2G4F0P02542; Thu, 15 Mar 2001 20:15:00 -0800 (PST) (envelope-from sgk) Date: Thu, 15 Mar 2001 20:15:00 -0800 From: Steve Kargl To: Jordan Hubbard Cc: bright@wintelcom.net, arch@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: NO MORE '-BETA' Message-ID: <20010315201500.A2484@troutmask.apl.washington.edu> References: <20010315180837.N29888@fw.wintelcom.net> <20010315194029C.jkh@osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010315194029C.jkh@osd.bsdi.com>; from jkh@osd.bsdi.com on Thu, Mar 15, 2001 at 07:40:29PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Mar 15, 2001 at 07:40:29PM -0800, Jordan Hubbard wrote: > Hmm. I've yet to get *any* mail about BETA scaring people, and we've > been doing them for literally years at this point. I suspect you're > overreacting somewhat to Saverio Perugini's recent mail in -stable, > but I'll nonetheless entertain any suggestions on what I could call > the "pre-RC" releases without confusing them with snapshots, which > occur every day anyway, or the actual release. > Drop by the newsgroup. There was a thread last week about someone using cvsup expecting to get 4.2-stable and he got 4.3-beta. He was annoyed and confused because he thought beta meant "beta quality" (as in inferior software). 4.2-stable --> 4.2-rc1 --> 4.2-rc2 --> ... --> 4.3 -- Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 21:25:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 2FD3537B718; Thu, 15 Mar 2001 21:25:13 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id VAA21014; Thu, 15 Mar 2001 21:25:14 -0800 Date: Thu, 15 Mar 2001 21:25:10 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Matt Dillon Cc: John Baldwin , arch@FreeBSD.org Subject: Re: Proposal for the CPU interrupt API In-Reply-To: <200103160338.f2G3cJs55363@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > And as far as your inane comments go, Matt... if you stopped to actually > read my posting you might have understood my issue a little better. I > don't know where you got your attitude problem or why you are being so > combative, and I'm not interested either. I did read the posting. I happen to also believe that leaving it ambiguous has some advantages. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 21:49:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 4BA5637B718; Thu, 15 Mar 2001 21:49:38 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f2G5naV56294; Thu, 15 Mar 2001 21:49:36 -0800 (PST) (envelope-from dillon) Date: Thu, 15 Mar 2001 21:49:36 -0800 (PST) From: Matt Dillon Message-Id: <200103160549.f2G5naV56294@earth.backplane.com> To: Matthew Jacob Cc: John Baldwin , arch@FreeBSD.org Subject: Re: Proposal for the CPU interrupt API References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Your comments were not on point for what John is trying to accomplish. They :clearly are a vehicle that you are using to leap in and say how loosely and :poorly the SMP effort is being run (it is). : :If you actually were really contributing to the effort, I'd probably agree :with you, but I see nothing from you on this topic that is very helpful right :now. Well, this is out of the blue. Not only was I not trying to turn John's suggestion into a vehicle for any such thing, but I in fact have absolutely no problem with his idea... I happen to like it. My only interest is to ensure that the functions are documented well enough that we don't hit the same snag that we hit with the spl*() calls not being nested -- by making the API crystal clear. That's all. And as far as contributing goes... SMP isn't the only thing going on in the FreeBSD tree, dude. I've been working my ass off and in what little spare time I've had I've been tracking down and fixing filesystem, NFS, and VM problems, often with the help of many people including Paul, Alfred, Kirk, Tor, Ian, Alan, and many others. All you have to do is look in the cvs logs for 'dillon' (either committed by or reviewed by) and that should be pretty damn obvious. While it is true that I feel the SMPng stuff could have been done with fewer breakages, I think I've only stated that view once or twice on the lists in the last year. At the very beginning, at the meeting at Yahoo, I had very little time todo work and I said that quite clearly. I did what I could to get the ball rolling in the time I had by cleaning and documenting as much low level code as I had time for and implementing the idle process context. I'm sorry I didn't have time to do more, but as I said I am extremely busy right now trying to make my startup a success. I have bigger things to worry about then a few bruised egos. :Calling my comments 'inane' is rich. You're the complete moron who claims to :'support' NFS but can't be bothered to have non-*BSD clients. Go away and :bother somebody who cares. Huh? I have absolutely no clue as to what you are talking about here. I have spent hundreds of hours with people fixing NFS bugs, many related to other platforms. All you have to do is look at the commit logs to see that. Just a month or two ago I fixed a bug related to the use of O_EXCL|O_CREAT opens in mixed BSD/Solaris environments, for example. If you were interesting in moving the conversation onward there are about a thousand nice ways you could have said it. Since you chose not to use one of those thousand ways, my description of your comment is accurate. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 21:53:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-202.dsl.lsan03.pacbell.net [63.207.60.202]) by hub.freebsd.org (Postfix) with ESMTP id E17EB37B71C; Thu, 15 Mar 2001 21:53:50 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 4696766B09; Thu, 15 Mar 2001 21:53:50 -0800 (PST) Date: Thu, 15 Mar 2001 21:53:50 -0800 From: Kris Kennaway To: Jordan Hubbard Cc: bright@wintelcom.net, arch@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: NO MORE '-BETA' Message-ID: <20010315215349.A70879@mollari.cthul.hu> References: <20010315180837.N29888@fw.wintelcom.net> <20010315194029C.jkh@osd.bsdi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010315194029C.jkh@osd.bsdi.com>; from jkh@osd.bsdi.com on Thu, Mar 15, 2001 at 07:40:29PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Mar 15, 2001 at 07:40:29PM -0800, Jordan Hubbard wrote: > Hmm. I've yet to get *any* mail about BETA scaring people, and we've > been doing them for literally years at this point. I suspect you're > overreacting somewhat to Saverio Perugini's recent mail in -stable, > but I'll nonetheless entertain any suggestions on what I could call > the "pre-RC" releases without confusing them with snapshots, which > occur every day anyway, or the actual release. There have been several people on -questions and -stable confused and worried about why they got a beta release instead of a stable snapshot like they "asked for". I think we could stand to find a better name, perhaps 4.3-PRERELEASE. Kris --+HP7ph2BbKc20aGI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6saptWry0BWjoQKURAsJIAJ4/nI6xI9dc5gckXecY9UdafW5MAwCfY1MP 7qJvVJj1S/YB0Q6vUhT8Ruk= =ZZUR -----END PGP SIGNATURE----- --+HP7ph2BbKc20aGI-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 21:59:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 62CE637B718 for ; Thu, 15 Mar 2001 21:59:35 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id VAA21140 for ; Thu, 15 Mar 2001 21:59:38 -0800 Date: Thu, 15 Mar 2001 21:59:34 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: arch@FreeBSD.ORG Subject: Re: Proposal for the CPU interrupt API In-Reply-To: <200103160549.f2G5naV56294@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'd like to make it clear to the list and apologize for Matt Dillon's behaviour in making a private communication which was not directly on the topic public here. By emailing him directly I took such issues out of the list and had no intention to waste the bandwidth with such discussions. I'm sorry he did not follow suit. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 22: 7:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 4A88637B719 for ; Thu, 15 Mar 2001 22:07:22 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id XAA22259; Thu, 15 Mar 2001 23:01:17 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpdAAA4SaOxR; Thu Mar 15 23:01:07 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id XAA04414; Thu, 15 Mar 2001 23:07:01 -0700 (MST) From: Terry Lambert Message-Id: <200103160607.XAA04414@usr05.primenet.com> Subject: Re: ftpd SITE MD5 and "really bad links" To: jonathan@graehl.org (Jonathan Graehl) Date: Fri, 16 Mar 2001 06:06:56 +0000 (GMT) Cc: freebsd-arch@FreeBSD.ORG (freebsd-Arch) In-Reply-To: from "Jonathan Graehl" at Mar 15, 2001 05:12:29 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I don't see your "4 bits in error in your lossy-compressed media > file is not so bad" argument as an answer to my question, nor are > all file transfers sending lossy-compressed media where you don't > care about errors. Well, then, if we're concerned over bit errors not capable of being caught by TCP/IP, rather than fixing TCP/IP, we better add MD5 to SMTP, UUCP, POP3, IMAP4, FSP, GOPHER, ARCHIE, FTAM, NFS, CODA, HTTP, AFS, and every other internet protocol, so that TCP/IP can be lossy for the rest of time and never have to change. After all, it's better to "fix" every program that uses a lossy transport than it is to fix a lossy transport, isn't it? Sheesh... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 15 22:42:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from molly.straylight.com (molly.straylight.com [209.68.199.242]) by hub.freebsd.org (Postfix) with ESMTP id E613C37B719 for ; Thu, 15 Mar 2001 22:42:11 -0800 (PST) (envelope-from jonathan@graehl.org) Received: from dickie (case.straylight.com [209.68.199.244]) by molly.straylight.com (8.11.0/8.10.0) with SMTP id f2G6g3E27712 for ; Thu, 15 Mar 2001 22:42:03 -0800 From: "Jonathan Graehl" To: "freebsd-Arch" Subject: end to end file transfer Date: Thu, 15 Mar 2001 22:41:47 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200103160607.XAA04414@usr05.primenet.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I don't see your "4 bits in error in your lossy-compressed media > > file is not so bad" argument as an answer to my question, nor are > > all file transfers sending lossy-compressed media where you don't > > care about errors. > > Well, then, if we're concerned over bit errors not capable of being > caught by TCP/IP, rather than fixing TCP/IP, we better add MD5 to > SMTP, UUCP, POP3, IMAP4, FSP, GOPHER, ARCHIE, FTAM, NFS, CODA, HTTP, > AFS, and every other internet protocol, so that TCP/IP can be > lossy for the rest of time and never have to change. > > After all, it's better to "fix" every program that uses a lossy > transport than it is to fix a lossy transport, isn't it? > > Sheesh... The argument for modularity and code reuse is specious. Code can be reused in other ways than stuffing it into the transport layer (shared libraries?). Read the excellent paper Gordon referenced: http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf (don't worry, it's an pleasant trip), you'll understand why people might be interested in true application-level guarantees of succesful transfer. No matter how you fortify the network (using IPSEC AH with a 160 bit hash?), you still face these possible failures: 1) the server sends the wrong bits (disk corruption, cosmic ray twiddles a bit in memory before it is sent out) 2) the client writes the file to disk with errors along the way (same possibilities as the server) Perhaps I am interested in knowing if I managed to succesfully store on my disk the same bits that were originally written to the remote disk by the file's creator. If it were possible to have the filesystem maintain the whole-file checksum of the data when it was originally written, then we could truly guarantee this. No matter how error-unlikely the transport, it is still possible that what I write to disk was corrupted after transport. Reading back the contents of the file and doing a whole-file checksum, and comparing it to the server's is the only way to be sure I have the same file. Common to this thread has been the complaint that "it only happens .1% of the time". If the consequences of "it" happening are really bad, then there should be a mechanism for at least detecting "it", if "it" cannot be prevented. For instance, you say: "if it only happens a few time that a distfile is changed but has the same size and filename, then it is not worth having the server implement SITE MD5". What you are missing is, it may be bad to miss an update to a file. Therefore, if I wish to check every day for new versions, I have to download the same file every day *FOR ALL FILES I AM CHECKING*, not just those which have been changed and happen to have the same size (if I knew which had been changed, I wouldn't need to ask, now would I?) I really do not understand the resistance. Perhaps it would be more constructive if we ask: What is the best protocol for reliable (signed) serving of public files with minimum complexity and server-overhead? What is the best protocol for confidential, reliable transfer of private files? Vanilla FTP is the answer to neither of these. Feel free to invent a new protocol or extend existing ones ;) For the first, http with a signed hash of the content sounds acceptable to me, although I'd rather have a less clunky header format (content-negotiation based on MIME type is a good thing, I suppose, but a more minimalist binary-file-transfer protocol using a signle TCP connection would be nice). For the second, I currently use scp (or rsync over ssh). -- Jonathan Graehl email: jonathan@graehl.org web: http://jonathan.graehl.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 1:29:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by hub.freebsd.org (Postfix) with ESMTP id D7CCE37B718; Fri, 16 Mar 2001 01:29:07 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1) id 14dqXi-000118-0Y; Fri, 16 Mar 2001 09:29:06 +0000 Received: from salmon.nlsystems.com (salmon [10.0.0.3]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f2G9Rp475057; Fri, 16 Mar 2001 09:27:51 GMT (envelope-from dfr@nlsystems.com) Date: Fri, 16 Mar 2001 09:27:51 +0000 (GMT) From: Doug Rabson To: Matt Dillon Cc: Matthew Jacob , John Baldwin , Subject: Re: Proposal for the CPU interrupt API In-Reply-To: <200103160242.f2G2gNS54923@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Mar 2001, Matt Dillon wrote: > > :I would hope it would actually disable interrupts. > > On all cpu's or just the current cpu? Just the current one, I think. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 1:29:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net [194.217.242.41]) by hub.freebsd.org (Postfix) with ESMTP id 9DBEC37B719; Fri, 16 Mar 2001 01:29:54 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1) id 14dqYQ-0007df-0C; Fri, 16 Mar 2001 09:29:50 +0000 Received: from salmon.nlsystems.com (salmon [10.0.0.3]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f2G9SZ475061; Fri, 16 Mar 2001 09:28:35 GMT (envelope-from dfr@nlsystems.com) Date: Fri, 16 Mar 2001 09:28:35 +0000 (GMT) From: Doug Rabson To: John Baldwin Cc: Subject: Re: Proposal for the CPU interrupt API In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Mar 2001, John Baldwin wrote: > The end result of these changes would be this: > > intrmask_t intr_disable(void); > intrmask_t intr_enable(void); > void intr_restore(intrmask_t); > > and the code above would become this instead: > > intrmask_t foo = intr_disable(); > ... > intr_restore(foo); > > Comments, objections? Good idea. I nearly did this myself a while ago. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 1:31: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by hub.freebsd.org (Postfix) with ESMTP id 187C137B718; Fri, 16 Mar 2001 01:31:04 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-31.mail.demon.net with esmtp (Exim 2.12 #1) id 14dqZb-000EvY-0V; Fri, 16 Mar 2001 09:31:03 +0000 Received: from salmon.nlsystems.com (salmon [10.0.0.3]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f2G9Tl475070; Fri, 16 Mar 2001 09:29:47 GMT (envelope-from dfr@nlsystems.com) Date: Fri, 16 Mar 2001 09:29:47 +0000 (GMT) From: Doug Rabson To: John Baldwin Cc: Matthew Jacob , , Matt Dillon Subject: Re: Proposal for the CPU interrupt API In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Mar 2001, John Baldwin wrote: > > On 16-Mar-01 Matthew Jacob wrote: > > > > > >> > >> :I would hope it would actually disable interrupts. > >> > >> On all cpu's or just the current cpu? > > > > Undefined. This depends on the architecture. Some architectures don't have a > > global interrupt lockout mechanism. Some architectures vary as to whether or > > not interrupts can be directed to one CPU, broadcast to all, or only for a > > specific CPU. > > > > I think it's safe to say that given your specific platform's interrupt > > mechanism, this disable_intr disables for this CPU only, or for all. > > Yep. I think that on the Alpha the IPL may be shared among all CPU's or may be > per-CPU but I'm not sure. On the x86 it would only be for the local CPU, but > all that any calling code should depend on is that it disables interrupts for > the current CPU. On the alpha, IPL is a cpu-local attribute as far as I know. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 1:41:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 4EF1037B718; Fri, 16 Mar 2001 01:41:39 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id BAA21665; Fri, 16 Mar 2001 01:41:29 -0800 Date: Fri, 16 Mar 2001 01:41:25 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Doug Rabson Cc: John Baldwin , arch@FreeBSD.org Subject: Re: Proposal for the CPU interrupt API In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On the alpha, IPL is a cpu-local attribute as far as I know. The Alpha architecture books are fairly clear that IPL is part of the processor status word which is per-cpu. But the semantics of interrupt disabling *may* be construed to be just disabling all interrupts for all CPUs. I was serious when I said there might be an advantage to leaving this vague at this time rather than trying to nail it down. (in the PPC architecture I believe that page faults are interrupts) -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 2:24:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 1C0E437B718; Fri, 16 Mar 2001 02:24:54 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id VAA09872; Fri, 16 Mar 2001 21:24:51 +1100 Date: Fri, 16 Mar 2001 21:24:34 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: John Baldwin Cc: arch@FreeBSD.ORG Subject: Re: Proposal for the CPU interrupt API In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Mar 2001, John Baldwin wrote: > ... > Typically, interrupts are disabled in the following fashion: > > u_int foo = save_intr(); > disable_intr(); > ... > restore_intr(foo); > > Unfortunately, this can be somewhat expensive on the Alpha, as both > save_intr() and disable_intr() involve a PAL call. However, the Alpha > returns the previous state whenever you set the interrupt state, which > allows you to only make 1 PAL call. Thus, I'm proposing to change > disable/enable_intr to return the previous state in addition to setting > the state. This would be a minor pessimization on i386's. WHether it is an optimization or a pessimization is very MD. It would be a major pessimization on i386's with ICUs if we put the entire interrupt state including the ICU masks in the interrrupt state. > This then removes the need for save_intr(), and > restore_intr() can stay the same. This doesn't remove the need for save_intr(). I use it in at least one place (perhaps only one :-) where I don't want to disable interrupts any more than they already are. > Another suggestion I've received is to use intrmask_t as the type > for holding interrupt state rather than u_int. OK. > Finally, another suggestion has been to fudge the names some to stick > all of these functions in one intr_* namespace. > > The end result of these changes would be this: > > intrmask_t intr_disable(void); > intrmask_t intr_enable(void); > void intr_restore(intrmask_t); I don't like names like this much. It's really a mistake to let this stuff escape from MD code. Frotunately, it hasn't escaped far yet. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 3: 9: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.jeamland.net (rafe.jeamland.net [203.18.243.114]) by hub.freebsd.org (Postfix) with ESMTP id DE5A837B71C; Fri, 16 Mar 2001 03:09:01 -0800 (PST) (envelope-from benno@FreeBSD.org) Received: by mail.jeamland.net (Postfix, from userid 1000) id 5203070606; Fri, 16 Mar 2001 22:08:49 +1100 (EST) Date: Fri, 16 Mar 2001 22:08:49 +1100 From: Benno Rice To: Matthew Jacob Cc: Doug Rabson , John Baldwin , arch@FreeBSD.org Subject: Re: Proposal for the CPU interrupt API Message-ID: <20010316220848.A30533@rafe.jeamland.net> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mjacob@feral.com on Fri, Mar 16, 2001 at 01:41:25AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 16, 2001 at 01:41:25AM -0800, Matthew Jacob wrote: >=20 > > On the alpha, IPL is a cpu-local attribute as far as I know. >=20 > The Alpha architecture books are fairly clear that IPL is part of the > processor status word which is per-cpu. >=20 > But the semantics of interrupt disabling *may* be construed to be just > disabling all interrupts for all CPUs. I was serious when I said there > might be an advantage to leaving this vague at this time rather than tryi= ng to > nail it down. >=20 > (in the PPC architecture I believe that page faults are interrupts) Not quite. Page faults and external interrupts are both classed as 'exceptions'. External interrupts however can be turned on or off using the EE bit of the machine state register without disabling page fault (DSI or I= SI) exceptions. --=20 Benno Rice benno@FreeBSD.org --Dxnq1zWXvFF0Q93v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjqx9EAACgkQbQx7xhW+Eg7uIwCguBjedOqRR88sIuEQz1fQ9uly 1aAAoKLBQQQCLcWMptiuxzLfpm+YMn/S =3q8r -----END PGP SIGNATURE----- --Dxnq1zWXvFF0Q93v-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 6:49:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wolves.k12.mo.us (mail.wolves.k12.mo.us [207.160.214.1]) by hub.freebsd.org (Postfix) with ESMTP id 0664437B71A; Fri, 16 Mar 2001 06:49:54 -0800 (PST) (envelope-from cdillon@wolves.k12.mo.us) Received: from mail.wolves.k12.mo.us (cdillon@mail.wolves.k12.mo.us [207.160.214.1]) by mail.wolves.k12.mo.us (8.9.3/8.9.3) with ESMTP id IAA17698; Fri, 16 Mar 2001 08:49:42 -0600 (CST) (envelope-from cdillon@wolves.k12.mo.us) Date: Fri, 16 Mar 2001 08:49:41 -0600 (CST) From: Chris Dillon To: Steve Kargl Cc: Jordan Hubbard , , , Subject: Re: NO MORE '-BETA' In-Reply-To: <20010315201500.A2484@troutmask.apl.washington.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Mar 2001, Steve Kargl wrote: > On Thu, Mar 15, 2001 at 07:40:29PM -0800, Jordan Hubbard wrote: > > Hmm. I've yet to get *any* mail about BETA scaring people, and we've > > been doing them for literally years at this point. I suspect you're > > overreacting somewhat to Saverio Perugini's recent mail in -stable, > > but I'll nonetheless entertain any suggestions on what I could call > > the "pre-RC" releases without confusing them with snapshots, which > > occur every day anyway, or the actual release. > > > > Drop by the newsgroup. There was a thread last week about someone > using cvsup expecting to get 4.2-stable and he got 4.3-beta. He > was annoyed and confused because he thought beta meant "beta > quality" (as in inferior software). I've heard that quite often on IRC as well. Sometimes to fix a problem I tell someone to upgrade to -STABLE, which happens to be 4.3-BETA at this time. I get the usual "BETA!?!?" response, whereby I have to explain that FreeBSD's "BETA" is nothing like, say, Microsoft's "BETA". I don't think its a big problem, just that it might discourage a few more freebsd-newbie users from using it than it would if it weren't called "BETA". -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. 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 Fri Mar 16 6:54: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from midget.dons.net.au (daniel.lnk.telstra.net [139.130.137.70]) by hub.freebsd.org (Postfix) with ESMTP id 1832A37B71A; Fri, 16 Mar 2001 06:53:52 -0800 (PST) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (guppy.dons.net.au [203.31.81.9]) by midget.dons.net.au (8.11.1/8.9.3) with ESMTP id f2GErde42867; Sat, 17 Mar 2001 01:23:39 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sat, 17 Mar 2001 01:22:35 +1030 (CST) From: "Daniel O'Connor" To: Chris Dillon Subject: Re: NO MORE '-BETA' Cc: jkh@FreeBSD.ORG, arch@FreeBSD.ORG, bright@wintelcom.net, Jordan Hubbard , Steve Kargl Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 16-Mar-01 Chris Dillon wrote: > 4.3-BETA at this time. I get the usual "BETA!?!?" response, whereby I > have to explain that FreeBSD's "BETA" is nothing like, say, > Microsoft's "BETA". I don't think its a big problem, just that it Heh.. actually it is.. MS run RC's and Beta's too. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 7: 3:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wolves.k12.mo.us (mail.wolves.k12.mo.us [207.160.214.1]) by hub.freebsd.org (Postfix) with ESMTP id 5316237B718; Fri, 16 Mar 2001 07:03:37 -0800 (PST) (envelope-from cdillon@wolves.k12.mo.us) Received: from mail.wolves.k12.mo.us (cdillon@mail.wolves.k12.mo.us [207.160.214.1]) by mail.wolves.k12.mo.us (8.9.3/8.9.3) with ESMTP id JAA18173; Fri, 16 Mar 2001 09:03:28 -0600 (CST) (envelope-from cdillon@wolves.k12.mo.us) Date: Fri, 16 Mar 2001 09:03:27 -0600 (CST) From: Chris Dillon To: "Daniel O'Connor" Cc: , , , Jordan Hubbard , Steve Kargl Subject: Re: NO MORE '-BETA' In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 17 Mar 2001, Daniel O'Connor wrote: > On 16-Mar-01 Chris Dillon wrote: > > 4.3-BETA at this time. I get the usual "BETA!?!?" response, whereby I > > have to explain that FreeBSD's "BETA" is nothing like, say, > > Microsoft's "BETA". I don't think its a big problem, just that it > > Heh.. actually it is.. > > MS run RC's and Beta's too. I'm referring to the code quality and general usefullness of the "BETA". To me, FreeBSD's "BETA" is just another term for "-STABLE in a code freeze because we're just about to do a release", not "a buggy piece of crap". -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. 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 Fri Mar 16 7: 9:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 4939437B718; Fri, 16 Mar 2001 07:09:17 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f2GF95E13422; Fri, 16 Mar 2001 07:09:05 -0800 (PST) Date: Fri, 16 Mar 2001 07:09:05 -0800 From: Alfred Perlstein To: Chris Dillon Cc: "Daniel O'Connor" , jkh@FreeBSD.ORG, arch@FreeBSD.ORG, Jordan Hubbard , Steve Kargl Subject: Re: NO MORE '-BETA' Message-ID: <20010316070905.U29888@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from cdillon@wolves.k12.mo.us on Fri, Mar 16, 2001 at 09:03:27AM -0600 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Chris Dillon [010316 07:03] wrote: > On Sat, 17 Mar 2001, Daniel O'Connor wrote: > > > On 16-Mar-01 Chris Dillon wrote: > > > 4.3-BETA at this time. I get the usual "BETA!?!?" response, whereby I > > > have to explain that FreeBSD's "BETA" is nothing like, say, > > > Microsoft's "BETA". I don't think its a big problem, just that it > > > > Heh.. actually it is.. > > > > MS run RC's and Beta's too. > > I'm referring to the code quality and general usefullness of the > "BETA". To me, FreeBSD's "BETA" is just another term for "-STABLE in > a code freeze because we're just about to do a release", not "a buggy > piece of crap". I thought it was the "MS" that implied "buggy piece of crap" not the "BETA", but I could see how our users would be confused. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 7:10:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 60DBB37B718; Fri, 16 Mar 2001 07:10:42 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f2GFAeu13536; Fri, 16 Mar 2001 07:10:40 -0800 (PST) Date: Fri, 16 Mar 2001 07:10:40 -0800 From: Alfred Perlstein To: Chris Dillon Cc: Steve Kargl , Jordan Hubbard , arch@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: NO MORE '-BETA' Message-ID: <20010316071040.V29888@fw.wintelcom.net> References: <20010315201500.A2484@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from cdillon@wolves.k12.mo.us on Fri, Mar 16, 2001 at 08:49:41AM -0600 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Chris Dillon [010316 06:50] wrote: > On Thu, 15 Mar 2001, Steve Kargl wrote: > > > On Thu, Mar 15, 2001 at 07:40:29PM -0800, Jordan Hubbard wrote: > > > Hmm. I've yet to get *any* mail about BETA scaring people, and we've > > > been doing them for literally years at this point. I suspect you're > > > overreacting somewhat to Saverio Perugini's recent mail in -stable, > > > but I'll nonetheless entertain any suggestions on what I could call > > > the "pre-RC" releases without confusing them with snapshots, which > > > occur every day anyway, or the actual release. > > > > > > > Drop by the newsgroup. There was a thread last week about someone > > using cvsup expecting to get 4.2-stable and he got 4.3-beta. He > > was annoyed and confused because he thought beta meant "beta > > quality" (as in inferior software). > > I've heard that quite often on IRC as well. Sometimes to fix a > problem I tell someone to upgrade to -STABLE, which happens to be > 4.3-BETA at this time. I get the usual "BETA!?!?" response, whereby I > have to explain that FreeBSD's "BETA" is nothing like, say, > Microsoft's "BETA". I don't think its a big problem, just that it > might discourage a few more freebsd-newbie users from using it than it > would if it weren't called "BETA". Ok, so we have reports of confusion on the mailing lists, usenet and IRC. Jordan, where can I pick up a set those blinders you have on? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 7:28:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 1CECF37B719; Fri, 16 Mar 2001 07:28:34 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id HAA22686; Fri, 16 Mar 2001 07:28:37 -0800 Date: Fri, 16 Mar 2001 07:28:33 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Benno Rice Cc: Doug Rabson , John Baldwin , arch@FreeBSD.ORG Subject: Re: Proposal for the CPU interrupt API In-Reply-To: <20010316220848.A30533@rafe.jeamland.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > (in the PPC architecture I believe that page faults are interrupts) > > Not quite. Page faults and external interrupts are both classed as > 'exceptions'. External interrupts however can be turned on or off using the > EE bit of the machine state register without disabling page fault (DSI or ISI) > exceptions. Ah! Thanks for the clarification. What I had gotten my notion from was from AIX- if you have a spinlock contested and take a page fault in the kernel, you lock up. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 7:39:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id E2D2537B718; Fri, 16 Mar 2001 07:39:22 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f2GFdL814157; Fri, 16 Mar 2001 07:39:21 -0800 (PST) Date: Fri, 16 Mar 2001 07:39:21 -0800 From: Alfred Perlstein To: Matthew Jacob Cc: Benno Rice , Doug Rabson , John Baldwin , arch@FreeBSD.ORG Subject: Re: Proposal for the CPU interrupt API Message-ID: <20010316073921.W29888@fw.wintelcom.net> References: <20010316220848.A30533@rafe.jeamland.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mjacob@feral.com on Fri, Mar 16, 2001 at 07:28:33AM -0800 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Matthew Jacob [010316 07:28] wrote: > > > > > > > (in the PPC architecture I believe that page faults are interrupts) > > > > Not quite. Page faults and external interrupts are both classed as > > 'exceptions'. External interrupts however can be turned on or off using the > > EE bit of the machine state register without disabling page fault (DSI or ISI) > > exceptions. > > Ah! Thanks for the clarification. > > What I had gotten my notion from was from AIX- if you have a spinlock > contested and take a page fault in the kernel, you lock up. I've heard that page faults in the AIX kernel are "ok" (obviously not when holding a mutex) because some of the kernel memory is actually pageable. Any idea on what structures they keep in pageable memory? (just wondering) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 7:41:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hand.dotat.at (inch.demon.co.uk [194.222.223.128]) by hub.freebsd.org (Postfix) with ESMTP id A82DA37B71D for ; Fri, 16 Mar 2001 07:41:26 -0800 (PST) (envelope-from fanf@dotat.at) Received: from fanf by hand.dotat.at with local (Exim 3.20 #3) id 14dm8d-00008p-00; Fri, 16 Mar 2001 04:46:55 +0000 Date: Fri, 16 Mar 2001 04:46:55 +0000 From: Tony Finch To: Terry Lambert Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010316044655.C385@hand.dotat.at> References: <20010314161555.A4984@Odin.AC.HMC.Edu> <200103150439.VAA01217@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103150439.VAA01217@usr05.primenet.com> Organization: Covalent Technologies, Inc Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > >The whole idea of HTTP protection like this is pretty inane, since >we've all already agreed, I think, that it's really only useful >for mirroring, or for offloading an MD5 calculation from my 800MHz >Pentium III laptop onto a big, ballsy 66MHz 486 FTP server. RFC 2616 section 14.15: [...] The Content-MD5 entity-header field, as defined in RFC 1864 [23], is an MD5 digest of the entity-body for the purpose of providing an end-to-end message integrity check (MIC) of the entity-body. (Note: a MIC is good for detecting accidental modification of the entity-body in transit, but is not proof against malicious attacks.) [...] Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 7:41:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hand.dotat.at (inch.demon.co.uk [194.222.223.128]) by hub.freebsd.org (Postfix) with ESMTP id 5A94837B718 for ; Fri, 16 Mar 2001 07:41:28 -0800 (PST) (envelope-from fanf@dotat.at) Received: from fanf by hand.dotat.at with local (Exim 3.20 #3) id 14dm4A-000086-00 for freebsd-arch@FreeBSD.ORG; Fri, 16 Mar 2001 04:42:18 +0000 Date: Fri, 16 Mar 2001 04:42:18 +0000 From: Tony Finch To: freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010316044218.B385@hand.dotat.at> References: <20010314084651.A23104@ringworld.oblivion.bg> <200103142342.QAA09233@usr08.primenet.com> <20010314161555.A4984@Odin.AC.HMC.Edu> <20010314161555.A4984@Odin.AC.HMC.Edu>; <20010314185026.C7683@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010314185026.C7683@dragon.nuxi.com> Organization: Covalent Technologies, Inc Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David O'Brien wrote: > >How?? are clients going to take advantage of it? For the majority of FTP >clients want to fetch the file, so why ask for an MD5 of it? Are you >thinking about checking the xfer was OK? That's the only use I can think >of. This is in fact the example used in an early paper about end-to-end protocol design, one of the foundation papers of the modern Internet :-) >Since making a loadable Apache module is so much less intrusive, I call >on those wanting to experiment with this feature to do this thru this >path. If you can get the Apache people to either bundle the module as a >standard thing, or convince large sites to load it; THEN hack ftpd. Apache already has support for this in the server core, since it is part of the HTTP standard. Look at the docs for the ContentDigest directive. Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 7:41:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hand.dotat.at (inch.demon.co.uk [194.222.223.128]) by hub.freebsd.org (Postfix) with ESMTP id 2966E37B728; Fri, 16 Mar 2001 07:41:30 -0800 (PST) (envelope-from fanf@dotat.at) Received: from fanf by hand.dotat.at with local (Exim 3.20 #3) id 14dlsg-00007n-00; Fri, 16 Mar 2001 04:30:26 +0000 Date: Fri, 16 Mar 2001 04:30:25 +0000 From: Tony Finch To: David O'Brien Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010316043025.A385@hand.dotat.at> References: <20010314105918.A5204@roaming.cacheboy.net> <35525.984597779@critter> <20010314210758.A2405@roaming.cacheboy.net> <15023.53743.215996.538067@nomad.yogotech.com> <20010314130025.A3031@dragon.nuxi.com> <20010314161646.A1482@dan.emsphone.com> <15023.61042.768406.854325@nomad.yogotech.com> <15023.61042.768406.854325@nomad.yogotech.com>; <20010314151022.B5250@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010314151022.B5250@dragon.nuxi.com> Organization: Covalent Technologies, Inc Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David O'Brien wrote: > >Can you address the fact that the majority of MASTERSITES either use >HTTP, or offer it and is thus given perference by all maintainers (except >me). Thus this hack has pretty low coverage, *even* if you get the >native Linux, wu-ftpd, and ProFTPd to accept it. Content-MD5 is already in the HTTP standard, so it has more coverage than you think. It is supported by Apache, however "ContentDigest On" must be added to the configuration file since it isn't there by default. Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at WIGHT PORTLAND: SOUTHWEST 3 BACKING EAST 3 OR 4. RAIN THEN SHOWERS. MODERATE WITH FOG PATCHES, BECOMING GOOD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 7:49:20 2001 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 B1BB737B719 for ; Fri, 16 Mar 2001 07:49:17 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id KAA59527; Fri, 16 Mar 2001 10:47:57 -0500 (EST) (envelope-from wollman) Date: Fri, 16 Mar 2001 10:47:57 -0500 (EST) From: Garrett Wollman Message-Id: <200103161547.KAA59527@khavrinen.lcs.mit.edu> To: dot@dotat.at Subject: Re: [PATCH] add a SITE MD5 command to ftpd In-Reply-To: <20010316043025.A385@hand.dotat.at> References: <20010314105918.A5204@roaming.cacheboy.net> <35525.984597779@critter> <20010314210758.A2405@roaming.cacheboy.net> <15023.53743.215996.538067@nomad.yogotech.com> <20010314130025.A3031@dragon.nuxi.com> <20010314161646.A1482@dan.emsphone.com> <15023.61042.768406.854325@nomad.yogotech.com> <15023.61042.768406.854325@nomad.yogotech.com>; <20010314151022.B5250@dragon.nuxi.com> Organization: MIT Laboratory for Computer Science Cc: arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <20010316043025.A385@hand.dotat.at> you write: >Content-MD5 is already in the HTTP standard, so it has more coverage >than you think. Unfortunately, the HTTP/1.1 behavior is completely broken with respect to byte-ranges. Does Apache send the Content-MD5 (when configured) for HEAD requests? -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 7:52:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 8FAC437B71C; Fri, 16 Mar 2001 07:52:36 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id HAA22797; Fri, 16 Mar 2001 07:52:38 -0800 Date: Fri, 16 Mar 2001 07:52:34 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Alfred Perlstein Cc: Benno Rice , Doug Rabson , John Baldwin , arch@FreeBSD.ORG Subject: page faults in AIX kernel In-Reply-To: <20010316073921.W29888@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ different topic ] On Fri, 16 Mar 2001, Alfred Perlstein wrote: > * Matthew Jacob [010316 07:28] wrote: > > > > > > > > > > (in the PPC architecture I believe that page faults are interrupts) > > > > > > Not quite. Page faults and external interrupts are both classed as > > > 'exceptions'. External interrupts however can be turned on or off using the > > > EE bit of the machine state register without disabling page fault (DSI or ISI) > > > exceptions. > > > > Ah! Thanks for the clarification. > > > > What I had gotten my notion from was from AIX- if you have a spinlock > > contested and take a page fault in the kernel, you lock up. > > I've heard that page faults in the AIX kernel are "ok" (obviously > not when holding a mutex) because some of the kernel memory is > actually pageable. > > Any idea on what structures they keep in pageable memory? > > (just wondering) They have a concept of pinned and unpinned memory. IIRC (it's been a while now- one of my former clients took back the 2 processor 300MHz PPC box about a year ago and I hadn't done any work with it for 2-3 years) pinned memory isn't unpageable while unpinned memory is.... Let's see if I can dig up some examples... I can't remember exactly what other 'structures' they then actually have as pageable... I guess pretty much anything that isn't pinned (now isn't *that* a useful answer) :-).. Okay- here's one: /* * If this is the first time through: * Add entry to the device switch table to call this driver */ if (nconfigured == 0) { result = devswadd(dev, &vtd_dsw); if (result != 0) { Trace1(0, "vtd_config: devswadd result: %d", result); break; } result = pincode((int (*) ()) vtd_timer); if (result) { Trace1(0, "vtd_config: pincode result: %d", result); devswdel(dev); break; } } nconfigured++; Note that the timer funcion is pinned so that it can't be paged out when a soft call happens (which would be embarrassing). -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 7:55:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 3E31B37B718 for ; Fri, 16 Mar 2001 07:55:31 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2GFtQO93538; Fri, 16 Mar 2001 07:55:26 -0800 (PST) (envelope-from obrien) Date: Fri, 16 Mar 2001 07:55:25 -0800 From: "David O'Brien" To: Tony Finch Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010316075525.A93456@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <35525.984597779@critter> <20010314210758.A2405@roaming.cacheboy.net> <15023.53743.215996.538067@nomad.yogotech.com> <20010314130025.A3031@dragon.nuxi.com> <20010314161646.A1482@dan.emsphone.com> <15023.61042.768406.854325@nomad.yogotech.com> <15023.61042.768406.854325@nomad.yogotech.com>; <20010314151022.B5250@dragon.nuxi.com> <20010316043025.A385@hand.dotat.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010316043025.A385@hand.dotat.at>; from dot@dotat.at on Fri, Mar 16, 2001 at 04:30:25AM +0000 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 X-Loop: FreeBSD.ORG On Fri, Mar 16, 2001 at 04:30:25AM +0000, Tony Finch wrote: > >Can you address the fact that the majority of MASTERSITES either use > >HTTP, or offer it and is thus given perference by all maintainers (except > >me). Thus this hack has pretty low coverage, *even* if you get the > >native Linux, wu-ftpd, and ProFTPd to accept it. > > Content-MD5 is already in the HTTP standard, so it has more coverage > than you think. It is supported by Apache, however "ContentDigest On" > must be added to the configuration file since it isn't there by > default. Then convience people to turn it on, and run some expierments. That's what people have advocated here. And since Apache already supports it, and the growing number of distfiles sites offering only http, this really seems the right path to take for now. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 8:46:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hand.dotat.at (inch.demon.co.uk [194.222.223.128]) by hub.freebsd.org (Postfix) with ESMTP id 03EF837B718 for ; Fri, 16 Mar 2001 08:46:35 -0800 (PST) (envelope-from fanf@dotat.at) Received: from fanf by hand.dotat.at with local (Exim 3.20 #3) id 14dxMn-00013e-00; Fri, 16 Mar 2001 16:46:17 +0000 Date: Fri, 16 Mar 2001 16:46:17 +0000 From: Tony Finch To: Garrett Wollman Cc: arch@freebsd.org Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010316164617.N385@hand.dotat.at> References: <20010314210758.A2405@roaming.cacheboy.net> <15023.53743.215996.538067@nomad.yogotech.com> <20010314130025.A3031@dragon.nuxi.com> <20010314161646.A1482@dan.emsphone.com> <15023.61042.768406.854325@nomad.yogotech.com> <15023.61042.768406.854325@nomad.yogotech.com>; <20010314151022.B5250@dragon.nuxi.com> <20010316043025.A385@hand.dotat.at> <200103161547.KAA59527@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103161547.KAA59527@khavrinen.lcs.mit.edu> Organization: Covalent Technologies, Inc Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Garrett Wollman wrote: > >Unfortunately, the HTTP/1.1 behavior is completely broken with respect >to byte-ranges. Hmm, it does seem a bit screwy. >Does Apache send the Content-MD5 (when configured) for HEAD requests? Yes. Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at MALIN: EAST 5 TO 7, OCCASIONALLY GALE 8 IN SOUTH. MAINLY FAIR. MODERATE OR GOOD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 9:17:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 1F8BB37B718; Fri, 16 Mar 2001 09:17:40 -0800 (PST) (envelope-from jkh@osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.2/8.11.1) with ESMTP id f2GHG2H88417; Fri, 16 Mar 2001 09:16:02 -0800 (PST) (envelope-from jkh@osd.bsdi.com) To: sgk@troutmask.apl.washington.edu Cc: bright@wintelcom.net, arch@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: NO MORE '-BETA' In-Reply-To: <20010315201500.A2484@troutmask.apl.washington.edu> References: <20010315180837.N29888@fw.wintelcom.net> <20010315194029C.jkh@osd.bsdi.com> <20010315201500.A2484@troutmask.apl.washington.edu> X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010316091602N.jkh@osd.bsdi.com> Date: Fri, 16 Mar 2001 09:16:02 -0800 From: Jordan Hubbard X-Dispatcher: imput version 20000228(IM140) Lines: 18 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Drop by the newsgroup. There was a thread last week about > someone using cvsup expecting to get 4.2-stable and he got > 4.3-beta. He was annoyed and confused because he thought > beta meant "beta quality" (as in inferior software). Well, there are two different things here though: 1. The usage of "BETA" to denote some pre-release collection of bits on an FTP site. 2. The usage of BETA in newvers.sh I think it's #2 which is actually causing all the problems here and I would happily forgo changing newvers.sh until it's time for the actual release. I don't usually mark it BETA myself, but one of my helpers here jumped the gun this time. :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 9:38:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 6CCE137B718 for ; Fri, 16 Mar 2001 09:38:28 -0800 (PST) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id JAA28428 for ; Fri, 16 Mar 2001 09:38:28 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda28423; Fri Mar 16 09:38:24 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.2/8.9.1) id f2GHcJU45716 for ; Fri, 16 Mar 2001 09:38:19 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdX45714; Fri Mar 16 09:37:56 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.3/8.9.1) id f2GHbua04336 for ; Fri, 16 Mar 2001 09:37:56 -0800 (PST) Message-Id: <200103161737.f2GHbua04336@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdiu4332; Fri Mar 16 09:37:42 2001 X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: freebsd-arch@FreeBSD.ORG Subject: Re: flags settings for modules In-reply-to: Your message of "Wed, 14 Mar 2001 11:16:29 PST." <20010314111629.A1018@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Mar 2001 09:37:42 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010314111629.A1018@dragon.nuxi.com>, "David O'Brien" writes: > I committed a change sys/conf/kmod.mk such that modules are now installed > with flags "schg" as the kernel has been forever. > > It was asked of me if the "schg" flags do much more than get in the > way now? Some feel we're really using "schg" mainly to inhibit foot > shooting. It doesn't really help security or we would set it on more > libraries than libc.so.* and a couple of crypto shared libraries. > > So the question is do we want to keep my change? If so, shouldn't we use > "schg" in a *lot* more places? Otherwise it's use is nebulous Let's keep the change. Yes we should use schg in a lot more places for the reason you've articulated above. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 9:48: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 25CB537B718; Fri, 16 Mar 2001 09:48:05 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id JAA54015; Fri, 16 Mar 2001 09:47:46 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200103161747.JAA54015@gndrsh.dnsmgr.net> Subject: Re: NO MORE '-BETA' In-Reply-To: <20010316091602N.jkh@osd.bsdi.com> from Jordan Hubbard at "Mar 16, 2001 09:16:02 am" To: jkh@osd.bsdi.com (Jordan Hubbard) Date: Fri, 16 Mar 2001 09:47:46 -0800 (PST) Cc: sgk@troutmask.apl.washington.edu, bright@wintelcom.net, arch@FreeBSD.ORG, jkh@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Drop by the newsgroup. There was a thread last week about > > someone using cvsup expecting to get 4.2-stable and he got > > 4.3-beta. He was annoyed and confused because he thought > > beta meant "beta quality" (as in inferior software). > > Well, there are two different things here though: > > 1. The usage of "BETA" to denote some pre-release collection of bits > on an FTP site. > > 2. The usage of BETA in newvers.sh > > I think it's #2 which is actually causing all the problems here and I > would happily forgo changing newvers.sh until it's time for the actual > release. I don't usually mark it BETA myself, but one of my helpers > here jumped the gun this time. :) As the implementor of this part of newvers.sh I would have to say that the use of BRANCH has been heavly overloaded by the release engineers (including myself) to indicated points on a BRANCH. One thing that I probably did differently was that the points on a branch were usually never committed, I simply edited the copy in my build tree, built the -ALPHA, -BETA, whatever, and put the bits up. If anything I would like to see this changed to be more in line with that. Perhaps commit the -BETA, then immediately commit it back to -STABLE so we can use these commit dates in a cvs co -d to get the same tree that release engineering used to build the release, but those cvsuping are very very unlikely to see a -BETA version. You have to change both the version and the branch up and back down, not so sure I feel good about that :-(. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 9:49:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id E7B3F37B719; Fri, 16 Mar 2001 09:49:27 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f2GHnLn60220; Fri, 16 Mar 2001 09:49:21 -0800 (PST) (envelope-from dillon) Date: Fri, 16 Mar 2001 09:49:21 -0800 (PST) From: Matt Dillon Message-Id: <200103161749.f2GHnLn60220@earth.backplane.com> To: Alfred Perlstein Cc: Chris Dillon , Steve Kargl , Jordan Hubbard , arch@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: NO MORE '-BETA' References: <20010315201500.A2484@troutmask.apl.washington.edu> <20010316071040.V29888@fw.wintelcom.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I don't think it's that big of an issue. People who track -stable on a daily or weekly basis should tend to understand the release cycle anyway. There are lots of people who just track the release CDs, and they'll never see the -BETAs. I don't think we need to cop to the lowest common denominator in this case. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 9:53: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 4172337B728 for ; Fri, 16 Mar 2001 09:52:56 -0800 (PST) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id JAA28502; Fri, 16 Mar 2001 09:52:48 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda28498; Fri Mar 16 09:52:36 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.2/8.9.1) id f2GHqVP45887; Fri, 16 Mar 2001 09:52:31 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdj45885; Fri Mar 16 09:51:58 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.3/8.9.1) id f2GHpvA04419; Fri, 16 Mar 2001 09:51:57 -0800 (PST) Message-Id: <200103161751.f2GHpvA04419@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdqQ4413; Fri Mar 16 09:51:10 2001 X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: Warner Losh Cc: freebsd-arch@FreeBSD.ORG Subject: Re: flags settings for modules In-reply-to: Your message of "Thu, 15 Mar 2001 01:16:06 MST." <200103150816.f2F8G6920260@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Mar 2001 09:51:10 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200103150816.f2F8G6920260@harmony.village.org>, Warner Losh writes: > In message <20010314111629.A1018@dragon.nuxi.com> "David O'Brien" writes: > : So the question is do we want to keep my change? If so, shouldn't we use > : "schg" in a *lot* more places? Otherwise it's use is nebulous > > I think the change is premature. Until such time as we have a > convenient way to build a system that all vectors to compromise of > schg have been plugged, setting it to gain "security" is at best > folly. > > I do not argue that one could set schg on files by hand and might be > able to not miss any, such an undertaking is still very very > difficult. You have to make sure that all the rc scripts are schg. > And then all scripts that are run before we raise secure level. And > all binaries that are touched (and facist path policing of all > scripts). And then there's all the libraries that are linked in > against those binaries. And then there are all the modules loaded by > default or by the loader. And you have to secure the loader agianst > change in a similar way. And let's not forget any config files that > all these files/programs use. Oh, and let's not forget those things > that are too obscure for me to think of there. > > There are likely items in the list that I've forgotten. Since the > list is still so long, and since there's no one working on tightening > things up, I think that adding schg to modules is premature and will > cause more hassles than it is worth. > > Before people think that I don't think that this is worth it, or that > I have a negative attitude, I would like to point out that I think > work in this area would be beneficial. A script in /usr/sbin or a port might be the best answer. Maintaining this script might be another story. I'm currently working on a Tripwire 2.3.1 port and building the default policy file for FreeBSD has been a tedious process. I would think that building an schg script or port would be just as tedious. I could generate the script/port based on my work on the FreeBSD Tripwire policy file I'm currently building for the upcoming Tripwire 2.3.1 port. If people like this idea, I can do the work as it dovetails nicely with the Tripwire work I've been doing. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 10:14:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail-100baset.rpi.edu [128.113.26.45]) by hub.freebsd.org (Postfix) with ESMTP id 5D26337B719; Fri, 16 Mar 2001 10:14:43 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id NAA105228; Fri, 16 Mar 2001 13:14:39 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20010315194029C.jkh@osd.bsdi.com> References: <20010315180837.N29888@fw.wintelcom.net> <20010315194029C.jkh@osd.bsdi.com> Date: Fri, 16 Mar 2001 13:14:37 -0500 To: Jordan Hubbard , bright@wintelcom.net From: Garance A Drosihn Subject: Re: NO MORE '-BETA' Cc: arch@FreeBSD.ORG, jkh@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 7:40 PM -0800 3/15/01, Jordan Hubbard wrote: >Hmm. I've yet to get *any* mail about BETA scaring people, and we've >been doing them for literally years at this point. I suspect you're >overreacting somewhat to Saverio Perugini's recent mail in -stable, >but I'll nonetheless entertain any suggestions on what I could call >the "pre-RC" releases without confusing them with snapshots, which >occur every day anyway, or the actual release. I've only been following freebsd for two or three years, but every single time freebsd starts ramping up for a release I see some newbie freebsd users come on "lily" (our equivalent of IRC) and say "Hey, I meant to get N.x-stable, but I got N.x+1-beta!! What did I do wrong? How do I back out?" It only takes a few minutes to calm them down and say "that's just the way freebsd does things, don't worry about it", but it does happen (with different people, of course) for every release that I've seen. How about calling it: 4.3-pre-release When we then create a new branch after the release (the "super stable, critical bug-fixes only" branch), we can call that 4.3-post-release I'm not really all that fond of "4.3-post-release", but I thought I'd also bring up the question of what the easily-identifiable name for that branch should be, as long as we're talking about names. -- Garance Alistair Drosehn = gad@eclipse.acs.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 Fri Mar 16 10:42:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 3E85437B71A; Fri, 16 Mar 2001 10:42:56 -0800 (PST) (envelope-from jkh@osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.2/8.11.1) with ESMTP id f2GIfPH88883; Fri, 16 Mar 2001 10:41:25 -0800 (PST) (envelope-from jkh@osd.bsdi.com) To: bright@wintelcom.net Cc: cdillon@wolves.k12.mo.us, sgk@troutmask.apl.washington.edu, arch@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: NO MORE '-BETA' In-Reply-To: <20010316071040.V29888@fw.wintelcom.net> References: <20010315201500.A2484@troutmask.apl.washington.edu> <20010316071040.V29888@fw.wintelcom.net> X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010316104124Z.jkh@osd.bsdi.com> Date: Fri, 16 Mar 2001 10:41:24 -0800 From: Jordan Hubbard X-Dispatcher: imput version 20000228(IM140) Lines: 9 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Ok, so we have reports of confusion on the mailing lists, usenet and > IRC. Jordan, where can I pick up a set those blinders you have on? Chill, Albert. I think we've already established that a) It's the newvers.sh "BETAness" that's really freaking people out and b) That you've yet to supply any practical name alternative, you're just whining about it at this point. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 11: 9:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id 7F0B937B71A for ; Fri, 16 Mar 2001 11:09:16 -0800 (PST) (envelope-from roam@orbitel.bg) Received: (qmail 8704 invoked by uid 1000); 16 Mar 2001 19:08:33 -0000 Date: Fri, 16 Mar 2001 21:08:33 +0200 From: Peter Pentchev To: arch@FreeBSD.org Subject: add MD5Chunk(filename, .., offset, length) to libmd Message-ID: <20010316210833.C8245@ringworld.oblivion.bg> Mail-Followup-To: arch@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, (I wonder if I'm starting another bikeshed, but oh well ;) As phk pointed out in the SITE MD5 thread, it is sometimes useful to compute the MD5 hash over a range of a file. I agree this is trivial to implement, but why not have it in our standard toolbox? Attached is a patch to libmd, which adds an MD5Check() function, similar in all aspects to MD5File() (actually quite a lot of it was shamelessly stolen from MD5File ;), but with additional two arguments, offset and length to compute the hash over. If there is sufficient interest, I could take the time to document it in the corresponding manpages, too. At the end is a patch to /sbin/md5, which adds a new -R (range) argument. There are two proposed implementations with different semantics - one puts the offset:length as an optarg to -R, thus keeping md5(1)'s ability to process multiple files, the other - conditionalized on an ALT_RFLAG compiler define - only accepts one file name, and takes the offset and length as additional cmdline arguments after the filename. It's up to y'all to choose between the two, should you like either one at all :) G'luck, Peter -- Hey, out there - is it *you* reading me, or is it someone else? Index: src/sys/sys/md5.h =================================================================== RCS file: /home/ncvs/src/sys/sys/md5.h,v retrieving revision 1.13 diff -u -r1.13 md5.h --- src/sys/sys/md5.h 1999/12/29 04:24:44 1.13 +++ src/sys/sys/md5.h 2001/03/16 19:00:32 @@ -34,6 +34,7 @@ } MD5_CTX; #include +#include __BEGIN_DECLS void MD5Init (MD5_CTX *); @@ -42,6 +43,7 @@ void MD5Final (unsigned char [16], MD5_CTX *); char * MD5End(MD5_CTX *, char *); char * MD5File(const char *, char *); +char * MD5Chunk(const char *, char *, off_t, off_t); char * MD5Data(const unsigned char *, unsigned int, char *); #ifdef _KERNEL void MD5Transform __P((u_int32_t [4], const unsigned char [64])); Index: src/lib/libmd/md2.h =================================================================== RCS file: /home/ncvs/src/lib/libmd/md2.h,v retrieving revision 1.8 diff -u -r1.8 md2.h --- src/lib/libmd/md2.h 1999/08/28 00:05:04 1.8 +++ src/lib/libmd/md2.h 2001/03/16 19:00:32 @@ -31,6 +31,7 @@ } MD2_CTX; #include +#include __BEGIN_DECLS void MD2Init(MD2_CTX *); @@ -39,6 +40,7 @@ void MD2Final(unsigned char [16], MD2_CTX *); char * MD2End(MD2_CTX *, char *); char * MD2File(const char *, char *); +char * MD2Chunk(const char *, char *, off_t, off_t); char * MD2Data(const unsigned char *, unsigned int, char *); __END_DECLS Index: src/lib/libmd/md4.h =================================================================== RCS file: /home/ncvs/src/lib/libmd/md4.h,v retrieving revision 1.9 diff -u -r1.9 md4.h --- src/lib/libmd/md4.h 1999/08/28 00:05:05 1.9 +++ src/lib/libmd/md4.h 2001/03/16 19:00:32 @@ -33,6 +33,7 @@ } MD4_CTX; #include +#include __BEGIN_DECLS void MD4Init(MD4_CTX *); @@ -41,6 +42,7 @@ void MD4Final(unsigned char [16], MD4_CTX *); char * MD4End(MD4_CTX *, char *); char * MD4File(const char *, char *); +char * MD4Chunk(const char *, char *, off_t, off_t); char * MD4Data(const unsigned char *, unsigned int, char *); __END_DECLS Index: src/lib/libmd/mdXhl.c =================================================================== RCS file: /home/ncvs/src/lib/libmd/mdXhl.c,v retrieving revision 1.13 diff -u -r1.13 mdXhl.c --- src/lib/libmd/mdXhl.c 1999/08/28 00:05:07 1.13 +++ src/lib/libmd/mdXhl.c 2001/03/16 19:00:33 @@ -11,6 +11,7 @@ */ #include +#include #include #include @@ -53,6 +54,43 @@ while ((i = read(f,buffer,sizeof buffer)) > 0) { MDXUpdate(&ctx,buffer,i); } + j = errno; + close(f); + errno = j; + if (i < 0) return 0; + return MDXEnd(&ctx, buf); +} + +char * +MDXChunk(const char *filename, char *buf, off_t ofs, off_t len) +{ + unsigned char buffer[BUFSIZ]; + MDX_CTX ctx; + struct stat stbuf; + int f, i, j; + off_t n; + + MDXInit(&ctx); + f = open(filename, O_RDONLY); + if (f < 0) return 0; + if (fstat(f, &stbuf) < 0) return 0; + if (ofs > stbuf.st_size) + ofs = stbuf.st_size; + if (len == 0) + len = stbuf.st_size - ofs; + else if (len > stbuf.st_size - ofs) + len = stbuf.st_size - ofs; + if (lseek(f, ofs, SEEK_SET) < 0) return 0; + n = len; + while (n > 0) { + if (n > sizeof(buffer)) + i = read(f, buffer, sizeof(buffer)); + else + i = read(f, buffer, n); + if (i < 0) break; + MDXUpdate(&ctx, buffer, i); + n -= i; + } j = errno; close(f); errno = j; Index: src/sbin/md5/md5.c =================================================================== RCS file: /home/ncvs/src/sbin/md5/md5.c,v retrieving revision 1.21 diff -u -r1.21 md5.c --- src/sbin/md5/md5.c 2000/11/08 20:41:35 1.21 +++ src/sbin/md5/md5.c 2001/03/16 19:01:16 @@ -40,6 +40,7 @@ int qflag; int rflag; +int Rflag; static void MDString PROTO_LIST((char *)); static void MDTimeTrial PROTO_LIST((void)); @@ -64,9 +65,15 @@ int ch; char *p; char buf[33]; + off_t ofs, len; + ofs = len = 0; if (argc > 1) { - while ((ch = getopt(argc, argv, "ps:qrtx")) != -1) { +#ifndef ALT_RFLAG + while ((ch = getopt(argc, argv, "ps:qR:rtx")) != -1) { +#else + while ((ch = getopt(argc, argv, "ps:qRrtx")) != -1) { +#endif switch (ch) { case 'p': MDFilter(1); @@ -74,6 +81,20 @@ case 'q': qflag = 1; break; + case 'R': +#ifndef ALT_RFLAG + ofs = strtoul(optarg, &p, 10); + if (p == optarg) + usage(); + if (*p) { + if (*p != ':') + usage(); + else + len = strtoul(p + 1, NULL, 10); + } +#endif + Rflag = 1; + break; case 'r': rflag = 1; break; @@ -90,8 +111,22 @@ usage(); } } +#ifdef ALT_RFLAG + if (Rflag) { + if ((argc == optind) || (argc > optind + 3)) + usage(); + if (argc > optind + 1) + ofs = strtoul(argv[optind+1], NULL, 10); + if (argc > optind + 2) + len = strtoul(argv[optind+2], NULL, 10); + argc = optind + 1; + } +#endif while (optind < argc) { - p = MD5File(argv[optind], buf); + if (!Rflag) + p = MD5File(argv[optind], buf); + else + p = MD5Chunk(argv[optind], buf, ofs, len); if (!p) warn("%s", argv[optind]); else @@ -214,6 +249,11 @@ usage() { +#ifndef ALT_RFLAG + fprintf(stderr, "usage: md5 [-pqrtx] [-R ofs:len] [-s string] [files ...]\n"); +#else fprintf(stderr, "usage: md5 [-pqrtx] [-s string] [files ...]\n"); + fprintf(stderr, " md5 [-pqrtx] -R file [ofs [len]]\n"); +#endif exit(1); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 11:11: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id 4EB9E37B719 for ; Fri, 16 Mar 2001 11:11:01 -0800 (PST) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (bill.cs.rpi.edu [128.213.2.2]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id OAA81258 for ; Fri, 16 Mar 2001 14:10:56 -0500 (EST) Message-Id: <200103161910.OAA81258@cs.rpi.edu> To: freebsd-arch@freebsd.org Subject: idle wonderings about 'struct pcred' Date: Fri, 16 Mar 2001 14:10:55 -0500 From: "David E. Cross" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG How would people feel about a fairly significant change to the pcred structure? The change would be to facilitate different types of authentication information about each process (say perhaps kerberos credentials, or private keys, or encryption keys for a file, ACL type info, etc. The possibilities are enormous). What got me thinking about this is how AFS handles this problem... it takes the first 2 GID slots away from the process to store kernel data into (yuck), there must be a better way, especially with the proliferation of authentication systems, and the need to store and manage that data easily and securely. NFSv4 will use GSS-API, for example, I think this system would be a much better approach than trying to store the authentication information in userland and needing to communicate that with the kernel somehow. What I had in mind would be something like the following: struct pcred { enum p_type; void *p_data; struct pcred *next; }; (That is a _very_ rough idea). Our current, traditional, 'struct pcred' would become 'pcred_unix', with a p_type of 0 (#define-d to PCRED_TYPE_UNIX) and would be stuffed into the p_data pointer). What do people think? -- David Cross | email: crossd@cs.rpi.edu Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 11:26:29 2001 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 66D5737B718 for ; Fri, 16 Mar 2001 11:26:26 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f2GJQN114991; Fri, 16 Mar 2001 20:26:23 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Peter Pentchev Cc: arch@FreeBSD.ORG Subject: Re: add MD5Chunk(filename, .., offset, length) to libmd In-Reply-To: Your message of "Fri, 16 Mar 2001 21:08:33 +0200." <20010316210833.C8245@ringworld.oblivion.bg> Date: Fri, 16 Mar 2001 20:26:23 +0100 Message-ID: <14989.984770783@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010316210833.C8245@ringworld.oblivion.bg>, Peter Pentchev writes: >Hi, > >(I wonder if I'm starting another bikeshed, but oh well ;) > >As phk pointed out in the SITE MD5 thread, it is sometimes useful >to compute the MD5 hash over a range of a file. I agree this is trivial >to implement, but why not have it in our standard toolbox? If you include manpage patches I'll commit it. -- 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 Fri Mar 16 11:27:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 9771A37B71A; Fri, 16 Mar 2001 11:27:15 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2GJR8c95659; Fri, 16 Mar 2001 11:27:08 -0800 (PST) (envelope-from obrien) Date: Fri, 16 Mar 2001 11:27:08 -0800 From: "David O'Brien" To: Steve Kargl Cc: arch@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: NO MORE '-BETA' Message-ID: <20010316112707.C93551@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <20010315180837.N29888@fw.wintelcom.net> <20010315194029C.jkh@osd.bsdi.com> <20010315201500.A2484@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010315201500.A2484@troutmask.apl.washington.edu>; from sgk@troutmask.apl.washington.edu on Thu, Mar 15, 2001 at 08:15:00PM -0800 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 X-Loop: FreeBSD.ORG On Thu, Mar 15, 2001 at 08:15:00PM -0800, Steve Kargl wrote: > Drop by the newsgroup. There was a thread last week about > someone using cvsup expecting to get 4.2-stable and he got > 4.3-beta. He was annoyed and confused because he thought > beta meant "beta quality" (as in inferior software). It potentially is considering the amount of CVS commits that always happen right before the code freeze. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 11:30:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 84C6937B719 for ; Fri, 16 Mar 2001 11:30:17 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2GJUFq95686; Fri, 16 Mar 2001 11:30:15 -0800 (PST) (envelope-from obrien) Date: Fri, 16 Mar 2001 11:30:14 -0800 From: "David O'Brien" To: Jordan Hubbard Cc: arch@FreeBSD.ORG Subject: Re: NO MORE '-BETA' Message-ID: <20010316113014.D93551@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <20010315180837.N29888@fw.wintelcom.net> <20010315194029C.jkh@osd.bsdi.com> <20010315201500.A2484@troutmask.apl.washington.edu> <20010316091602N.jkh@osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010316091602N.jkh@osd.bsdi.com>; from jkh@osd.bsdi.com on Fri, Mar 16, 2001 at 09:16:02AM -0800 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 X-Loop: FreeBSD.ORG On Fri, Mar 16, 2001 at 09:16:02AM -0800, Jordan Hubbard wrote: > 2. The usage of BETA in newvers.sh > > I think it's #2 which is actually causing all the problems here and I > would happily forgo changing newvers.sh until it's time for the actual > release. I don't usually mark it BETA myself, but one of my helpers > here jumped the gun this time. :) It is needed for -ports. *MANY* ports break when uname starts reporting a minor version greater than the existing one. So we are back to needing a new name. Would "4.3-PRE-RELEASE" make people happy? -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 11:38:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 6027C37B71A; Fri, 16 Mar 2001 11:38:18 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id MAA10166; Fri, 16 Mar 2001 12:34:56 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpdAAAV.aqUt; Fri Mar 16 12:34:44 2001 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id MAA16182; Fri, 16 Mar 2001 12:37:59 -0700 (MST) From: Terry Lambert Message-Id: <200103161937.MAA16182@usr02.primenet.com> Subject: Re: Proposal for the CPU interrupt API To: bright@wintelcom.net (Alfred Perlstein) Date: Fri, 16 Mar 2001 19:37:53 +0000 (GMT) Cc: mjacob@feral.com (Matthew Jacob), benno@FreeBSD.ORG (Benno Rice), dfr@nlsystems.com (Doug Rabson), jhb@FreeBSD.ORG (John Baldwin), arch@FreeBSD.ORG In-Reply-To: <20010316073921.W29888@fw.wintelcom.net> from "Alfred Perlstein" at Mar 16, 2001 07:39:21 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I've heard that page faults in the AIX kernel are "ok" (obviously > not when holding a mutex) because some of the kernel memory is > actually pageable. Yes. > Any idea on what structures they keep in pageable memory? > > (just wondering) AIX can swap anything in a segment marked "pageable", which include most of the kernel not in the paging path. So can Windows 95, 98, CE, ME, NT... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 11:38:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 4FB2C37B719 for ; Fri, 16 Mar 2001 11:38:29 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2GJboG60191; Fri, 16 Mar 2001 11:37:50 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200103160338.f2G3cJs55363@earth.backplane.com> Date: Fri, 16 Mar 2001 11:38:00 -0800 (PST) From: John Baldwin To: Matt Dillon Subject: Re: Proposal for the CPU interrupt API Cc: arch@FreeBSD.org, Matthew Jacob Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 16-Mar-01 Matt Dillon wrote: > >:Yep. I think that on the Alpha the IPL may be shared among all CPU's or may >:be >:per-CPU but I'm not sure. On the x86 it would only be for the local CPU, but >:all that any calling code should depend on is that it disables interrupts for >:the current CPU. > > Well, if the IPL is shared amoung all CPU's then for disable_intr() or > work as advertised it would have to keep a reference count, since you > might have several cpu's disabling interrupts at the same time. That > would imply that every call to disable_intr() or enable_intr() must be > matched by a call to restore_intr(). Umm, actually, on the alpha it can go both ways, and yes we _do_ match intr_restore() with intr_disable() and intr_enable() (except right now some x86 MD code doesn't do this yet). We actually added save_intr() and restore_intr() for precisely this reason back in the first SMPng commit a few months ago. You did read the part of my post that included the API we currently use, right? > And as far as your inane comments go, Matt... if you stopped to actually > read my posting you might have understood my issue a little better. I > don't know where you got your attitude problem or why you are being so > combative, and I'm not interested either. And if you would actually read all of the post and keep up to date with the code so that you weren't telling us to do what we are already doing it would be more helpful, too. Honestly, Matt, you're sort of reminding me of Terry here. :) > -Matt -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - 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 Fri Mar 16 11:38:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 0911C37B718 for ; Fri, 16 Mar 2001 11:38:35 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2GJbpG60199; Fri, 16 Mar 2001 11:37:52 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 16 Mar 2001 11:38:01 -0800 (PST) From: John Baldwin To: Bruce Evans Subject: Re: Proposal for the CPU interrupt API Cc: arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 16-Mar-01 Bruce Evans wrote: > On Thu, 15 Mar 2001, John Baldwin wrote: > >> ... >> Typically, interrupts are disabled in the following fashion: >> >> u_int foo = save_intr(); >> disable_intr(); >> ... >> restore_intr(foo); >> >> Unfortunately, this can be somewhat expensive on the Alpha, as both >> save_intr() and disable_intr() involve a PAL call. However, the Alpha >> returns the previous state whenever you set the interrupt state, which >> allows you to only make 1 PAL call. Thus, I'm proposing to change >> disable/enable_intr to return the previous state in addition to setting >> the state. > > This would be a minor pessimization on i386's. WHether it is an optimization > or a pessimization is very MD. It would be a major pessimization on i386's > with ICUs if we put the entire interrupt state including the ICU masks in > the interrrupt state. I don't think this needs to go near the ICU state, but yes, it is a minor pessimization on i386. >> This then removes the need for save_intr(), and >> restore_intr() can stay the same. > > This doesn't remove the need for save_intr(). I use it in at least one > place (perhaps only one :-) where I don't want to disable interrupts any > more than they already are. If it is just the CPU status, then just intr_disable() (or disable_intr()) will accomplish this. >> Finally, another suggestion has been to fudge the names some to stick >> all of these functions in one intr_* namespace. >> >> The end result of these changes would be this: >> >> intrmask_t intr_disable(void); >> intrmask_t intr_enable(void); >> void intr_restore(intrmask_t); > > I don't like names like this much. I don't care too strongly about the names either way. But it seems to me that foo_* namespaces are easier to enforce than *_foo namespaces. > It's really a mistake to let this stuff escape from MD code. Frotunately, > it hasn't escaped far yet. The only somewhat MI place it is used is in the bowels of the mutex code. Any MI code that wishes to prevent preemption should use a spinlock instead of disabling interrupts manually now. > Bruce -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - 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 Fri Mar 16 11:38:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id B5A3C37B719 for ; Fri, 16 Mar 2001 11:38:42 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2GJboG60195; Fri, 16 Mar 2001 11:37:50 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 16 Mar 2001 11:38:01 -0800 (PST) From: John Baldwin To: Doug Rabson Subject: Re: Proposal for the CPU interrupt API Cc: arch@FreeBSD.org, Matthew Jacob , Matt Dillon Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 16-Mar-01 Doug Rabson wrote: > On Thu, 15 Mar 2001, Matt Dillon wrote: > >> >> :I would hope it would actually disable interrupts. >> >> On all cpu's or just the current cpu? > > Just the current one, I think. Looking in the brown book again I think it is always just the current CPU. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - 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 Fri Mar 16 11:44: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id E10FE37B71A for ; Fri, 16 Mar 2001 11:43:53 -0800 (PST) (envelope-from roam@ringworld.nanolink.com) Received: (qmail 9505 invoked by uid 1000); 16 Mar 2001 19:43:10 -0000 Date: Fri, 16 Mar 2001 21:43:10 +0200 From: Peter Pentchev To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG Subject: Re: add MD5Chunk(filename, .., offset, length) to libmd Message-ID: <20010316214310.A8968@ringworld.oblivion.bg> Mail-Followup-To: Poul-Henning Kamp , arch@FreeBSD.ORG References: <20010316210833.C8245@ringworld.oblivion.bg> <14989.984770783@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <14989.984770783@critter>; from phk@critter.freebsd.dk on Fri, Mar 16, 2001 at 08:26:23PM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Mar 16, 2001 at 08:26:23PM +0100, Poul-Henning Kamp wrote: > In message <20010316210833.C8245@ringworld.oblivion.bg>, Peter Pentchev writes: > >Hi, > > > >(I wonder if I'm starting another bikeshed, but oh well ;) > > > >As phk pointed out in the SITE MD5 thread, it is sometimes useful > >to compute the MD5 hash over a range of a file. I agree this is trivial > >to implement, but why not have it in our standard toolbox? > > If you include manpage patches I'll commit it. Thanks! :) OK, here's the libmd part. How about /sbin/md5? ALT_RFLAG or not? Or not at all? :) G'luck, Peter -- .siht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI Index: src/sys/sys/md5.h =================================================================== RCS file: /home/ncvs/src/sys/sys/md5.h,v retrieving revision 1.13 diff -u -r1.13 md5.h --- src/sys/sys/md5.h 1999/12/29 04:24:44 1.13 +++ src/sys/sys/md5.h 2001/03/16 19:38:33 @@ -34,6 +34,7 @@ } MD5_CTX; #include +#include __BEGIN_DECLS void MD5Init (MD5_CTX *); @@ -42,6 +43,7 @@ void MD5Final (unsigned char [16], MD5_CTX *); char * MD5End(MD5_CTX *, char *); char * MD5File(const char *, char *); +char * MD5Chunk(const char *, char *, off_t, off_t); char * MD5Data(const unsigned char *, unsigned int, char *); #ifdef _KERNEL void MD5Transform __P((u_int32_t [4], const unsigned char [64])); Index: src/lib/libmd/md2.h =================================================================== RCS file: /home/ncvs/src/lib/libmd/md2.h,v retrieving revision 1.8 diff -u -r1.8 md2.h --- src/lib/libmd/md2.h 1999/08/28 00:05:04 1.8 +++ src/lib/libmd/md2.h 2001/03/16 19:38:33 @@ -31,6 +31,7 @@ } MD2_CTX; #include +#include __BEGIN_DECLS void MD2Init(MD2_CTX *); @@ -39,6 +40,7 @@ void MD2Final(unsigned char [16], MD2_CTX *); char * MD2End(MD2_CTX *, char *); char * MD2File(const char *, char *); +char * MD2Chunk(const char *, char *, off_t, off_t); char * MD2Data(const unsigned char *, unsigned int, char *); __END_DECLS Index: src/lib/libmd/md4.h =================================================================== RCS file: /home/ncvs/src/lib/libmd/md4.h,v retrieving revision 1.9 diff -u -r1.9 md4.h --- src/lib/libmd/md4.h 1999/08/28 00:05:05 1.9 +++ src/lib/libmd/md4.h 2001/03/16 19:38:33 @@ -33,6 +33,7 @@ } MD4_CTX; #include +#include __BEGIN_DECLS void MD4Init(MD4_CTX *); @@ -41,6 +42,7 @@ void MD4Final(unsigned char [16], MD4_CTX *); char * MD4End(MD4_CTX *, char *); char * MD4File(const char *, char *); +char * MD4Chunk(const char *, char *, off_t, off_t); char * MD4Data(const unsigned char *, unsigned int, char *); __END_DECLS Index: src/lib/libmd/mdX.3 =================================================================== RCS file: /home/ncvs/src/lib/libmd/mdX.3,v retrieving revision 1.18 diff -u -r1.18 mdX.3 --- src/lib/libmd/mdX.3 2000/12/14 11:45:18 1.18 +++ src/lib/libmd/mdX.3 2001/03/16 19:38:33 @@ -18,6 +18,7 @@ .Nm MDXFinal , .Nm MDXEnd , .Nm MDXFile , +.Nm MDXChunk , .Nm MDXData .Nd calculate the RSA Data Security, Inc., ``MDX'' message digest .Sh LIBRARY @@ -38,6 +39,8 @@ .Ft "char *" .Fn MDXFile "const char *filename" "char *buf" .Ft "char *" +.Fn MDXChunk "const char *filename" "char *buf" "off_t offset" "off_t length" +.Ft "char *" .Fn MDXData "const unsigned char *data" "unsigned int len" "char *buf" .Sh DESCRIPTION The MDX functions calculate a 128-bit cryptographic checksum (digest) @@ -88,6 +91,23 @@ .Fn MDXEnd to return the result. If the file cannot be opened, a null pointer is returned. +.Fn MDXChunk +is similar to +.Fn MDXFile , +but it only calculates the digest over a byte-range of the file specified, +starting at +.Ar offset +and spanning +.Ar length +bytes. +If the +.Ar length +parameter is specified as 0, or more than the length of the remaining part +of the file, +.Fn MDXChunk +calculates the digest from +.Ar offset +to the end of file. .Fn MDXData calculates the digest of a chunk of data in memory, and uses .Fn MDXEnd Index: src/lib/libmd/mdXhl.c =================================================================== RCS file: /home/ncvs/src/lib/libmd/mdXhl.c,v retrieving revision 1.13 diff -u -r1.13 mdXhl.c --- src/lib/libmd/mdXhl.c 1999/08/28 00:05:07 1.13 +++ src/lib/libmd/mdXhl.c 2001/03/16 19:38:33 @@ -11,6 +11,7 @@ */ #include +#include #include #include @@ -53,6 +54,41 @@ while ((i = read(f,buffer,sizeof buffer)) > 0) { MDXUpdate(&ctx,buffer,i); } + j = errno; + close(f); + errno = j; + if (i < 0) return 0; + return MDXEnd(&ctx, buf); +} + +char * +MDXChunk(const char *filename, char *buf, off_t ofs, off_t len) +{ + unsigned char buffer[BUFSIZ]; + MDX_CTX ctx; + struct stat stbuf; + int f, i, j; + off_t n; + + MDXInit(&ctx); + f = open(filename, O_RDONLY); + if (f < 0) return 0; + if (fstat(f, &stbuf) < 0) return 0; + if (ofs > stbuf.st_size) + ofs = stbuf.st_size; + if ((len == 0) || (len > stbuf.st_size - ofs)) + len = stbuf.st_size - ofs; + if (lseek(f, ofs, SEEK_SET) < 0) return 0; + n = len; + while (n > 0) { + if (n > sizeof(buffer)) + i = read(f, buffer, sizeof(buffer)); + else + i = read(f, buffer, n); + if (i < 0) break; + MDXUpdate(&ctx, buffer, i); + n -= i; + } j = errno; close(f); errno = j; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 11:56:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 6193037B718; Fri, 16 Mar 2001 11:56:15 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id MAA21430; Fri, 16 Mar 2001 12:41:13 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp04.primenet.com, id smtpdAAAaraaOP; Fri Mar 16 12:40:58 2001 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id MAA16289; Fri, 16 Mar 2001 12:46:53 -0700 (MST) From: Terry Lambert Message-Id: <200103161946.MAA16289@usr02.primenet.com> Subject: Re: NO MORE '-BETA' To: drosih@rpi.edu (Garance A Drosihn) Date: Fri, 16 Mar 2001 19:46:48 +0000 (GMT) Cc: jkh@osd.bsdi.com (Jordan Hubbard), bright@wintelcom.net, arch@FreeBSD.ORG, jkh@FreeBSD.ORG In-Reply-To: from "Garance A Drosihn" at Mar 16, 2001 01:14:37 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I've only been following freebsd for two or three years, but every > single time freebsd starts ramping up for a release I see some newbie > freebsd users come on "lily" (our equivalent of IRC) and say > "Hey, I meant to get N.x-stable, but I got N.x+1-beta!! > What did I do wrong? How do I back out?" > > It only takes a few minutes to calm them down and say "that's > just the way freebsd does things, don't worry about it", but it > does happen (with different people, of course) for every release > that I've seen. > > How about calling it: > 4.3-pre-release > > When we then create a new branch after the release (the "super > stable, critical bug-fixes only" branch), we can call that > 4.3-post-release -stable -release -stable-rc (stable, release candidate) The people with the problems may wonder about the "-rc" suffix, but with "stable" there as a prefix, they will probably ignore it, after wondering for a second whether it's the initials of the last person to commit changes or something... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 11:57:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id EFEF737B71C for ; Fri, 16 Mar 2001 11:57:46 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id MAA95652; Fri, 16 Mar 2001 12:57:31 -0700 Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp10.phx.gblx.net, id smtpdbz5Aya; Fri Mar 16 12:57:30 2001 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id MAA16801; Fri, 16 Mar 2001 12:57:43 -0700 (MST) From: Terry Lambert Message-Id: <200103161957.MAA16801@usr02.primenet.com> Subject: Re: idle wonderings about 'struct pcred' To: crossd@cs.rpi.edu (David E. Cross) Date: Fri, 16 Mar 2001 19:57:38 +0000 (GMT) Cc: freebsd-arch@FreeBSD.ORG In-Reply-To: <200103161910.OAA81258@cs.rpi.edu> from "David E. Cross" at Mar 16, 2001 02:10:55 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > What I had in mind would be something like the following: > > struct pcred { > enum p_type; > void *p_data; > struct pcred *next; > }; > > (That is a _very_ rough idea). > > Our current, traditional, 'struct pcred' would become 'pcred_unix', with > a p_type of 0 (#define-d to PCRED_TYPE_UNIX) and would be stuffed into the > p_data pointer). > > What do people think? Good idea. I have been pushing for something like this for years. It would let you "preauthenticate" (ala a "password cache" on login, or an explicit "add credential for XXX" program) for things like per user authentication for an SMB or Appletalk client, on a per user basis (most SMBFS implementations are useless, because they do not offer per user security, unless you are using a single user client OS like Windows). The next neat step would be a "session manager", which would sit on an fd listening for "new credential needed" requests from the kernel, and interrogating the user. For example, you could have a KDE program that sat there and waited, and when the user tried to access a password protected file, a network share, /dev/io, the CDROM, tape backup unit, mount an FS as someone other than root, or whatever, it could pop up a dialog and say: ,---------------------------------. | sessiond | |---------------------------------| | | | Restricted access file: foo.txt | | | | Password: [ ] | | | | < OK > < HELP > | | | `---------------------------------' Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 12: 2: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 3BD2F37B719 for ; Fri, 16 Mar 2001 12:01:58 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id MAA16834; Fri, 16 Mar 2001 12:57:17 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpdAAA5sa4XG; Fri Mar 16 12:57:05 2001 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id NAA16923; Fri, 16 Mar 2001 13:00:22 -0700 (MST) From: Terry Lambert Message-Id: <200103162000.NAA16923@usr02.primenet.com> Subject: Re: add MD5Chunk(filename, .., offset, length) to libmd To: roam@orbitel.bg (Peter Pentchev) Date: Fri, 16 Mar 2001 20:00:17 +0000 (GMT) Cc: phk@critter.freebsd.dk (Poul-Henning Kamp), arch@FreeBSD.ORG In-Reply-To: <20010316214310.A8968@ringworld.oblivion.bg> from "Peter Pentchev" at Mar 16, 2001 09:43:10 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > >As phk pointed out in the SITE MD5 thread, it is sometimes useful > > >to compute the MD5 hash over a range of a file. I agree this is trivial > > >to implement, but why not have it in our standard toolbox? > > > > If you include manpage patches I'll commit it. > > Thanks! :) Please implement the "File" version as a special case of "Chunk", instead of duplicating all that code. I realize that it's unlikely that these algorithms will ever change, causing the code to get out of sync, but duplicate code is generally a bad idea. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 12: 2:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id A721137B718; Fri, 16 Mar 2001 12:02:24 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f2GK2ON72390; Fri, 16 Mar 2001 12:02:24 -0800 (PST) (envelope-from dillon) Date: Fri, 16 Mar 2001 12:02:24 -0800 (PST) From: Matt Dillon Message-Id: <200103162002.f2GK2ON72390@earth.backplane.com> To: John Baldwin Cc: arch@FreeBSD.org Subject: Re: Proposal for the CPU interrupt API References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :And if you would actually read all of the post and keep up to date with the :code so that you weren't telling us to do what we are already doing it would be :more helpful, too. Honestly, Matt, you're sort of reminding me of Terry here. : :> -Matt : : :John Baldwin -- http://www.FreeBSD.org/~jhb/ Again, my only issue here is documentation. *You* and the other people *currently* working on SMPng might know how it works, but take a good hard look at the actual documentation in the source code. There is none. Zilch. Zero. Not one single line describing the API anywhere. I don't see any comments near the function source, I don't see any man-9 pages. Nothing. So how do you expect people coming onto the project to know how to use these functions? Do they have to learn the hard way, by coding it wrong, breaking the tree, and then being told what it is? Do they have to guess? Compare that against, say, the documentation of the VM system that I started working on two years ago. Look at vm_page_insert(), for example. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 12: 9:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id EDA3337B71A for ; Fri, 16 Mar 2001 12:09:10 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f2GK97o21627; Fri, 16 Mar 2001 12:09:07 -0800 (PST) Date: Fri, 16 Mar 2001 12:09:07 -0800 From: Alfred Perlstein To: Terry Lambert Cc: Garance A Drosihn , Jordan Hubbard , arch@FreeBSD.ORG Subject: Re: NO MORE '-BETA' Message-ID: <20010316120906.D29888@fw.wintelcom.net> References: <200103161946.MAA16289@usr02.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103161946.MAA16289@usr02.primenet.com>; from tlambert@primenet.com on Fri, Mar 16, 2001 at 07:46:48PM +0000 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG My main objection is to the newvers.sh change that happens right before the next -release, anyhow here's some suggestions: * Terry Lambert [010316 11:57] wrote: > > I've only been following freebsd for two or three years, but every > > single time freebsd starts ramping up for a release I see some newbie > > freebsd users come on "lily" (our equivalent of IRC) and say > > "Hey, I meant to get N.x-stable, but I got N.x+1-beta!! > > What did I do wrong? How do I back out?" > > > > It only takes a few minutes to calm them down and say "that's > > just the way freebsd does things, don't worry about it", but it > > does happen (with different people, of course) for every release > > that I've seen. > > > > How about calling it: > > 4.3-pre-release > > > > When we then create a new branch after the release (the "super > > stable, critical bug-fixes only" branch), we can call that > > 4.3-post-release > > > -stable > -release > -stable-rc (stable, release candidate) > > The people with the problems may wonder about the "-rc" suffix, > but with "stable" there as a prefix, they will probably ignore > it, after wondering for a second whether it's the initials of > the last person to commit changes or something... Yes, people are used to seeing something like: Linux-2.2.3232.2.2-STABLE+alc+spiff ^^^^^^ On Fri, Mar 16, 2001 at 09:16:02AM -0800, Jordan Hubbard wrote: > > Well, there are two different things here though: > > 1. The usage of "BETA" to denote some pre-release collection of bits > on an FTP site. > > 2. The usage of BETA in newvers.sh > > I think it's #2 which is actually causing all the problems here and I > would happily forgo changing newvers.sh until it's time for the actual > release. I don't usually mark it BETA myself, but one of my helpers > here jumped the gun this time. :) Yes, the real problem with this is '2' (newvers.sh), there's nothing wrong with using 'BETA' in the names on the ftp site. So either quit doing '2' or use a variant of Terry's suggestion '-stable-rc' ~ % uname -srm FreeBSD 4.3-STABLE-RC i386 Would be a lot less scary than -BETA. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 12:10:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id CC36037B71C; Fri, 16 Mar 2001 12:10:19 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f2GKA9n21686; Fri, 16 Mar 2001 12:10:09 -0800 (PST) Date: Fri, 16 Mar 2001 12:10:09 -0800 From: Alfred Perlstein To: Terry Lambert Cc: Matthew Jacob , Benno Rice , Doug Rabson , John Baldwin , arch@FreeBSD.ORG Subject: Re: Proposal for the CPU interrupt API Message-ID: <20010316121009.E29888@fw.wintelcom.net> References: <20010316073921.W29888@fw.wintelcom.net> <200103161937.MAA16182@usr02.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103161937.MAA16182@usr02.primenet.com>; from tlambert@primenet.com on Fri, Mar 16, 2001 at 07:37:53PM +0000 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Terry Lambert [010316 11:38] wrote: > > I've heard that page faults in the AIX kernel are "ok" (obviously > > not when holding a mutex) because some of the kernel memory is > > actually pageable. > > Yes. > > > > Any idea on what structures they keep in pageable memory? > > > > (just wondering) > > AIX can swap anything in a segment marked "pageable", which > include most of the kernel not in the paging path. > > So can Windows 95, 98, CE, ME, NT... Once we quit relying on mutual exclusion we'll have a lot more places where we may be able to do this. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 12:12:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 8847F37B718; Fri, 16 Mar 2001 12:12:55 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f2GKCtk21795; Fri, 16 Mar 2001 12:12:55 -0800 (PST) Date: Fri, 16 Mar 2001 12:12:55 -0800 From: Alfred Perlstein To: Matt Dillon Cc: John Baldwin , arch@FreeBSD.ORG Subject: Re: Proposal for the CPU interrupt API Message-ID: <20010316121254.F29888@fw.wintelcom.net> References: <200103162002.f2GK2ON72390@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103162002.f2GK2ON72390@earth.backplane.com>; from dillon@earth.backplane.com on Fri, Mar 16, 2001 at 12:02:24PM -0800 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Matt Dillon [010316 12:02] wrote: > :And if you would actually read all of the post and keep up to date with the > :code so that you weren't telling us to do what we are already doing it would be > :more helpful, too. Honestly, Matt, you're sort of reminding me of Terry here. > : > :> -Matt > : > : > :John Baldwin -- http://www.FreeBSD.org/~jhb/ > > Again, my only issue here is documentation. *You* and the other people > *currently* working on SMPng might know how it works, but take a good > hard look at the actual documentation in the source code. There is none. > Zilch. Zero. Not one single line describing the API anywhere. I don't > see any comments near the function source, I don't see any man-9 pages. > Nothing. > > So how do you expect people coming onto the project to know how to use > these functions? Do they have to learn the hard way, by coding it wrong, > breaking the tree, and then being told what it is? Do they have to guess? > > Compare that against, say, the documentation of the VM system that I > started working on two years ago. Look at vm_page_insert(), for example. Whoa there Matt... just as you told people to check the CVS logs for your contributions, you should have done the same for John. John has committed or been involved with committing major amounts of docco for the smpng APIs as well misc other stuff like the scheduler and header files. Everyone *breath* for a second, k? :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 12:20: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 0FBDE37B718; Fri, 16 Mar 2001 12:20:02 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f2GKJt372869; Fri, 16 Mar 2001 12:19:55 -0800 (PST) (envelope-from dillon) Date: Fri, 16 Mar 2001 12:19:55 -0800 (PST) From: Matt Dillon Message-Id: <200103162019.f2GKJt372869@earth.backplane.com> To: Alfred Perlstein Cc: John Baldwin , arch@FreeBSD.ORG Subject: Re: Proposal for the CPU interrupt API References: <200103162002.f2GK2ON72390@earth.backplane.com> <20010316121254.F29888@fw.wintelcom.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Whoa there Matt... just as you told people to check the CVS logs for :your contributions, you should have done the same for John. : :John has committed or been involved with committing major amounts of :docco for the smpng APIs as well misc other stuff like the scheduler :and header files. : :Everyone *breath* for a second, k? :) : :-- :-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] That's great! Here's another one to document :-) Or if you don't mind I'd be happy to commit an update that adds appropriate comments. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 12:20:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 83DB937B71A; Fri, 16 Mar 2001 12:20:17 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2GKJUG61815; Fri, 16 Mar 2001 12:19:30 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200103161747.JAA54015@gndrsh.dnsmgr.net> Date: Fri, 16 Mar 2001 12:19:41 -0800 (PST) From: John Baldwin To: "Rodney W. Grimes" Subject: Re: NO MORE '-BETA' Cc: jkh@FreeBSD.org, arch@FreeBSD.org, bright@wintelcom.net, sgk@troutmask.apl.washington.edu, (Jordan Hubbard) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 16-Mar-01 Rodney W. Grimes wrote: >> > Drop by the newsgroup. There was a thread last week about >> > someone using cvsup expecting to get 4.2-stable and he got >> > 4.3-beta. He was annoyed and confused because he thought >> > beta meant "beta quality" (as in inferior software). >> >> Well, there are two different things here though: >> >> 1. The usage of "BETA" to denote some pre-release collection of bits >> on an FTP site. >> >> 2. The usage of BETA in newvers.sh >> >> I think it's #2 which is actually causing all the problems here and I >> would happily forgo changing newvers.sh until it's time for the actual >> release. I don't usually mark it BETA myself, but one of my helpers >> here jumped the gun this time. :) > > As the implementor of this part of newvers.sh I would have to say that > the use of BRANCH has been heavly overloaded by the release engineers > (including myself) to indicated points on a BRANCH. > > One thing that I probably did differently was that the points on a > branch were usually never committed, I simply edited the copy in my > build tree, built the -ALPHA, -BETA, whatever, and put the bits up. > > If anything I would like to see this changed to be more in line with > that. Perhaps commit the -BETA, then immediately commit it back to > -STABLE so we can use these commit dates in a cvs co -d to get the > same tree that release engineering used to build the release, but > those cvsuping are very very unlikely to see a -BETA version. > > You have to change both the version and the branch up and back down, > not so sure I feel good about that :-(. Actually, the main reason for the bump is for the port builds, since we also bump the BASE when we go to beta. This allows time to fix ports with broken configure scripts that die on the new version number. We will always need this, and calling it 4.3-STABLE prior to 4.3-RELEASE is rather bogus I think. Calling it a RC when it's not release quality yet is bogus, too. BETA is the proper term it just seems that some of our users' minds are poisoned. Also, for what its worth, 4.3-BETA is a beta OS, it's not the final product yet. Anyone running -stable already knows that it involves some minimal risk that is not present in -release. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - 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 Fri Mar 16 12:22:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 5710037B718 for ; Fri, 16 Mar 2001 12:22:21 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2GKLfG61881; Fri, 16 Mar 2001 12:21:41 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200103162002.f2GK2ON72390@earth.backplane.com> Date: Fri, 16 Mar 2001 12:21:52 -0800 (PST) From: John Baldwin To: Matt Dillon Subject: Re: Proposal for the CPU interrupt API Cc: arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 16-Mar-01 Matt Dillon wrote: >:And if you would actually read all of the post and keep up to date with the >:code so that you weren't telling us to do what we are already doing it would >:be >:more helpful, too. Honestly, Matt, you're sort of reminding me of Terry >:here. >: >:> -Matt >: >: >:John Baldwin -- http://www.FreeBSD.org/~jhb/ > > Again, my only issue here is documentation. *You* and the other people > *currently* working on SMPng might know how it works, but take a good > hard look at the actual documentation in the source code. There is none. > Zilch. Zero. Not one single line describing the API anywhere. I don't > see any comments near the function source, I don't see any man-9 pages. > Nothing. Nor was there any before. Nor was any of the scheduler documented before. Nor were software interrupts documented before. I _have_ been adding man pages and documenting things. I have no problem with adding a new intr.9 manpage. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - 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 Fri Mar 16 12:27:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 7327937B718 for ; Fri, 16 Mar 2001 12:27:20 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2GKQeG62063; Fri, 16 Mar 2001 12:26:40 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010316120906.D29888@fw.wintelcom.net> Date: Fri, 16 Mar 2001 12:26:51 -0800 (PST) From: John Baldwin To: Alfred Perlstein Subject: Re: NO MORE '-BETA' Cc: arch@FreeBSD.org, Jordan Hubbard , Garance A Drosihn , Terry Lambert Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 16-Mar-01 Alfred Perlstein wrote: > Yes, the real problem with this is '2' (newvers.sh), there's nothing > wrong with using 'BETA' in the names on the ftp site. People who follow -stable should be reading -stable. Thus, they will read the heads up about the release schedule, and will not be surprised. If having -BETA on the ftp site for people who aren't necessarly reading -stable is ok, then it should be more than ok for people who are supposedly reading the list and know what is going on. > So either quit doing '2' or use a variant of > Terry's suggestion '-stable-rc' > > ~ % uname -srm > FreeBSD 4.3-STABLE-RC i386 Except that it's not a real release candidate. Which is why we don't just use -RC the whole time. -RC means that we would actually feel confident releasing that exact source on the CD's as foo-RELEASE. This is not true for foo-BETA, as it is a time for people to test stuff out and spot things that need to be fixed. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - 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 Fri Mar 16 12:35:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id B9EF637B718; Fri, 16 Mar 2001 12:35:47 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f2GKZkZ73579; Fri, 16 Mar 2001 12:35:46 -0800 (PST) (envelope-from dillon) Date: Fri, 16 Mar 2001 12:35:46 -0800 (PST) From: Matt Dillon Message-Id: <200103162035.f2GKZkZ73579@earth.backplane.com> To: John Baldwin Cc: arch@FreeBSD.org Subject: Re: Proposal for the CPU interrupt API References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Just to be clear. I am not advocating that everyone drop everything and start writing man pages... man pages take a lot of effort. But I would recommend that the procedures in the source code itself be documented in comments above each procedure whenever you have the chance and some time. That is ultimately the best way to document kernel interfaces, because it doesn't result in the documentation becoming outdated (whereas manual pages, while great and all that, tend to become outdated especially when things are changing quickly). The best examples of this sort of documentation in our current kernel is in vm/vm_page.h, vm/vm_page.c, and vm/vm_object.c. Alan, Alfred, I, DG, and others have had very good success keeping our understanding of the various functions in-sync and not stepping on each other's feet by keeping the documentation of the procedures up to date. kern/vfs_bio.c also is a good example of procedural documentation. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 12:37:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id 2FC7237B718 for ; Fri, 16 Mar 2001 12:37:25 -0800 (PST) (envelope-from roam@orbitel.bg) Received: (qmail 15151 invoked by uid 1000); 16 Mar 2001 20:36:41 -0000 Date: Fri, 16 Mar 2001 22:36:41 +0200 From: Peter Pentchev To: Terry Lambert Cc: Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: add MD5Chunk(filename, .., offset, length) to libmd Message-ID: <20010316223641.D8968@ringworld.oblivion.bg> Mail-Followup-To: Terry Lambert , Poul-Henning Kamp , arch@FreeBSD.ORG References: <20010316214310.A8968@ringworld.oblivion.bg> <200103162000.NAA16923@usr02.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103162000.NAA16923@usr02.primenet.com>; from tlambert@primenet.com on Fri, Mar 16, 2001 at 08:00:17PM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Mar 16, 2001 at 08:00:17PM +0000, Terry Lambert wrote: > > > >As phk pointed out in the SITE MD5 thread, it is sometimes useful > > > >to compute the MD5 hash over a range of a file. I agree this is trivial > > > >to implement, but why not have it in our standard toolbox? > > > > > > If you include manpage patches I'll commit it. > > > > Thanks! :) > > > Please implement the "File" version as a special case of "Chunk", > instead of duplicating all that code. I realize that it's > unlikely that these algorithms will ever change, causing the > code to get out of sync, but duplicate code is generally a bad > idea. Will do; thanks for the (obvious, yet something I missed) idea! G'luck, Peter -- No language can express every thought unambiguously, least of all this one. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 13: 3:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 1880237B718 for ; Fri, 16 Mar 2001 13:03:51 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id NAA11588; Fri, 16 Mar 2001 13:58:09 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp05.primenet.com, id smtpdAAAW_aynu; Fri Mar 16 11:30:52 2001 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id LAA14833; Fri, 16 Mar 2001 11:36:20 -0700 (MST) From: Terry Lambert Message-Id: <200103161836.LAA14833@usr02.primenet.com> Subject: Re: [PATCH] add a SITE MD5 command to ftpd To: dot@dotat.at (Tony Finch) Date: Fri, 16 Mar 2001 18:36:19 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), freebsd-arch@FreeBSD.ORG In-Reply-To: <20010316044655.C385@hand.dotat.at> from "Tony Finch" at Mar 16, 2001 04:46:55 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >The whole idea of HTTP protection like this is pretty inane, since > >we've all already agreed, I think, that it's really only useful > >for mirroring, or for offloading an MD5 calculation from my 800MHz > >Pentium III laptop onto a big, ballsy 66MHz 486 FTP server. > > RFC 2616 section 14.15: > > [...] > The Content-MD5 entity-header field, as defined in RFC 1864 [23], is > an MD5 digest of the entity-body for the purpose of providing an > end-to-end message integrity check (MIC) of the entity-body. (Note: a > MIC is good for detecting accidental modification of the entity-body > in transit, but is not proof against malicious attacks.) > [...] Actually, it would prevent useful modification more often than accidental modification. Accidental modification is nearly impossible; who would do it? The kernel between the time the server writes the bytes, and the TCP stack checksums them? I've suggested twice before that this RFC be updated to indicate that the actual intent of this field is to prevent caches from being efficient and/or doing URL rewriting and/or caching static portions of dynamically generated pages as page elements, without the use of "frames". For example, much as I dislike the fact that they've talked people into their absurd scheme, Akamai would not work very well with this being enforced. Make that three times, now. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 13: 9:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-202.dsl.lsan03.pacbell.net [63.207.60.202]) by hub.freebsd.org (Postfix) with ESMTP id 4C09037B719; Fri, 16 Mar 2001 13:09:18 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id E12E266B25; Fri, 16 Mar 2001 13:09:17 -0800 (PST) Date: Fri, 16 Mar 2001 13:09:17 -0800 From: Kris Kennaway To: Jordan Hubbard Cc: bright@wintelcom.net, cdillon@wolves.k12.mo.us, sgk@troutmask.apl.washington.edu, arch@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: NO MORE '-BETA' Message-ID: <20010316130917.A99286@mollari.cthul.hu> References: <20010315201500.A2484@troutmask.apl.washington.edu> <20010316071040.V29888@fw.wintelcom.net> <20010316104124Z.jkh@osd.bsdi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="pWyiEgJYm5f9v55/" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010316104124Z.jkh@osd.bsdi.com>; from jkh@osd.bsdi.com on Fri, Mar 16, 2001 at 10:41:24AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 16, 2001 at 10:41:24AM -0800, Jordan Hubbard wrote: > > Ok, so we have reports of confusion on the mailing lists, usenet and > > IRC. Jordan, where can I pick up a set those blinders you have on? >=20 > Chill, Albert. I think we've already established that a) It's the > newvers.sh "BETAness" that's really freaking people out and b) That > you've yet to supply any practical name alternative, you're just > whining about it at this point. I suggested "-PRERELEASE" as a more friendly alternative. Kris --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6soAhWry0BWjoQKURAl26AKD0mkU3IXyBmPJDuYJTsR+yAGaIXgCg2rwO rs5a2ow8fHFPNi+r0fPidp8= =EBrA -----END PGP SIGNATURE----- --pWyiEgJYm5f9v55/-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 13:15:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-202.dsl.lsan03.pacbell.net [63.207.60.202]) by hub.freebsd.org (Postfix) with ESMTP id 7B93437B719 for ; Fri, 16 Mar 2001 13:15:24 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 1AA0766B25; Fri, 16 Mar 2001 13:15:24 -0800 (PST) Date: Fri, 16 Mar 2001 13:15:24 -0800 From: Kris Kennaway To: Peter Pentchev Cc: arch@FreeBSD.org Subject: Re: add MD5Chunk(filename, .., offset, length) to libmd Message-ID: <20010316131523.B99286@mollari.cthul.hu> References: <20010316210833.C8245@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="f2QGlHpHGjS2mn6Y" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010316210833.C8245@ringworld.oblivion.bg>; from roam@orbitel.bg on Fri, Mar 16, 2001 at 09:08:33PM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --f2QGlHpHGjS2mn6Y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Mar 16, 2001 at 09:08:33PM +0200, Peter Pentchev wrote: > Attached is a patch to libmd, which adds an MD5Check() function, I'd appreciate it if you could provide a patch against libcrypto as well: libmd is a subset of what libcrypto provides (looks like libmd was actually taken from the OpenSSL code in fact), and at some point in the future I'd like to look at switching it back to the openssl sources, if they're available. The benefits would be things like ASM optimisations for MD5 and SHA1, etc. Kris --f2QGlHpHGjS2mn6Y Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6soJrWry0BWjoQKURAlFDAKCaaJPUSlPLduir4I/b/kWnKFbJmACg2cv5 svmHX2TKJkl5D5i6I9BmmMU= =ndYK -----END PGP SIGNATURE----- --f2QGlHpHGjS2mn6Y-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 13:20:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id CB9D037B718; Fri, 16 Mar 2001 13:20:14 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id NAA54727; Fri, 16 Mar 2001 13:20:06 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200103162120.NAA54727@gndrsh.dnsmgr.net> Subject: Re: Proposal for the CPU interrupt API In-Reply-To: <200103162035.f2GKZkZ73579@earth.backplane.com> from Matt Dillon at "Mar 16, 2001 12:35:46 pm" To: dillon@earth.backplane.com (Matt Dillon) Date: Fri, 16 Mar 2001 13:20:06 -0800 (PST) Cc: jhb@FreeBSD.ORG (John Baldwin), arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Just to be clear. I am not advocating that everyone drop everything > and start writing man pages... man pages take a lot of effort. > But I would recommend that the procedures in the source code itself > be documented in comments above each procedure whenever you have the > chance and some time. That is ultimately the best way to document > kernel interfaces, because it doesn't result in the documentation > becoming outdated (whereas manual pages, while great and all that, > tend to become outdated especially when things are changing quickly). Every committer should be slapped on the hand every time they make a commit that changes source code that does not update the related documentation (man page or otherwise). 5 slapps on the hand and a commit bit should be suspended. Three suspensions and it should be revoked. The excuse that they don't know how to deal with nroff and mandoc is not really acceptable. They can always inlist the help of those that do understand these things, and hold the commit until both parts are ready. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 13:26:36 2001 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 1739937B718 for ; Fri, 16 Mar 2001 13:26:32 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f2GLQP116609; Fri, 16 Mar 2001 22:26:25 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Kris Kennaway Cc: Peter Pentchev , arch@FreeBSD.ORG Subject: Re: add MD5Chunk(filename, .., offset, length) to libmd In-Reply-To: Your message of "Fri, 16 Mar 2001 13:15:24 PST." <20010316131523.B99286@mollari.cthul.hu> Date: Fri, 16 Mar 2001 22:26:25 +0100 Message-ID: <16607.984777985@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010316131523.B99286@mollari.cthul.hu>, Kris Kennaway writes: > >--f2QGlHpHGjS2mn6Y >Content-Type: text/plain; charset=us-ascii >Content-Disposition: inline > >On Fri, Mar 16, 2001 at 09:08:33PM +0200, Peter Pentchev wrote: > >> Attached is a patch to libmd, which adds an MD5Check() function, > >I'd appreciate it if you could provide a patch against libcrypto as >well: libmd is a subset of what libcrypto provides (looks like libmd >was actually taken from the OpenSSL code in fact), EXCUSE ME!!!! I created libmd in july 1994, well before anybody had even heard about much less implemented any kind of SSL... (Exactly the kind of innovative behaviour we don't do here in FreeBSD according to Jordan.) In all likelyhood OpenSSL nicked our libmd... -- 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 Fri Mar 16 13:28:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wolves.k12.mo.us (mail.wolves.k12.mo.us [207.160.214.1]) by hub.freebsd.org (Postfix) with ESMTP id 6E48437B71A; Fri, 16 Mar 2001 13:28:40 -0800 (PST) (envelope-from cdillon@wolves.k12.mo.us) Received: from mail.wolves.k12.mo.us (cdillon@mail.wolves.k12.mo.us [207.160.214.1]) by mail.wolves.k12.mo.us (8.9.3/8.9.3) with ESMTP id PAA26162; Fri, 16 Mar 2001 15:28:29 -0600 (CST) (envelope-from cdillon@wolves.k12.mo.us) Date: Fri, 16 Mar 2001 15:28:28 -0600 (CST) From: Chris Dillon To: Kris Kennaway Cc: Jordan Hubbard , , , , Subject: Re: NO MORE '-BETA' In-Reply-To: <20010316130917.A99286@mollari.cthul.hu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 16 Mar 2001, Kris Kennaway wrote: > On Fri, Mar 16, 2001 at 10:41:24AM -0800, Jordan Hubbard wrote: > > > Ok, so we have reports of confusion on the mailing lists, usenet and > > > IRC. Jordan, where can I pick up a set those blinders you have on? > > > > Chill, Albert. I think we've already established that a) It's the > > newvers.sh "BETAness" that's really freaking people out and b) That > > you've yet to supply any practical name alternative, you're just > > whining about it at this point. > > I suggested "-PRERELEASE" as a more friendly alternative. I suppose we could just keep it X.Y-STABLE right up until newvers.sh is changed and the X.(Y+1)-RELEASE tag is laid down immediately afterwards... Obviously developers and others tracking -STABLE will already know when we're in a "BETA" stage (since they're on the appropriate mailing lists, or should be), others don't really need to be "bothered" with that fact. -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. 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 Fri Mar 16 13:38:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 3BE2F37B719; Fri, 16 Mar 2001 13:38:27 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f2GLc8d74959; Fri, 16 Mar 2001 13:38:08 -0800 (PST) (envelope-from dillon) Date: Fri, 16 Mar 2001 13:38:08 -0800 (PST) From: Matt Dillon Message-Id: <200103162138.f2GLc8d74959@earth.backplane.com> To: "Rodney W. Grimes" Cc: jhb@FreeBSD.ORG (John Baldwin), arch@FreeBSD.ORG Subject: Re: Proposal for the CPU interrupt API References: <200103162120.NAA54727@gndrsh.dnsmgr.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Every committer should be slapped on the hand every time they make a :commit that changes source code that does not update the related :documentation (man page or otherwise). : :5 slapps on the hand and a commit bit should be suspended. Three :suspensions and it should be revoked. : :The excuse that they don't know how to deal with nroff and mandoc is :not really acceptable. They can always inlist the help of those that :do understand these things, and hold the commit until both parts are :ready. : :Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net Well, the problem is that only 1% of the kernel interfaces are documented with man pages. So if you are requiring every single committer working on the kernel to go and check to see if a man 9 section exists for some of the dozens of files they just touched, well, I'm afraid that is a bit over the top. FreeBSD's committers have historically *NOT* done that, so depending on it now is a bad idea. It just won't happen. This isn't to say that man 9 pages are useless... but I would say that they are not as useful in an environment that is changing as quickly as -current is. On the otherhand, documenting the procedures in the source itself is a whole lot easier for the committers to do. It represents a relatively small burden instead of a large one, which means that the source code comments wind up being more up to date and more complete. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 13:40:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 5B16D37B718; Fri, 16 Mar 2001 13:40:14 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2GLcrG64795; Fri, 16 Mar 2001 13:38:53 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 16 Mar 2001 13:39:04 -0800 (PST) From: John Baldwin To: Chris Dillon Subject: Re: NO MORE '-BETA' Cc: jkh@FreeBSD.org, arch@FreeBSD.org, sgk@troutmask.apl.washington.edu, bright@wintelcom.net, Jordan Hubbard , Kris Kennaway Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 16-Mar-01 Chris Dillon wrote: > On Fri, 16 Mar 2001, Kris Kennaway wrote: > >> On Fri, Mar 16, 2001 at 10:41:24AM -0800, Jordan Hubbard wrote: >> > > Ok, so we have reports of confusion on the mailing lists, usenet and >> > > IRC. Jordan, where can I pick up a set those blinders you have on? >> > >> > Chill, Albert. I think we've already established that a) It's the >> > newvers.sh "BETAness" that's really freaking people out and b) That >> > you've yet to supply any practical name alternative, you're just >> > whining about it at this point. >> >> I suggested "-PRERELEASE" as a more friendly alternative. > > I suppose we could just keep it X.Y-STABLE right up until newvers.sh > is changed and the X.(Y+1)-RELEASE tag is laid down immediately > afterwards... Obviously developers and others tracking -STABLE will > already know when we're in a "BETA" stage (since they're on the > appropriate mailing lists, or should be), others don't really need to > be "bothered" with that fact. You missed the need for the Y+1 bump for ports testing prior to release. Doing 4.2-stable -> 4.3-stable -> 4.3-release -> 4.3-stable doesn't make much sense. Next.. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - 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 Fri Mar 16 13:41:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id AC3F237B719; Fri, 16 Mar 2001 13:41:17 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f2GLfDW24567; Fri, 16 Mar 2001 13:41:13 -0800 (PST) Date: Fri, 16 Mar 2001 13:41:13 -0800 From: Alfred Perlstein To: Jim Mock Cc: "Steve O'Hara-Smith" , arch@FreeBSD.ORG, j mckitrick , jkh@FreeBSD.ORG Subject: More BETA evilness Re: BETA induced nervousness Message-ID: <20010316134113.I29888@fw.wintelcom.net> References: <20010316214210.5a3dc591.steveo@eircom.net> <20010316160949.A3791@guinness.osdn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010316160949.A3791@guinness.osdn.com>; from mij@osdn.com on Fri, Mar 16, 2001 at 04:09:49PM -0500 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG (moved to -arch because...) FYI I'm fighting this cause on the -arch list, I've just quoted this message and added cc's to the people who have the authority to fix it. I want to be clear that it's not just me that's irritated by this. My current solution is instead of -BETA have -STABLE-RC, the '-RC' is there to give knowledgeable people a heads-up and the '-STABLE' is prominent enough to reduce the amount of concern. * Jim Mock [010316 13:15] wrote: > On Fri, 16 Mar 2001 at 21:42:10 +0100, Steve O'Hara-Smith wrote: > > Hi, > > > > Picking a recent example: > > > > Saverio Perugini writes: > > > What is a BETA system? Is it similiar to CURRENT? > > > > We get a lot of this sort of thing every time a release rolls, > > an idea crossed my mind, perhaps if during BETA and RC phases > > /etc/motd were to carry a big message like > > > > ---------------------- > > DO NOT PANIC - BETA is a normal phase that STABLE goes through prior > > to the rolling of a release. If anything it is *MORE* stable than > > usual during BETA as all changes are monitered by the release > > engineer. > > ---------------------- > > > > Changing BETA to RC as appropriate. It *might* reduce the > > effect, worth a try ? > > This would be wonderful. It should cut down dramatically on the 3.7 > million "MY FBSD IZ BORKEN CUZ IT SAYZ -BETA N I WANT -STABLE FIX IT NOW > K PLZ THX" (I think I hung out with Alfred too much :-) emails to this > list and -questions. > > Perhaps even pointing something towards the FAQ entry on this would > help. > > The only problem is see doing this is that: > > 1) Not everyone will run mergemaster afterwards. It doesn't matter > whether they should or not, many just won't. > > 2) Not everyone who does run mergemaster will update their /etc/motd > (like me). > > So, the question is.. how can we get something like this to the most > people without printing that section of the FAQ and stapling it to their > foreheads? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 13:42:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail-100baset.rpi.edu [128.113.26.45]) by hub.freebsd.org (Postfix) with ESMTP id 64C9437B71E; Fri, 16 Mar 2001 13:42:43 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id QAA94240; Fri, 16 Mar 2001 16:42:42 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Fri, 16 Mar 2001 16:42:41 -0500 To: John Baldwin , Alfred Perlstein From: Garance A Drosihn Subject: Re: NO MORE '-BETA' Cc: arch@FreeBSD.org, Jordan Hubbard , Terry Lambert Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 12:26 PM -0800 3/16/01, John Baldwin wrote: >On 16-Mar-01 Alfred Perlstein wrote: >> Yes, the real problem with this is '2' (newvers.sh), there's nothing >> wrong with using 'BETA' in the names on the ftp site. > >People who follow -stable should be reading -stable. A lot of people "should" be doing a lot of things. Maybe these users partially follow the -stable mailing list, but happen to ignore any message with '-beta' in the subject because "they know" they are running the -stable branch. As I say, it is only a few people each release, and it never takes more than a few minutes to calm them down, but it DOES happen every release cycle. > > ~ % uname -srm >> FreeBSD 4.3-STABLE-RC i386 > >Except that it's not a real release candidate. Which is why we >don't just use -RC the whole time. I do think the current "beta" period should have some specific name, and one which doesn't imply "release-candidate". I always thought it was odd to be calling it "beta", because (whether we like it or not) "beta" implies something certainly less trustworthy "stable". On the other hand, I still haven't come up with anything more inventive than "4.3-pre-release", or maybe "4.3-pre-rel" (just to be shorter). Maybe something like "4.3-code-freeze"? Or "4.3-precursor"? -- Garance Alistair Drosehn = gad@eclipse.acs.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 Fri Mar 16 13:43:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 1569837B71A; Fri, 16 Mar 2001 13:43:50 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f2GLhne24624; Fri, 16 Mar 2001 13:43:49 -0800 (PST) Date: Fri, 16 Mar 2001 13:43:49 -0800 From: Alfred Perlstein To: John Baldwin Cc: Chris Dillon , jkh@FreeBSD.ORG, arch@FreeBSD.ORG, sgk@troutmask.apl.washington.edu, Jordan Hubbard , Kris Kennaway Subject: Re: NO MORE '-BETA' Message-ID: <20010316134349.K29888@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.ORG on Fri, Mar 16, 2001 at 01:39:04PM -0800 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * John Baldwin [010316 13:40] wrote: > > On 16-Mar-01 Chris Dillon wrote: > > On Fri, 16 Mar 2001, Kris Kennaway wrote: > > > >> On Fri, Mar 16, 2001 at 10:41:24AM -0800, Jordan Hubbard wrote: > >> > > Ok, so we have reports of confusion on the mailing lists, usenet and > >> > > IRC. Jordan, where can I pick up a set those blinders you have on? > >> > > >> > Chill, Albert. I think we've already established that a) It's the > >> > newvers.sh "BETAness" that's really freaking people out and b) That > >> > you've yet to supply any practical name alternative, you're just > >> > whining about it at this point. > >> > >> I suggested "-PRERELEASE" as a more friendly alternative. > > > > I suppose we could just keep it X.Y-STABLE right up until newvers.sh > > is changed and the X.(Y+1)-RELEASE tag is laid down immediately > > afterwards... Obviously developers and others tracking -STABLE will > > already know when we're in a "BETA" stage (since they're on the > > appropriate mailing lists, or should be), others don't really need to > > be "bothered" with that fact. > > You missed the need for the Y+1 bump for ports testing prior to release. > Doing 4.2-stable -> 4.3-stable -> 4.3-release -> 4.3-stable doesn't make much > sense. Next.. He's saying 4.2-stable -> 4.3-release -> 4.3-stable -> 4.4 release ... Which makes sense. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 13:58:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id A3ED837B71A; Fri, 16 Mar 2001 13:58:25 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id IAA11695; Sat, 17 Mar 2001 08:58:22 +1100 Date: Sat, 17 Mar 2001 08:58:06 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: John Baldwin Cc: arch@FreeBSD.org Subject: Re: Proposal for the CPU interrupt API In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 16 Mar 2001, John Baldwin wrote: > On 16-Mar-01 Bruce Evans wrote: > > On Thu, 15 Mar 2001, John Baldwin wrote: > >> ... Thus, I'm proposing to change > >> disable/enable_intr to return the previous state in addition to setting > >> the state. > > > > This would be a minor pessimization on i386's. WHether it is an optimization > > or a pessimization is very MD. It would be a major pessimization on i386's > > with ICUs if we put the entire interrupt state including the ICU masks in > > the interrrupt state. > > I don't think this needs to go near the ICU state, but yes, it is a minor > pessimization on i386. But on some machines it might need to go near something expensive like the ICU state. > >> This then removes the need for save_intr(), and > >> restore_intr() can stay the same. > > > > This doesn't remove the need for save_intr(). I use it in at least one > > place (perhaps only one :-) where I don't want to disable interrupts any > > more than they already are. > > If it is just the CPU status, then just intr_disable() (or disable_intr()) > will accomplish this. I don't use disable_intr() since it has the unwanted side (actually main) effect of disabling interrupts. > > It's really a mistake to let this stuff escape from MD code. Frotunately, > > it hasn't escaped far yet. > > The only somewhat MI place it is used is in the bowels of the mutex code. Any > MI code that wishes to prevent preemption should use a spinlock instead of > disabling interrupts manually now. It is also used in (non-broken) drivers that use fast interrupt handlers. The broken sio and cy drivers in -current assume that spinlocks disable all interrupts (on the current CPU). This will be fixed. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 14: 0:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 8B2C237B719 for ; Fri, 16 Mar 2001 14:00:24 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2GLxPG65604; Fri, 16 Mar 2001 13:59:25 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 16 Mar 2001 13:59:36 -0800 (PST) From: John Baldwin To: Garance A Drosihn Subject: Re: NO MORE '-BETA' Cc: Terry Lambert , Jordan Hubbard , arch@FreeBSD.org, Alfred Perlstein Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 16-Mar-01 Garance A Drosihn wrote: > At 12:26 PM -0800 3/16/01, John Baldwin wrote: >>On 16-Mar-01 Alfred Perlstein wrote: >>> Yes, the real problem with this is '2' (newvers.sh), there's nothing >>> wrong with using 'BETA' in the names on the ftp site. >> >>People who follow -stable should be reading -stable. > > A lot of people "should" be doing a lot of things. Maybe these users > partially follow the -stable mailing list, but happen to ignore any > message with '-beta' in the subject because "they know" they are > running the -stable branch. As I say, it is only a few people each > release, and it never takes more than a few minutes to calm them down, > but it DOES happen every release cycle. Is this in the FAQ yet? If we documented our release engineering process and put it on the website, that would eliminate most of this confusion. :) I've somewhat attempted to do this but can't seem to get the release engineer to look at it. :-P >> > ~ % uname -srm >>> FreeBSD 4.3-STABLE-RC i386 >> >>Except that it's not a real release candidate. Which is why we >>don't just use -RC the whole time. > > I do think the current "beta" period should have some specific > name, and one which doesn't imply "release-candidate". I always > thought it was odd to be calling it "beta", because (whether we > like it or not) "beta" implies something certainly less trustworthy > "stable". Actually, with the MFC spree that usually happens before a release, it is potentially less stable than before. How many times has -stable had a broken world in the 3 months between -BETA and 4.2-release, and how many times has it been broken in the last few weeks? I rest my case.. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - 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 Fri Mar 16 14: 1:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 13FB137B718; Fri, 16 Mar 2001 14:01:41 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2GM0pG65680; Fri, 16 Mar 2001 14:00:51 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010316134349.K29888@fw.wintelcom.net> Date: Fri, 16 Mar 2001 14:01:03 -0800 (PST) From: John Baldwin To: Alfred Perlstein Subject: Re: NO MORE '-BETA' Cc: Kris Kennaway , Jordan Hubbard , sgk@troutmask.apl.washington.edu, arch@FreeBSD.org, jkh@FreeBSD.org, Chris Dillon Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 16-Mar-01 Alfred Perlstein wrote: > * John Baldwin [010316 13:40] wrote: >> >> On 16-Mar-01 Chris Dillon wrote: >> > On Fri, 16 Mar 2001, Kris Kennaway wrote: >> > >> >> On Fri, Mar 16, 2001 at 10:41:24AM -0800, Jordan Hubbard wrote: >> >> > > Ok, so we have reports of confusion on the mailing lists, usenet and >> >> > > IRC. Jordan, where can I pick up a set those blinders you have on? >> >> > >> >> > Chill, Albert. I think we've already established that a) It's the >> >> > newvers.sh "BETAness" that's really freaking people out and b) That >> >> > you've yet to supply any practical name alternative, you're just >> >> > whining about it at this point. >> >> >> >> I suggested "-PRERELEASE" as a more friendly alternative. >> > >> > I suppose we could just keep it X.Y-STABLE right up until newvers.sh >> > is changed and the X.(Y+1)-RELEASE tag is laid down immediately >> > afterwards... Obviously developers and others tracking -STABLE will >> > already know when we're in a "BETA" stage (since they're on the >> > appropriate mailing lists, or should be), others don't really need to >> > be "bothered" with that fact. >> >> You missed the need for the Y+1 bump for ports testing prior to release. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> Doing 4.2-stable -> 4.3-stable -> 4.3-release -> 4.3-stable doesn't make >> much >> sense. Next.. > > He's saying 4.2-stable -> 4.3-release -> 4.3-stable -> 4.4 release ... > > Which makes sense. ... which breaks all the ports testing since you missed the Y+1 bump prior to release. I've underlined it for you this time. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - 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 Fri Mar 16 14: 4:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id A7A3937B71A; Fri, 16 Mar 2001 14:04:08 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f2GM48S25378; Fri, 16 Mar 2001 14:04:08 -0800 (PST) Date: Fri, 16 Mar 2001 14:04:08 -0800 From: Alfred Perlstein To: John Baldwin Cc: Garance A Drosihn , Terry Lambert , Jordan Hubbard , arch@FreeBSD.org Subject: Re: NO MORE '-BETA' Message-ID: <20010316140408.N29888@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Fri, Mar 16, 2001 at 01:59:36PM -0800 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * John Baldwin [010316 14:00] wrote: re -BETA > > Actually, with the MFC spree that usually happens before a release, it is > potentially less stable than before. How many times has -stable had a broken > world in the 3 months between -BETA and 4.2-release, and how many times has it > been broken in the last few weeks? I rest my case.. The point is that I don't know how one detects that you're about to be nailed by this supposedly less 'stable' version of '-stable' until you reboot after installing the new world/kernel. Let's just add something to cvsup to prompt the user? Or something in the build process that's interactive? or what? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 14: 6: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peitho.fxp.org (peitho.fxp.org [209.26.95.40]) by hub.freebsd.org (Postfix) with ESMTP id 6C6FE37B719; Fri, 16 Mar 2001 14:05:53 -0800 (PST) (envelope-from cdf.lists@fxp.org) Received: by peitho.fxp.org (Postfix, from userid 1501) id 29C121360C; Fri, 16 Mar 2001 17:05:52 -0500 (EST) Date: Fri, 16 Mar 2001 17:05:52 -0500 From: Chris Faulhaber To: John Baldwin Cc: arch@FreeBSD.org, Alfred Perlstein Subject: Re: NO MORE '-BETA' Message-ID: <20010316170551.A3379@peitho.fxp.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Fri, Mar 16, 2001 at 01:59:36PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 16, 2001 at 01:59:36PM -0800, John Baldwin wrote: >=20 > On 16-Mar-01 Garance A Drosihn wrote: > > At 12:26 PM -0800 3/16/01, John Baldwin wrote: > >>On 16-Mar-01 Alfred Perlstein wrote: > >>> Yes, the real problem with this is '2' (newvers.sh), there's nothing > >>> wrong with using 'BETA' in the names on the ftp site. > >> > >>People who follow -stable should be reading -stable. > >=20 > > A lot of people "should" be doing a lot of things. Maybe these users > > partially follow the -stable mailing list, but happen to ignore any > > message with '-beta' in the subject because "they know" they are > > running the -stable branch. As I say, it is only a few people each > > release, and it never takes more than a few minutes to calm them down, > > but it DOES happen every release cycle. >=20 > Is this in the FAQ yet? If we documented our release engineering process= and > put it on the website, that would eliminate most of this confusion. :) I= 've > somewhat attempted to do this but can't seem to get the release engineer = to > look at it. :-P > =20 http://www.FreeBSD.org/FAQ/admin.html#RELEASE-CANDIDATE --=20 Chris D. Faulhaber - jedgar@fxp.org - jedgar@FreeBSD.org -------------------------------------------------------- FreeBSD: The Power To Serve - http://www.FreeBSD.org --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: FreeBSD: The Power To Serve iEYEARECAAYFAjqyjj8ACgkQObaG4P6BelDrjQCfT13V9QM2TYNI21uvCAc1vVCj BjsAmQEehToYawsUI2oDswNhuHApf5sh =MtDw -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 14: 8:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wolves.k12.mo.us (mail.wolves.k12.mo.us [207.160.214.1]) by hub.freebsd.org (Postfix) with ESMTP id 6311B37B719; Fri, 16 Mar 2001 14:08:48 -0800 (PST) (envelope-from cdillon@wolves.k12.mo.us) Received: from mail.wolves.k12.mo.us (cdillon@mail.wolves.k12.mo.us [207.160.214.1]) by mail.wolves.k12.mo.us (8.9.3/8.9.3) with ESMTP id QAA26884; Fri, 16 Mar 2001 16:08:41 -0600 (CST) (envelope-from cdillon@wolves.k12.mo.us) Date: Fri, 16 Mar 2001 16:08:41 -0600 (CST) From: Chris Dillon To: Alfred Perlstein Cc: Jim Mock , "Steve O'Hara-Smith" , , j mckitrick , Subject: Re: More BETA evilness Re: BETA induced nervousness In-Reply-To: <20010316134113.I29888@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 16 Mar 2001, Alfred Perlstein wrote: > (moved to -arch because...) > > FYI I'm fighting this cause on the -arch list, I've just quoted > this message and added cc's to the people who have the authority > to fix it. > > I want to be clear that it's not just me that's irritated by this. > > My current solution is instead of -BETA have -STABLE-RC, the > '-RC' is there to give knowledgeable people a heads-up and > the '-STABLE' is prominent enough to reduce the amount of > concern. That would probably lead to some amount of confusion as well, since the combination of "4.3" and "STABLE" anywhere would seem to indicate a post-4.3-RELEASE state (hence 4.3-STABLE), while we are actually talking about a pre-release state. If it were 4.2-STABLE-RC, that would make sense, but then you don't have the version number bump that is needed to test ports, as was pointed out. Maybe "4.3-ALMOST-THERE" or "4.3-NOT-QUITE"? :-) -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. 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 Fri Mar 16 14:10:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id D50D337B718 for ; Fri, 16 Mar 2001 14:10:37 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2GM9uG66054; Fri, 16 Mar 2001 14:09:56 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010316140408.N29888@fw.wintelcom.net> Date: Fri, 16 Mar 2001 14:10:08 -0800 (PST) From: John Baldwin To: Alfred Perlstein Subject: Re: NO MORE '-BETA' Cc: arch@FreeBSD.org, Jordan Hubbard , Terry Lambert , Garance A Drosihn Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 16-Mar-01 Alfred Perlstein wrote: > * John Baldwin [010316 14:00] wrote: > > re -BETA > >> >> Actually, with the MFC spree that usually happens before a release, it is >> potentially less stable than before. How many times has -stable had a >> broken >> world in the 3 months between -BETA and 4.2-release, and how many times has >> it >> been broken in the last few weeks? I rest my case.. > > The point is that I don't know how one detects that you're about to > be nailed by this supposedly less 'stable' version of '-stable' until > you reboot after installing the new world/kernel. > > Let's just add something to cvsup to prompt the user? Or something > in the build process that's interactive? or what? Do we do any of these things when you cvsup -current on a -stable machine? No. Instead, we talk about what -stable and -current are in our documentation. The same method should be used here. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - 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 Fri Mar 16 14:22:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 8065737B718; Fri, 16 Mar 2001 14:22:00 -0800 (PST) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id OAA24494; Fri, 16 Mar 2001 14:22:02 -0800 Date: Fri, 16 Mar 2001 14:21:58 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Baldwin Cc: arch@FreeBSD.ORG Subject: man pages In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Actually, I think you only need disable_intr && restore_intr, which should be paired over tight MD code sections, and yes, leaving it ambigious is desirable IMO. .\" -*- nroff -*- .\" .\" Copyright (c) 2001 Farley Karbunkle .\" .\" All rights reserved. .\" .\" This program is free software. .\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions .\" are met: .\" 1. Redistributions of source code must retain the above copyright .\" notice, this list of conditions and the following disclaimer. .\" 2. Redistributions in binary form must reproduce the above copyright .\" notice, this list of conditions and the following disclaimer in the .\" documentation and/or other materials provided with the distribution. .\" .\" THIS SOFTWARE IS PROVIDED BY THE DEVELOPERS ``AS IS'' AND ANY EXPRESS OR .\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES .\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. .\" IN NO EVENT SHALL THE DEVELOPERS BE LIABLE FOR ANY DIRECT, INDIRECT, .\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT .\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, .\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY .\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT .\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF .\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. .\" .\" $FreeBSD: $ .\" .Dd March 16, 2001 .Dt DISABLE_INTR 9 .Os FreeBSD .Sh NAME .Nm disable_intr .Nd disable interrupts for devices .Sh SYNOPSIS .Fd #include .Ft intrmask_t .Fn disable_intr "void" .Sh DESCRIPTION .Pp This function disables interrupts and returns an interrupt mask to be used in a later call to .Xr restore_intr 9 . .Pp It is deliberately left undefined whether this disables interrupts only on the calling CPU or whether this disables interrupts across the entire system. Clearly it must be used with caution and does not eliminate the need for appropriate locking. .Sh RETURN VALUES Returns a value to be later passed to .Xr restore_intr 9 . .Sh SEE ALSO .Xr restore_intr 9 .Sh AUTHORS .An John Baldwin and the FreeBSD project. ---------- .\" -*- nroff -*- .\" .\" Copyright (c) 2001 Farley Karbunkle .\" .\" All rights reserved. .\" .\" This program is free software. .\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions .\" are met: .\" 1. Redistributions of source code must retain the above copyright .\" notice, this list of conditions and the following disclaimer. .\" 2. Redistributions in binary form must reproduce the above copyright .\" notice, this list of conditions and the following disclaimer in the .\" documentation and/or other materials provided with the distribution. .\" .\" THIS SOFTWARE IS PROVIDED BY THE DEVELOPERS ``AS IS'' AND ANY EXPRESS OR .\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES .\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. .\" IN NO EVENT SHALL THE DEVELOPERS BE LIABLE FOR ANY DIRECT, INDIRECT, .\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT .\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, .\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY .\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT .\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF .\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. .\" .\" $FreeBSD: $ .\" .Dd March 16, 2001 .Dt RESTORE_INTR 9 .Os FreeBSD .Sh NAME .Nm restore_intr .Nd restore interrupts from devices .Sh SYNOPSIS .Fd #include .Ft void .Fn restore_intr "intrmask_t" .Sh DESCRIPTION .Pp This function restores the ability of devices to generate interrupts. It takes an interrupt mask argument as returned by a previous call to .Xr disable_intr 9 . .Pp It is deliberately left undefined whether this restores interrupts only on the calling CPU or whether this disables interrupts across the entire system. Clearly it must be used with caution and does not eliminate the need for appropriate locking. .Sh SEE ALSO .Xr disable_intr 9 .Sh AUTHORS .An John Baldwin and the FreeBSD project. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 14:24:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-202.dsl.lsan03.pacbell.net [63.207.60.202]) by hub.freebsd.org (Postfix) with ESMTP id 0FF9637B71D for ; Fri, 16 Mar 2001 14:24:24 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 6394066E9D; Fri, 16 Mar 2001 14:24:23 -0800 (PST) Date: Fri, 16 Mar 2001 14:24:23 -0800 From: Kris Kennaway To: Poul-Henning Kamp Cc: Kris Kennaway , Peter Pentchev , arch@FreeBSD.ORG Subject: Re: add MD5Chunk(filename, .., offset, length) to libmd Message-ID: <20010316142423.A1278@mollari.cthul.hu> References: <20010316131523.B99286@mollari.cthul.hu> <16607.984777985@critter> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <16607.984777985@critter>; from phk@critter.freebsd.dk on Fri, Mar 16, 2001 at 10:26:25PM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 16, 2001 at 10:26:25PM +0100, Poul-Henning Kamp wrote: > In message <20010316131523.B99286@mollari.cthul.hu>, Kris Kennaway writes: > > > >--f2QGlHpHGjS2mn6Y > >Content-Type: text/plain; charset=3Dus-ascii > >Content-Disposition: inline > > > >On Fri, Mar 16, 2001 at 09:08:33PM +0200, Peter Pentchev wrote: > > > >> Attached is a patch to libmd, which adds an MD5Check() function, > > > >I'd appreciate it if you could provide a patch against libcrypto as > >well: libmd is a subset of what libcrypto provides (looks like libmd > >was actually taken from the OpenSSL code in fact),=20 >=20 > EXCUSE ME!!!! >=20 > I created libmd in july 1994, well before anybody had even heard > about much less implemented any kind of SSL... (Exactly the kind > of innovative behaviour we don't do here in FreeBSD according to > Jordan.) >=20 > In all likelyhood OpenSSL nicked our libmd... The SHA1 and RIPEMD-160 code is taken from OpenSSL. The MD5 header is copyright RSA Data Security Inc (and contains annoying s/_// differences between the OpenSSL version). I'm not claiming you didn't write at least some of that code, but libmd as it stands today clearly has a large amount in common with OpenSSL. Kris --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6spKXWry0BWjoQKURAsluAKC7sOi9EQwUJ4O60FPh+Qld1KUAUwCaAwY0 GS3vJZYCVnhDkCTtxPImb9A= =AffE -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 14:25:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-202.dsl.lsan03.pacbell.net [63.207.60.202]) by hub.freebsd.org (Postfix) with ESMTP id 78E8E37B71A; Fri, 16 Mar 2001 14:25:28 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 1C51066B25; Fri, 16 Mar 2001 14:25:28 -0800 (PST) Date: Fri, 16 Mar 2001 14:25:28 -0800 From: Kris Kennaway To: Chris Dillon Cc: Alfred Perlstein , Jim Mock , Steve O'Hara-Smith , arch@FreeBSD.ORG, j mckitrick , jkh@FreeBSD.ORG Subject: Re: More BETA evilness Re: BETA induced nervousness Message-ID: <20010316142527.B1278@mollari.cthul.hu> References: <20010316134113.I29888@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="wq9mPyueHGvFACwf" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from cdillon@wolves.k12.mo.us on Fri, Mar 16, 2001 at 04:08:41PM -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --wq9mPyueHGvFACwf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 16, 2001 at 04:08:41PM -0600, Chris Dillon wrote: > On Fri, 16 Mar 2001, Alfred Perlstein wrote: >=20 > > (moved to -arch because...) > > > > FYI I'm fighting this cause on the -arch list, I've just quoted > > this message and added cc's to the people who have the authority > > to fix it. > > > > I want to be clear that it's not just me that's irritated by this. > > > > My current solution is instead of -BETA have -STABLE-RC, the > > '-RC' is there to give knowledgeable people a heads-up and > > the '-STABLE' is prominent enough to reduce the amount of > > concern. >=20 > That would probably lead to some amount of confusion as well, since > the combination of "4.3" and "STABLE" anywhere would seem to indicate > a post-4.3-RELEASE state (hence 4.3-STABLE), while we are actually > talking about a pre-release state. If it were 4.2-STABLE-RC, that > would make sense, but then you don't have the version number bump that > is needed to test ports, as was pointed out. Maybe "4.3-ALMOST-THERE" > or "4.3-NOT-QUITE"? :-) 4.3-PRERELEASE. Explains exactly what it is, and does so without the negative connotations of -BETA. Kris --wq9mPyueHGvFACwf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6spLXWry0BWjoQKURAv+lAJ0a79gQ1cSwAtjGy5xmahcZ5WVi4QCcD/+O 9khIJnJ6mU4T5ZJkDWef9XM= =x3hO -----END PGP SIGNATURE----- --wq9mPyueHGvFACwf-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 14:31:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 7F01537B718 for ; Fri, 16 Mar 2001 14:31:46 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2GMV6G66830; Fri, 16 Mar 2001 14:31:06 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 16 Mar 2001 14:31:18 -0800 (PST) From: John Baldwin To: Matthew Jacob Subject: RE: man pages Cc: arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 16-Mar-01 Matthew Jacob wrote: > Actually, I think you only need disable_intr && restore_intr, which should be > paired over tight MD code sections, and yes, leaving it ambigious is > desirable > IMO. Actually, the cy(4) driver uses explicit enable_intr()'s as does some of the 386 fpu code, and the pre-spinlock variant of the sio(4) driver also used explicit enable_intr(). I'm not a big fan out of it myself, but some things do need it. The manpages look good though I'd be inclined personally to collapse them into a single intr.9 manpage. Also, the actual functions are declared in , and I didn't write these, I am just tweaking them. :) -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - 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 Fri Mar 16 14:31:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id DBC4637B718 for ; Fri, 16 Mar 2001 14:31:54 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2GMV5G66822; Fri, 16 Mar 2001 14:31:05 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010316170551.A3379@peitho.fxp.org> Date: Fri, 16 Mar 2001 14:31:17 -0800 (PST) From: John Baldwin To: Chris Faulhaber Subject: Re: NO MORE '-BETA' Cc: Alfred Perlstein , arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 16-Mar-01 Chris Faulhaber wrote: > On Fri, Mar 16, 2001 at 01:59:36PM -0800, John Baldwin wrote: >> >> On 16-Mar-01 Garance A Drosihn wrote: >> > At 12:26 PM -0800 3/16/01, John Baldwin wrote: >> >>On 16-Mar-01 Alfred Perlstein wrote: >> >>> Yes, the real problem with this is '2' (newvers.sh), there's nothing >> >>> wrong with using 'BETA' in the names on the ftp site. >> >> >> >>People who follow -stable should be reading -stable. >> > >> > A lot of people "should" be doing a lot of things. Maybe these users >> > partially follow the -stable mailing list, but happen to ignore any >> > message with '-beta' in the subject because "they know" they are >> > running the -stable branch. As I say, it is only a few people each >> > release, and it never takes more than a few minutes to calm them down, >> > but it DOES happen every release cycle. >> >> Is this in the FAQ yet? If we documented our release engineering process >> and >> put it on the website, that would eliminate most of this confusion. :) I've >> somewhat attempted to do this but can't seem to get the release engineer to >> look at it. :-P >> > > http://www.FreeBSD.org/FAQ/admin.html#RELEASE-CANDIDATE Woo, cool. Then it seems people aren't using the resources normally available to them either in the form of mailing lists or the FAQ. I'm not sure we need to sacrafice our release engineering process for the sake of people doing cvsup upgrades that can't be bothered to either read the mailing lists or look in the FAQ. :( -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - 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 Fri Mar 16 14:34:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 0FCD937B718; Fri, 16 Mar 2001 14:34:25 -0800 (PST) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id OAA24614; Fri, 16 Mar 2001 14:34:26 -0800 Date: Fri, 16 Mar 2001 14:34:22 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Baldwin Cc: arch@FreeBSD.org Subject: RE: man pages In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sure! Great! But put 'em in! > > On 16-Mar-01 Matthew Jacob wrote: > > Actually, I think you only need disable_intr && restore_intr, which should be > > paired over tight MD code sections, and yes, leaving it ambigious is > > desirable > > IMO. > > Actually, the cy(4) driver uses explicit enable_intr()'s as does some of the > 386 fpu code, and the pre-spinlock variant of the sio(4) driver also used > explicit enable_intr(). I'm not a big fan out of it myself, but some things do > need it. The manpages look good though I'd be inclined personally to collapse > them into a single intr.9 manpage. Also, the actual functions are declared > in , and I didn't write these, I am just tweaking them. :) > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 14:54:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from cypherpunks.ai (cypherpunks.ai [209.88.68.47]) by hub.freebsd.org (Postfix) with ESMTP id 1AFF837B718 for ; Fri, 16 Mar 2001 14:54:37 -0800 (PST) (envelope-from jeroen@vangelderen.org) Received: from vangelderen.org (grolsch.ai [209.88.68.214]) by cypherpunks.ai (Postfix) with ESMTP id 0FD3459; Fri, 16 Mar 2001 18:54:26 -0400 (AST) Message-ID: <3AB299A1.5108D321@vangelderen.org> Date: Fri, 16 Mar 2001 18:54:25 -0400 From: "Jeroen C. van Gelderen" X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Peter Pentchev Cc: arch@FreeBSD.org Subject: Re: add MD5Chunk(filename, .., offset, length) to libmd References: <20010316210833.C8245@ringworld.oblivion.bg> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Pentchev wrote: > (I wonder if I'm starting another bikeshed, but oh well ;) > > As phk pointed out in the SITE MD5 thread, it is sometimes useful > to compute the MD5 hash over a range of a file. I agree this is trivial > to implement, but why not have it in our standard toolbox? > > Attached is a patch to libmd, which adds an MD5Check() function, > similar in all aspects to MD5File() (actually quite a lot of it > was shamelessly stolen from MD5File ;), but with additional two > arguments, offset and length to compute the hash over. If there is > sufficient interest, I could take the time to document it in the > corresponding manpages, too. How about naming it MD5FileChunk to clearly show that it is an extension (or generalization) of the MD5File function and not something completely new? OTT it sounds useful. Cheers, Jeroen -- Jeroen C. van Gelderen - jeroen@vangelderen.org "If I could save the Union without freeing any slave I would do it; and if I could save it by freeing some and leaving others alone I would also do that." -- Abraham Lincoln, August 22, 1862 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 15: 2:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by hub.freebsd.org (Postfix) with ESMTP id 8C50E37B718; Fri, 16 Mar 2001 15:02:55 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.11.3/8.11.3) id f2GN5iK14362; Fri, 16 Mar 2001 15:05:44 -0800 (PST) (envelope-from sgk) Date: Fri, 16 Mar 2001 15:05:44 -0800 From: Steve Kargl To: John Baldwin Cc: Chris Faulhaber , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: NO MORE '-BETA' Message-ID: <20010316150544.A14137@troutmask.apl.washington.edu> References: <20010316170551.A3379@peitho.fxp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.ORG on Fri, Mar 16, 2001 at 02:31:17PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Mar 16, 2001 at 02:31:17PM -0800, John Baldwin wrote: > > Woo, cool. Then it seems people aren't using the resources normally > available to them either in the form of mailing lists or the FAQ. I'm > not sure we need to sacrafice our release engineering process for the > sake of people doing cvsup upgrades that can't be bothered to either > read the mailing lists or look in the FAQ. :( The FAQ is never posted to FreeBSD newsgroups. We get several new FreeBSD users from other OS's where newsgroups are the primary source of help. There is a handful of people who try to answer questions. My answers usually include pointers to the mailing list archives, Handbook, and Tutorials. Perhaps, a cron job could post a text version of the FAQ once a month (or two) to comp.unix.bsd.freebsd.announce. -- Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 15: 3:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 274D937B71A; Fri, 16 Mar 2001 15:03:10 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id PAA24469; Fri, 16 Mar 2001 15:45:25 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp04.primenet.com, id smtpdAAAJ8aGtV; Fri Mar 16 15:45:00 2001 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id PAA17018; Fri, 16 Mar 2001 15:50:49 -0700 (MST) From: Terry Lambert Message-Id: <200103162250.PAA17018@usr07.primenet.com> Subject: Re: NO MORE '-BETA' To: jhb@FreeBSD.ORG (John Baldwin) Date: Fri, 16 Mar 2001 22:50:49 +0000 (GMT) Cc: bright@wintelcom.net (Alfred Perlstein), arch@FreeBSD.ORG, jkh@osd.bsdi.com (Jordan Hubbard), drosih@rpi.edu (Garance A Drosihn), tlambert@primenet.com (Terry Lambert) In-Reply-To: from "John Baldwin" at Mar 16, 2001 12:26:51 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > So either quit doing '2' or use a variant of > > Terry's suggestion '-stable-rc' > > > > ~ % uname -srm > > FreeBSD 4.3-STABLE-RC i386 > > Except that it's not a real release candidate. Which is why we don't > just use -RC the whole time. -RC means that we would actually feel > confident releasing that exact source on the CD's as foo-RELEASE. > This is not true for foo-BETA, as it is a time for people to test > stuff out and spot things that need to be fixed. So what's the difference in tags between a release candidate and a beta? 8-). OH MY GOD! IT'S NO LONGER STABLE! WHAT _IS_ IT?!? BETA!?! GREAT CAESER'S GHOST! GET CLARK KENT IN HERE _NOW_!!! ..."Beta" is well known to be a synonym for "my cat wrote the floppy disk driver"... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 15: 3:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 79BF137B718; Fri, 16 Mar 2001 15:03:55 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id QAA21940; Fri, 16 Mar 2001 16:00:29 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp03.primenet.com, id smtpdAAA9Ua4wO; Fri Mar 16 15:57:45 2001 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id QAA17472; Fri, 16 Mar 2001 16:00:56 -0700 (MST) From: Terry Lambert Message-Id: <200103162300.QAA17472@usr07.primenet.com> Subject: Re: More BETA evilness Re: BETA induced nervousness To: bright@wintelcom.net (Alfred Perlstein) Date: Fri, 16 Mar 2001 23:00:56 +0000 (GMT) Cc: mij@osdn.com (Jim Mock), steveo@eircom.net (Steve O'Hara-Smith), arch@FreeBSD.ORG, jcm@FreeBSD-uk.eu.org (j mckitrick), jkh@FreeBSD.ORG In-Reply-To: <20010316134113.I29888@fw.wintelcom.net> from "Alfred Perlstein" at Mar 16, 2001 01:41:13 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > FYI I'm fighting this cause on the -arch list, I've just quoted > this message and added cc's to the people who have the authority > to fix it. > > I want to be clear that it's not just me that's irritated by this. > > My current solution is instead of -BETA have -STABLE-RC, the > '-RC' is there to give knowledgeable people a heads-up and > the '-STABLE' is prominent enough to reduce the amount of > concern. [...] > > > ---------------------- > > > DO NOT PANIC - BETA is a normal phase that STABLE goes through prior > > > to the rolling of a release. If anything it is *MORE* stable than > > > usual during BETA as all changes are monitered by the release > > > engineer. > > > ---------------------- ??? -STABLE++ -MORE-STABLE -METASTABLE Heh. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 15: 8:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id D17FE37B719 for ; Fri, 16 Mar 2001 15:08:42 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2GN8gG98183 for arch@FreeBSD.org; Fri, 16 Mar 2001 15:08:42 -0800 (PST) (envelope-from obrien) Date: Fri, 16 Mar 2001 15:08:32 -0800 From: "David O'Brien" To: arch@FreeBSD.org Subject: Re: NO MORE '-BETA' Message-ID: <20010316150832.A98051@dragon.nuxi.com> Reply-To: arch@FreeBSD.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Fri, Mar 16, 2001 at 01:59:36PM -0800 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 X-Loop: FreeBSD.ORG On Fri, Mar 16, 2001 at 01:59:36PM -0800, John Baldwin wrote: > > A lot of people "should" be doing a lot of things. Maybe these users > > partially follow the -stable mailing list, but happen to ignore any > > message with '-beta' in the subject because "they know" they are > > running the -stable branch. As I say, it is only a few people each > > release, and it never takes more than a few minutes to calm them down, > > but it DOES happen every release cycle. > > Is this in the FAQ yet? Yes. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 15:11:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id D23E037B718 for ; Fri, 16 Mar 2001 15:11:25 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2GNBKb98276; Fri, 16 Mar 2001 15:11:20 -0800 (PST) (envelope-from obrien) Date: Fri, 16 Mar 2001 15:11:20 -0800 From: "David O'Brien" To: Terry Lambert Cc: arch@FreeBSD.ORG Subject: Re: NO MORE '-BETA' Message-ID: <20010316151120.B98051@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <200103162250.PAA17018@usr07.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103162250.PAA17018@usr07.primenet.com>; from tlambert@primenet.com on Fri, Mar 16, 2001 at 10:50:49PM +0000 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 X-Loop: FreeBSD.ORG On Fri, Mar 16, 2001 at 10:50:49PM +0000, Terry Lambert wrote: > So what's the difference in tags between a release candidate and > a beta? RTFFAQ http://www.FreeBSD.org/FAQ/admin.html#RELEASE-CANDIDATE To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 15:23:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 24C0937B718; Fri, 16 Mar 2001 15:23:34 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id QAA06972; Fri, 16 Mar 2001 16:17:29 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp04.primenet.com, id smtpdAAAtNaWCn; Fri Mar 16 16:17:16 2001 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id QAA18245; Fri, 16 Mar 2001 16:23:12 -0700 (MST) From: Terry Lambert Message-Id: <200103162323.QAA18245@usr07.primenet.com> Subject: Re: man pages To: mjacob@feral.com Date: Fri, 16 Mar 2001 23:23:12 +0000 (GMT) Cc: jhb@FreeBSD.ORG (John Baldwin), arch@FreeBSD.ORG In-Reply-To: from "Matthew Jacob" at Mar 16, 2001 02:21:58 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Actually, I think you only need disable_intr && restore_intr, which should be > paired over tight MD code sections, and yes, leaving it ambigious is desirable > IMO. [ .. man page ... ] > It is deliberately left undefined whether this disables interrupts > only on the calling CPU or whether this disables interrupts across > the entire system. Clearly it must be used with caution and does > not eliminate the need for appropriate locking. Rather than doing this, wouldn't it just be easier to say that it can not be uses for inter-CPU synchronization, but may result in inter-CPU synchronization as a side effect on some architectures? Given that it's going to be used, and it's vaue, you might even go so far as to claim "as an undesirable side effect"... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 15:24:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hand.dotat.at (inch.demon.co.uk [194.222.223.128]) by hub.freebsd.org (Postfix) with ESMTP id 7F6CA37B71A for ; Fri, 16 Mar 2001 15:24:08 -0800 (PST) (envelope-from fanf@dotat.at) Received: from fanf by hand.dotat.at with local (Exim 3.20 #3) id 14e3Zd-0001TV-00; Fri, 16 Mar 2001 23:23:57 +0000 Date: Fri, 16 Mar 2001 23:23:57 +0000 From: Tony Finch To: Terry Lambert Cc: freebsd-arch@FreeBSD.ORG, Tony Finch Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010316232357.T385@hand.dotat.at> References: <20010316044655.C385@hand.dotat.at> <200103161836.LAA14833@usr02.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103161836.LAA14833@usr02.primenet.com> Organization: Covalent Technologies, Inc Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > >Actually, it would prevent useful modification more often than >accidental modification. Accidental modification is nearly >impossible; who would do it? *accidental* i.e. caused by obscure bugs or hardware problems. This is the end-to-end argument. Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at IRISH SEA: EAST 5 TO 7, OCCASIONALLY GALE 8. RAIN AT TIMES. MODERATE, OCCASIONALLY POOR IN SOUTH. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 15:25:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id 5F9C037B718; Fri, 16 Mar 2001 15:25:15 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id QAA86186; Fri, 16 Mar 2001 16:24:59 -0700 Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp10.phx.gblx.net, id smtpdP2KqMa; Fri Mar 16 16:24:53 2001 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id QAA18341; Fri, 16 Mar 2001 16:25:05 -0700 (MST) From: Terry Lambert Message-Id: <200103162325.QAA18341@usr07.primenet.com> Subject: Re: NO MORE '-BETA' To: jhb@FreeBSD.ORG (John Baldwin) Date: Fri, 16 Mar 2001 23:25:04 +0000 (GMT) Cc: jedgar@fxp.org (Chris Faulhaber), bright@wintelcom.net (Alfred Perlstein), arch@FreeBSD.ORG In-Reply-To: from "John Baldwin" at Mar 16, 2001 02:31:17 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Woo, cool. Then it seems people aren't using the resources > normally available to them either in the form of mailing lists > or the FAQ. I'm not sure we need to sacrafice our release > engineering process for the sake of people doing cvsup upgrades > that can't be bothered to either read the mailing lists or look > in the FAQ. :( Saying "not a bug" won't keep people from asking. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 15:33:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 29C7937B719; Fri, 16 Mar 2001 15:33:26 -0800 (PST) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id PAA24825; Fri, 16 Mar 2001 15:33:28 -0800 Date: Fri, 16 Mar 2001 15:33:24 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Terry Lambert Cc: John Baldwin , arch@FreeBSD.ORG Subject: Re: man pages In-Reply-To: <200103162323.QAA18245@usr07.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Actually, I think you only need disable_intr && restore_intr, which should be > > paired over tight MD code sections, and yes, leaving it ambigious is desirable > > IMO. > > [ .. man page ... ] > > > It is deliberately left undefined whether this disables interrupts > > only on the calling CPU or whether this disables interrupts across > > the entire system. Clearly it must be used with caution and does > > not eliminate the need for appropriate locking. > > > Rather than doing this, wouldn't it just be easier to say that it > can not be uses for inter-CPU synchronization, but may result in > inter-CPU synchronization as a side effect on some architectures? I wouldn't even go that far. The purpose of disable_intr is to do what it says- disable interrupts. One purpose might be something like disabling interrupts prior to (re)entering the PROM for reboot or debugging purposes (a la SPARC/OBB). It's left vague as to whether this has a global or per-cpu because each platform has to provide it, but the specifics of the scope of how it works is platform specific. In AT&T parlance, it's a DDI function, not a DKI function. Let's assume we have a broadcast interrupt platform, but disable_intr only disables interrupt recognition for the calling CPU. One might say it's a useless function- I'd say not. You *still* use locks to keep threads on other cpus out of critical regions- but you may have wanted to make sure you wouldn't be getting any ithreads pending on the *calling* cpu- I'm sure jhb can think of a number of cases this would help. > Given that it's going to be used, and it's vaue, you might even > go so far as to claim "as an undesirable side effect"... In order to address some other folks' expressed concerns that this might be 'useless', some very careful wording has to occur. I don't think we want to say anything at all about using this as a synchronization mechanism, unless to say "Do *not* consider this to be a method for synchronization" -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 15:37:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id DE8DE37B71C; Fri, 16 Mar 2001 15:37:28 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f2GNaOg79604; Fri, 16 Mar 2001 15:36:24 -0800 (PST) (envelope-from dillon) Date: Fri, 16 Mar 2001 15:36:24 -0800 (PST) From: Matt Dillon Message-Id: <200103162336.f2GNaOg79604@earth.backplane.com> To: Terry Lambert Cc: jhb@FreeBSD.ORG (John Baldwin), bright@wintelcom.net (Alfred Perlstein), arch@FreeBSD.ORG, jkh@osd.bsdi.com (Jordan Hubbard), drosih@rpi.edu (Garance A Drosihn), tlambert@primenet.com (Terry Lambert) Subject: Re: NO MORE '-BETA' References: <200103162250.PAA17018@usr07.primenet.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> stuff out and spot things that need to be fixed. : :So what's the difference in tags between a release candidate and :a beta? : :8-). : :OH MY GOD! :IT'S NO LONGER STABLE! :WHAT _IS_ IT?!? :BETA!?! :GREAT CAESER'S GHOST! GET CLARK KENT IN HERE _NOW_!!! JORDAN_WAS_HERE_IN_YXXX_Y2001__IF_U_C_THIS_AND_COMPLAIN_GET_A_LIFE_D00D! I_GOT_1_4_U_RIGHT_HERE__SMACK! -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 15:39:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id C2F5A37B718 for ; Fri, 16 Mar 2001 15:39:52 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id QAA111560; Fri, 16 Mar 2001 16:39:36 -0700 Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp10.phx.gblx.net, id smtpdiZcnEa; Fri Mar 16 16:39:27 2001 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id QAA18793; Fri, 16 Mar 2001 16:39:39 -0700 (MST) From: Terry Lambert Message-Id: <200103162339.QAA18793@usr07.primenet.com> Subject: Re: NO MORE '-BETA' To: arch@FreeBSD.ORG Date: Fri, 16 Mar 2001 23:39:38 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert) In-Reply-To: <20010316151120.B98051@dragon.nuxi.com> from "David O'Brien" at Mar 16, 2001 03:11:20 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > So what's the difference in tags between a release candidate and > > a beta? > > RTFFAQ http://www.FreeBSD.org/FAQ/admin.html#RELEASE-CANDIDATE I was facetiously point out that this is like the whole "UNIX had _PARTITIONS_ first, so we are renaming what 99.995% of the world calls ``partitions'' as ``slices'', and you should work to learn our non-standard terminology" thing... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 15:44:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 0278737B73D for ; Fri, 16 Mar 2001 15:44:03 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2GNh1G68782; Fri, 16 Mar 2001 15:43:01 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200103162250.PAA17018@usr07.primenet.com> Date: Fri, 16 Mar 2001 15:43:14 -0800 (PST) From: John Baldwin To: Terry Lambert Subject: Re: NO MORE '-BETA' Cc: (Garance A Drosihn) , (Jordan Hubbard) , arch@FreeBSD.org, (Alfred Perlstein) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 16-Mar-01 Terry Lambert wrote: >> > So either quit doing '2' or use a variant of >> > Terry's suggestion '-stable-rc' >> > >> > ~ % uname -srm >> > FreeBSD 4.3-STABLE-RC i386 >> >> Except that it's not a real release candidate. Which is why we don't >> just use -RC the whole time. -RC means that we would actually feel >> confident releasing that exact source on the CD's as foo-RELEASE. >> This is not true for foo-BETA, as it is a time for people to test >> stuff out and spot things that need to be fixed. > > So what's the difference in tags between a release candidate and > a beta? > > 8-). I just said. :-P I wouldn't want to put a raw 4.3-BETA out on the CD's, instead -BETA is the time during which we test it out and try to shake out bugs, polish things, etc. so that we can then move onto a 4.3-RC that could go out on the CD's just like it is. Then just to be paranoid we let the -RC get tested a while before doing the release. > ..."Beta" is well known to be a synonym for "my cat wrote the > floppy disk driver"... I thought it meant something more along the lines of test version, but I assume if we did 4.3-TEST everyone would freak out then as well. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - 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 Fri Mar 16 15:48:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail-100baset.rpi.edu [128.113.26.45]) by hub.freebsd.org (Postfix) with ESMTP id 7A1C937B718; Fri, 16 Mar 2001 15:48:10 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id SAA31610; Fri, 16 Mar 2001 18:48:06 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20010316134113.I29888@fw.wintelcom.net> References: <20010316214210.5a3dc591.steveo@eircom.net> <20010316160949.A3791@guinness.osdn.com> <20010316134113.I29888@fw.wintelcom.net> Date: Fri, 16 Mar 2001 18:48:05 -0500 To: Alfred Perlstein , Jim Mock From: Garance A Drosihn Subject: Re: More BETA evilness Re: BETA induced nervousness Cc: "Steve O'Hara-Smith" , arch@FreeBSD.ORG, j mckitrick , jkh@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 1:41 PM -0800 3/16/01, Alfred Perlstein wrote: >My current solution is instead of -BETA have -STABLE-RC, the >'-RC' is there to give knowledgeable people a heads-up and >the '-STABLE' is prominent enough to reduce the amount of >concern. It isn't quite the same as 4.3-stable, because there hasn't been a 4.3-release yet. It also isn't a "release candidate", so -RC seems wrong to me. Something like: 4.3-pre-release or 4.3-precursor seems better to me. Different enough for 'ports', but neither are as unsettling as seeing the word "beta" pop up when you were expecting a "stable" operating system. -- Garance Alistair Drosehn = gad@eclipse.acs.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 Fri Mar 16 15:52:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id EC25637B718; Fri, 16 Mar 2001 15:52:19 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id QAA17397; Fri, 16 Mar 2001 16:46:16 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp04.primenet.com, id smtpdAAAv7aySH; Fri Mar 16 16:45:57 2001 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id QAA19187; Fri, 16 Mar 2001 16:51:56 -0700 (MST) From: Terry Lambert Message-Id: <200103162351.QAA19187@usr07.primenet.com> Subject: Re: man pages To: mjacob@feral.com Date: Fri, 16 Mar 2001 23:51:56 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), jhb@FreeBSD.ORG (John Baldwin), arch@FreeBSD.ORG In-Reply-To: from "Matthew Jacob" at Mar 16, 2001 03:33:24 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Rather than doing this, wouldn't it just be easier to say that it > > can not be uses for inter-CPU synchronization, but may result in > > inter-CPU synchronization as a side effect on some architectures? > > I wouldn't even go that far. [ ... ] > Let's assume we have a broadcast interrupt platform, but disable_intr only > disables interrupt recognition for the calling CPU. One might say it's a > useless function- I'd say not. You *still* use locks to keep threads on other > cpus out of critical regions- but you may have wanted to make sure you > wouldn't be getting any ithreads pending on the *calling* cpu- I'm sure jhb > can think of a number of cases this would help. Sounds like you want something like these: intr_disable_this_cpu() ithread_diable_this_cpu() ... It seems to me that the function ou are documenting is machine specific, and should be named for the architecture/CPU/etc. to which it applies. > > Given that it's going to be used, and it's vaue, you might even > > go so far as to claim "as an undesirable side effect"... > > In order to address some other folks' expressed concerns that this might be > 'useless', some very careful wording has to occur. I don't think we want to > say anything at all about using this as a synchronization mechanism, unless to > say "Do *not* consider this to be a method for synchronization" I'd even say: Do *not* consider this to be a method for synchronization Do *not* invert inter-cpu lock ordering after calling this function, as it may result in a starvation deadlock Personally, I thinkit's useless to name a function after something which it does, rather than naming it after something which you want it to do. The distinction is subtle, I grant you, but people will be wanting to use it for what it does _in order to get a resulting desirable effect_. If it isn't cross-platform, it isn't cross platform. I don't think it's reasonable to require an English degree or a Juris Doctorate or both to be able to tell why you would want to call a function with a name that seems to imply an incorrect usage might be reasonable and safely used cross-platform. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 15:53:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from citusc17.usc.edu (citusc17.usc.edu [128.125.38.177]) by hub.freebsd.org (Postfix) with ESMTP id 398B637B71C; Fri, 16 Mar 2001 15:53:26 -0800 (PST) (envelope-from kris@citusc17.usc.edu) Received: (from kris@localhost) by citusc17.usc.edu (8.11.3/8.11.2) id f2GNr8J41600; Fri, 16 Mar 2001 15:53:08 -0800 (PST) (envelope-from kris) Date: Fri, 16 Mar 2001 15:53:07 -0800 From: Kris Kennaway To: Terry Lambert Cc: Alfred Perlstein , Jim Mock , "Steve O'Hara-Smith" , arch@FreeBSD.ORG, j mckitrick , jkh@FreeBSD.ORG Subject: Re: More BETA evilness Re: BETA induced nervousness Message-ID: <20010316155307.A41507@citusc17.usc.edu> References: <20010316134113.I29888@fw.wintelcom.net> <200103162300.QAA17472@usr07.primenet.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="ibTvN161/egqYuK8" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103162300.QAA17472@usr07.primenet.com>; from tlambert@primenet.com on Fri, Mar 16, 2001 at 11:00:56PM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Mar 16, 2001 at 11:00:56PM +0000, Terry Lambert wrote: > -METASTABLE I actually like this one: metastable means "stable, but may spontaneously transition to something else at any point without warning" which is a pretty good description of what happens during the early phases of code freeze :-) Probably a bit too technical for most users, though :-) Kris --ibTvN161/egqYuK8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6sqdjWry0BWjoQKURAjfSAJ43R5TTUbPxgA2SrM9tYhlzM4j+hgCgmwC0 zNVV+7UMWkQyaJrO8p2tVqs= =jaBc -----END PGP SIGNATURE----- --ibTvN161/egqYuK8-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 16: 1:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 9A19B37B719; Fri, 16 Mar 2001 16:01:46 -0800 (PST) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id QAA24973; Fri, 16 Mar 2001 16:01:45 -0800 Date: Fri, 16 Mar 2001 16:01:41 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Terry Lambert Cc: John Baldwin , arch@FreeBSD.ORG Subject: Re: man pages In-Reply-To: <200103162351.QAA19187@usr07.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > [ ... ] > > > Let's assume we have a broadcast interrupt platform, but disable_intr only > > disables interrupt recognition for the calling CPU. One might say it's a > > useless function- I'd say not. You *still* use locks to keep threads on other > > cpus out of critical regions- but you may have wanted to make sure you > > wouldn't be getting any ithreads pending on the *calling* cpu- I'm sure jhb > > can think of a number of cases this would help. > > Sounds like you want something like these: > > intr_disable_this_cpu() > ithread_diable_this_cpu() > ... > > It seems to me that the function ou are documenting is machine > specific, and should be named for the architecture/CPU/etc. to > which it applies. Umm..., no, disable_intr *could* be a global block. Perhaps I didn't pick the best example. It still remains that disable_intr disables interrupts. restore_intr restores the state that existed prior to the disable_intr call. The only thing which I think people have problems with is my running around saying "do *not* say whether it's global or cpu-local". > > In order to address some other folks' expressed concerns that this might be > > 'useless', some very careful wording has to occur. I don't think we want to > > say anything at all about using this as a synchronization mechanism, unless to > > say "Do *not* consider this to be a method for synchronization" > > I'd even say: > > Do *not* consider this to be a method for synchronization > Do *not* invert inter-cpu lock ordering after calling this > function, as it may result in a starvation deadlock Well, yes, sure. Isn't that kernel SMP 101? > Personally, I thinkit's useless to name a function after something which > it does, rather than naming it after something which you want it to do. > The distinction is subtle, I grant you, but people will be wanting to use > it for what it does _in order to get a resulting desirable effect_. If it > isn't cross-platform, it isn't cross platform. I'm having trouble following this. Let me try and reiterate (putting on my Solaris DDI/DKI team hat, FWIBWBN) that disable_intr/restore_intr would be required to be on all platforms, but might have subtly different meanings. > > I don't think it's reasonable to require an English degree or a Juris > Doctorate or both to be able to tell why you would want to call a function > with a name that seems to imply an incorrect usage might be reasonable and > safely used cross-platform. Jeez. I'm sorry, Terry. I'm not following this at all. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 16: 4:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wolves.k12.mo.us (mail.wolves.k12.mo.us [207.160.214.1]) by hub.freebsd.org (Postfix) with ESMTP id 661BF37B71A; Fri, 16 Mar 2001 16:04:45 -0800 (PST) (envelope-from cdillon@wolves.k12.mo.us) Received: from mail.wolves.k12.mo.us (cdillon@mail.wolves.k12.mo.us [207.160.214.1]) by mail.wolves.k12.mo.us (8.9.3/8.9.3) with ESMTP id SAA28201; Fri, 16 Mar 2001 18:04:38 -0600 (CST) (envelope-from cdillon@wolves.k12.mo.us) Date: Fri, 16 Mar 2001 18:04:38 -0600 (CST) From: Chris Dillon To: Kris Kennaway Cc: Alfred Perlstein , Jim Mock , "Steve O'Hara-Smith" , , j mckitrick , Subject: Re: More BETA evilness Re: BETA induced nervousness In-Reply-To: <20010316142527.B1278@mollari.cthul.hu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 16 Mar 2001, Kris Kennaway wrote: > 4.3-PRERELEASE. Explains exactly what it is, and does so without > the negative connotations of -BETA. After having seen everything else that was proposed and shot down, this or something very similar (i.e. "PRE-RELEASE" or "PRE_RELEASE" or whatthehellever) is probably the best alternative to "BETA". I can't see any disadvantages to it other than it might still incur some hysteria in some newbies, but not nearly as much. Just my $.01 of course. -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. 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 Fri Mar 16 16:10: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 34AC337B718 for ; Fri, 16 Mar 2001 16:10:05 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2H09wN98986; Fri, 16 Mar 2001 16:09:58 -0800 (PST) (envelope-from obrien) Date: Fri, 16 Mar 2001 16:09:58 -0800 From: "David O'Brien" To: Terry Lambert Cc: arch@FreeBSD.ORG Subject: Re: NO MORE '-BETA' Message-ID: <20010316160957.A98966@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <20010316151120.B98051@dragon.nuxi.com> <200103162339.QAA18793@usr07.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103162339.QAA18793@usr07.primenet.com>; from tlambert@primenet.com on Fri, Mar 16, 2001 at 11:39:38PM +0000 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 X-Loop: FreeBSD.ORG On Fri, Mar 16, 2001 at 11:39:38PM +0000, Terry Lambert wrote: > > > So what's the difference in tags between a release candidate and > > > a beta? > > > > RTFFAQ http://www.FreeBSD.org/FAQ/admin.html#RELEASE-CANDIDATE ..snip.. > and you should work to learn our non-standard terminology" thing... Uh all other OS's I know of use these same terms -- Beta is right before a release, during a time annoying bugs can be fixed. Release Candidate is pretty self-explanatory, nor did we invent it. So maybe you should have said something to the effect that even though 100% of the OSs today have "Betas" the 99% of the user population is totally clueless as to these words meanings. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 16:18:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id C67AE37B718; Fri, 16 Mar 2001 16:18:38 -0800 (PST) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net (client-151-198-117-208.nnj.dialup.bellatlantic.net [151.198.117.208]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id TAA09498; Fri, 16 Mar 2001 19:18:33 -0500 (EST) Message-ID: <3AB2AD54.24723E1@bellatlantic.net> Date: Fri, 16 Mar 2001 19:18:28 -0500 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: Dag-Erling Smorgrav Cc: obrien@FreeBSD.org, arch@FreeBSD.org Subject: Re: how do I get sysctl node names ? References: <3AAD7529.9F964E6E@bellatlantic.net> <20010312225530.A35431@dragon.nuxi.com> <3AAED48E.822BB6BF@bellatlantic.net> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > > [redirected from -developers] > Sergey Babkin writes: > > Asking about the policy of the sysctl namespace seemed to me > > as something belonging to this list, i.e. an organisational issue. > > No, it's -arch fodder. -developers is only for matters that concern > noone but the committers. Then I'm sorry for my misunderstanding. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 16:28:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id B3A1A37B719 for ; Fri, 16 Mar 2001 16:28:48 -0800 (PST) (envelope-from jkh@osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.2/8.11.1) with ESMTP id f2H0RBH90691; Fri, 16 Mar 2001 16:27:12 -0800 (PST) (envelope-from jkh@osd.bsdi.com) To: phk@critter.freebsd.dk Cc: kris@obsecurity.org, roam@orbitel.bg, arch@FreeBSD.ORG Subject: Re: add MD5Chunk(filename, .., offset, length) to libmd In-Reply-To: <16607.984777985@critter> References: <20010316131523.B99286@mollari.cthul.hu> <16607.984777985@critter> X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010316162711S.jkh@osd.bsdi.com> Date: Fri, 16 Mar 2001 16:27:11 -0800 From: Jordan Hubbard X-Dispatcher: imput version 20000228(IM140) Lines: 4 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG libmd was innovative? Hmmm. We ARE inflating things a bit now, aren't we. :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 16:32:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 2D4F937B718; Fri, 16 Mar 2001 16:32:20 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id RAA03148; Fri, 16 Mar 2001 17:26:45 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp05.primenet.com, id smtpdAAADzaOgg; Fri Mar 16 17:26:41 2001 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id RAA20020; Fri, 16 Mar 2001 17:32:13 -0700 (MST) From: Terry Lambert Message-Id: <200103170032.RAA20020@usr07.primenet.com> Subject: Re: man pages To: mjacob@feral.com Date: Sat, 17 Mar 2001 00:30:52 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), jhb@FreeBSD.ORG (John Baldwin), arch@FreeBSD.ORG In-Reply-To: from "Matthew Jacob" at Mar 16, 2001 04:01:41 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > It seems to me that the function ou are documenting is machine > > specific, and should be named for the architecture/CPU/etc. to > > which it applies. > > Umm..., no, disable_intr *could* be a global block. Perhaps I didn't pick the > best example. > > It still remains that disable_intr disables interrupts. restore_intr restores > the state that existed prior to the disable_intr call. That's a useless thing to say, particularly, when disabling interrupts is carefully worded to be devoid of demantics. > The only thing which I think people have problems with is my running around > saying "do *not* say whether it's global or cpu-local". No, that's not my objection. > I'm having trouble following this. Let me try and reiterate (putting on my > Solaris DDI/DKI team hat, FWIBWBN) that disable_intr/restore_intr would be > required to be on all platforms, but might have subtly different meanings. [ ... ] > Jeez. I'm sorry, Terry. I'm not following this at all. Let me try to be plain about this: quit documenting what it does, and instead, document when and why I would want to use it. If you document what it does, I get the choice of calling it when *I* think it might be useful based on my interpreation of what it does. If you document when and why I would want to use it, it takes away the ambiguity, and drastically reduces the potential for error. As a shining example: msync(). What does msync() do? It's an explicit VM and buffer cache synchronization call, which flushes unwritten changes to a VM object mapped into a user space program back to the buffer cache. Is knowing this useful? No; here's why: 1) Knowing this doesn't tell me that on systems with a coherent VM and buffer cache, synchronization is automatic, and the reason to use it in my program is to ensure portability to systems without a coherent VM and buffer cache; in other words, on some system it is (or is supposed to be) a NOP. . 2) Knowing this doesn't tell me that flushing it to buffer cache is not the same thing as flushing it to stable storage... there's no indication of the fact that the buffer cache is an intermediate layer. 3) Naming it "msync()" leads me to belive that it is to a write to an mmap()'ed region, what "fsync() is to a write() to an open()'ed file; it's not. Clearly, msync() could be better documented, and we would all be better off for it; but it's not. Someone thought it would be a good idea to document what it does -- the interface -- and not when and why I would want to use it. So we get all this code that calls msync() everywhere the author thought they knew what msync() does would be useful, instead of where it needed to be called for portability, or where it would actually be useful. Does this make more sense now? I think the name is misleading, and I think leaving the man pages intentionally ambiguous is worse than not having them, and I think that a relatively new user looking at them or the code would still not have a good idea of when and why they'd want to use the calls. As it is, even with the suggested intntional ambiguities called out as being intentional, it'd take a language lawyer with a clear head to be able to use the thing correctly and not shoot someone on a different architecture in the foot. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 16:35:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id DC96137B719 for ; Fri, 16 Mar 2001 16:35:50 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id RAA10498; Fri, 16 Mar 2001 17:35:33 -0700 Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp10.phx.gblx.net, id smtpdhZPFMa; Fri Mar 16 17:35:25 2001 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id RAA20064; Fri, 16 Mar 2001 17:35:37 -0700 (MST) From: Terry Lambert Message-Id: <200103170035.RAA20064@usr07.primenet.com> Subject: Re: NO MORE '-BETA' To: arch@FreeBSD.ORG Date: Sat, 17 Mar 2001 00:34:16 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert) In-Reply-To: <20010316160957.A98966@dragon.nuxi.com> from "David O'Brien" at Mar 16, 2001 04:09:58 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > RTFFAQ http://www.FreeBSD.org/FAQ/admin.html#RELEASE-CANDIDATE > ..snip.. > > and you should work to learn our non-standard terminology" thing... > > Uh all other OS's I know of use these same terms -- Beta is right before > a release, during a time annoying bugs can be fixed. Release Candidate > is pretty self-explanatory, nor did we invent it. > > So maybe you should have said something to the effect that even though > 100% of the OSs today have "Betas" the 99% of the user population is > totally clueless as to these words meanings. No, the problem is the user's know where to go to get what we call "STABLE", and they see "STABLE" as being desirable and "BETA" as being undesirable. OS vendors which use the term "BETA" don't leave it as a changeling baby in place of "RELEASE+SERVICE PACK 3", which is how people interpret "STABLE". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 16:38:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 9570037B718; Fri, 16 Mar 2001 16:38:55 -0800 (PST) (envelope-from jkh@osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.2/8.11.1) with ESMTP id f2H0bmH90758; Fri, 16 Mar 2001 16:37:48 -0800 (PST) (envelope-from jkh@osd.bsdi.com) To: bright@wintelcom.net Cc: jhb@FreeBSD.ORG, cdillon@wolves.k12.mo.us, jkh@FreeBSD.ORG, arch@FreeBSD.ORG, sgk@troutmask.apl.washington.edu, kris@obsecurity.org Subject: Re: NO MORE '-BETA' In-Reply-To: <20010316134349.K29888@fw.wintelcom.net> References: <20010316134349.K29888@fw.wintelcom.net> X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010316163748Z.jkh@osd.bsdi.com> Date: Fri, 16 Mar 2001 16:37:48 -0800 From: Jordan Hubbard X-Dispatcher: imput version 20000228(IM140) Lines: 18 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG SIGH... Since this has clearly become a world-class crisis which requires that everyone down tools and do nothing else until we've resolved it, I'll tell you all what. I'll simply kill the whole BETA concept and we can happily not revisit this again come 4.4. 3 weeks before 4.4 is due, I'll freeze the tree and not change anything in newvers.sh or anywhere else which pertains to the release number. 10 days before 4.4 is due, I'll change it to 4.4-RC. On the day 4.4 comes out, I'll change it to 4.4-STABLE. Quick and easy. I'll also expect that the ports folks will simply bump the bento cluster "artificially" up to 4.4-RELEASE by setting the versions there manually, so the packages will all bear the correct information. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 16:44:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id BBD6837B718; Fri, 16 Mar 2001 16:44:14 -0800 (PST) (envelope-from jkh@osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.2/8.11.1) with ESMTP id f2H0h6H90793; Fri, 16 Mar 2001 16:43:07 -0800 (PST) (envelope-from jkh@osd.bsdi.com) To: bright@wintelcom.net Cc: jhb@FreeBSD.org, drosih@rpi.edu, tlambert@primenet.com, arch@FreeBSD.org Subject: Re: NO MORE '-BETA' In-Reply-To: <20010316140408.N29888@fw.wintelcom.net> References: <20010316140408.N29888@fw.wintelcom.net> X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010316164306W.jkh@osd.bsdi.com> Date: Fri, 16 Mar 2001 16:43:06 -0800 From: Jordan Hubbard X-Dispatcher: imput version 20000228(IM140) Lines: 7 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Let's just add something to cvsup to prompt the user? Or something > in the build process that's interactive? or what? How about turning it off to all but authorized users (those who have a registered cvsup key, as on freefall) during release periods? - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 16:45: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 664) id B710C37B719; Fri, 16 Mar 2001 16:44:57 -0800 (PST) Date: Fri, 16 Mar 2001 16:44:57 -0800 From: David O'Brien To: Jordan Hubbard Cc: bright@wintelcom.net, arch@FreeBSD.ORG Subject: Re: NO MORE '-BETA' Message-ID: <20010316164457.A57253@hub.freebsd.org> Reply-To: arch@freebsd.org References: <20010316134349.K29888@fw.wintelcom.net> <20010316163748Z.jkh@osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010316163748Z.jkh@osd.bsdi.com>; from jkh@osd.bsdi.com on Fri, Mar 16, 2001 at 04:37:48PM -0800 X-Operating-System: FreeBSD 4.2-STABLE 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 X-Loop: FreeBSD.ORG On Fri, Mar 16, 2001 at 04:37:48PM -0800, Jordan Hubbard wrote: > I'll also expect that the ports folks will simply bump the bento > cluster "artificially" up to 4.4-RELEASE by setting the versions there > manually, so the packages will all bear the correct information. This doesn't solve the ports problem as ports maintainers cannot use bento for their own build testing. To take this approach puts us back in the FORTRAN, punched cards, batch days. A ports committer under the above conditions have to see in the bento error logs there was a configure problem, guess at the fix (since it isn't as easy to test on their own box), commit a fix, wait 24-36 hours later to see if indeed the commit fixed the problem, repeat if needed... -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 16:59:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 48B4137B719 for ; Fri, 16 Mar 2001 16:59:32 -0800 (PST) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id QAA25151; Fri, 16 Mar 2001 16:59:34 -0800 Date: Fri, 16 Mar 2001 16:59:30 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Terry Lambert Cc: arch@FreeBSD.ORG Subject: man pages/more formal def enable_intr/disable_intr/restore_intr In-Reply-To: <200103170032.RAA20020@usr07.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well, you put it marginally nicer than at least one other person. I don't entirely agree with you- in particular of "how to use" because one should try and be broad if you don't know the exact usage down the line, but let's cut this short. How's this...(paren comments in, duh, parentheses) 1. Formal Definition disable_intr: Disables interrupts being dispatched to at least the calling CPU. Returns an intrmask_t (should probably be an opaque type) to be possibly used in a future call to restore_intr. restore_intr: Restores the state prior to the call to disable_intr such that the calling CPU now can have interrupts dispatched to it. enable_intr: Irrespective of any prior state, enables interrupts to be dispatched to the calling CPU. (this narrows things down) 2. Where it might be used (generic) The function disable_intr can and should be used when core platform code wishes to not even allow for the possibility of interrupts to be dispatched to a specific CPU. The function restore_intr restores the state prior to the call to disable_intr. Clearly it is symmetric to disable_intr. The function enable_intr enables the dispatch of interrupts and you use it when you have absolutely no idea whether interrupts are disabled or enabled currently but you want them enabled. 3. How it might be used (an example) It likely would be used (don't frickin nitpick on the details): disable_intr: The very first line in machine dependent startup.. enable_intr: Just prior to calling interrupt driven configuration during startup disable_intr/restore_intr: callout from the kernel to PROM code (OBP, PAL) I can think of a half dozen other places it might be used... 4. Suggested Implementations: ia32: save_flags, cli/sti restore_flags (sorry- I only know linux usage here) alpha: alpha_pal_swpipl(ALPHA_PSL_IPL_HIGH), alpha_pal_swpipl(x) alpha_pal_swpipl(ALPHA_PSL_IPL_0) sparc: mov %psr, %o0 | get current %psr or %o0, PSR_PIL, %o0 ! spl8 mov %o0, %psr ! update psr wr %o0, PSR_ET, %psr ! turn on traps (mask IU bug) nop ! psr delay nop ! psr delay nop ! psr delay retl ! return nop ! nuthin to do in delay slot ... Does this help? If not, just leave it noted that I'm not satisfying you and we'll move on. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 17: 0: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id C465537B719 for ; Fri, 16 Mar 2001 17:00:01 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f2H101n01071; Fri, 16 Mar 2001 17:00:01 -0800 (PST) Date: Fri, 16 Mar 2001 17:00:00 -0800 From: Alfred Perlstein To: arch@FreeBSD.ORG Cc: Jordan Hubbard Subject: Re: NO MORE '-BETA' Message-ID: <20010316170000.R29888@fw.wintelcom.net> References: <20010316134349.K29888@fw.wintelcom.net> <20010316163748Z.jkh@osd.bsdi.com> <20010316164457.A57253@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010316164457.A57253@hub.freebsd.org>; from TrimYourCC@nuxi.com on Fri, Mar 16, 2001 at 04:44:57PM -0800 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * David O'Brien [010316 16:45] wrote: > On Fri, Mar 16, 2001 at 04:37:48PM -0800, Jordan Hubbard wrote: > > I'll also expect that the ports folks will simply bump the bento > > cluster "artificially" up to 4.4-RELEASE by setting the versions there > > manually, so the packages will all bear the correct information. > > This doesn't solve the ports problem as ports maintainers cannot use > bento for their own build testing. To take this approach puts us back in > the FORTRAN, punched cards, batch days. > > A ports committer under the above conditions have to see in the bento > error logs there was a configure problem, guess at the fix (since it > isn't as easy to test on their own box), commit a fix, wait 24-36 hours > later to see if indeed the commit fixed the problem, repeat if needed... Or teach the ports committers the way to bump newver.sh themselves. A minor step that should be trivial for them to do. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 17: 2:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 2C1EB37B718 for ; Fri, 16 Mar 2001 17:02:08 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2H11OG71412; Fri, 16 Mar 2001 17:01:24 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010316164306W.jkh@osd.bsdi.com> Date: Fri, 16 Mar 2001 17:01:38 -0800 (PST) From: John Baldwin To: Jordan Hubbard Subject: Re: NO MORE '-BETA' Cc: arch@FreeBSD.org, tlambert@primenet.com, drosih@rpi.edu, bright@wintelcom.net Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 17-Mar-01 Jordan Hubbard wrote: >> Let's just add something to cvsup to prompt the user? Or something >> in the build process that's interactive? or what? > > How about turning it off to all but authorized users (those who have > a registered cvsup key, as on freefall) during release periods? Well, this has the side effect of stalling -current during the release cycle along with ports fixes and documentation. I think this is a sledgehammer type solution. :-/ > - Jordan -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - 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 Fri Mar 16 17: 6:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id D80C537B71A; Fri, 16 Mar 2001 17:06:04 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id RAA55369; Fri, 16 Mar 2001 17:05:29 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200103170105.RAA55369@gndrsh.dnsmgr.net> Subject: Re: More BETA evilness Re: BETA induced nervousness In-Reply-To: <20010316142527.B1278@mollari.cthul.hu> from Kris Kennaway at "Mar 16, 2001 02:25:28 pm" To: kris@obsecurity.org (Kris Kennaway) Date: Fri, 16 Mar 2001 17:05:29 -0800 (PST) Cc: cdillon@wolves.k12.mo.us (Chris Dillon), bright@wintelcom.net (Alfred Perlstein), mij@osdn.com (Jim Mock), steveo@eircom.net (Steve O'Hara-Smith), arch@FreeBSD.ORG, jcm@FreeBSD-uk.eu.org (j mckitrick), jkh@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ... > > 4.3-PRERELEASE. Explains exactly what it is, and does so without the > negative connotations of -BETA. A rose is a rose by any other name... call it what it is, just don't make the committed version of newvers.sh say BETA for very long, infact it does not need to say BETA ever... 4.2-STABLE, release engineer grabs his copy of the tree to roll BETA, modifies, newvers.sh to 4.3-BETA, rolls the bits to make sure it rolled okay, optional commits 4.3-BETA newvers.sh to act as a time marker for the bits, commits newvers.sh back to 4.2-STABLE so the cvsup users don't freak. Similiar action is taken for 4.3-RC, and 4.3-RELEASE (here the version stays at 4.3, BRANCH becomes STABLE.) As far as the ports system needing the version bump for testing, well the ports build testing _SHOULD_ be done on a system built from the release engineers BETA bits, which if you'd all read very carefully what I said, WOULD have the VERSION bump. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 17: 7:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from thehousleys.net (frenchknot.ne.mediaone.net [24.147.224.201]) by hub.freebsd.org (Postfix) with ESMTP id 9397237B718 for ; Fri, 16 Mar 2001 17:07:12 -0800 (PST) (envelope-from jim@thehousleys.net) Received: (from root@localhost) by thehousleys.net (8.11.3/8.11.2) id f2H17BF02004 for freebsd-arch@freebsd.org; Fri, 16 Mar 2001 20:07:11 -0500 (EST) (envelope-from jim@thehousleys.net) Received: from thehousleys.net (baby.int.thehousleys.net [192.168.0.24]) by thehousleys.net (8.11.3/8.11.3) with ESMTP id f2H176f01996 for ; Fri, 16 Mar 2001 20:07:06 -0500 (EST) (envelope-from jim@thehousleys.net) Message-ID: <3AB2B8BA.29C5E58E@thehousleys.net> Date: Fri, 16 Mar 2001 20:07:06 -0500 From: James Housley X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Inherate nodump cause significant slow down of dump References: <20010316232344.050CB3E1F@bazooka.unixfreak.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-10 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The changes to src/sbin/dump/traverse.c (1.10.2.2) cause significant slow down of the dump estimate phase. Specifically Phase II. My /usr partition has about 2.5G of data including ports. I had just the /usr/ports director flagged as nodump. I think that this needs to be backed out, or fixed before the 4.3-RELEASE. This is very easy to reproduce. I am assuming that /usr is /dev/ad0s1f and that ports is on that file system for the following instructions. For all of these example abort the dump when Phase II finishes with the "DUMP: estimate ..... blocks.." message appears. dump 0sf 1048576 /dev/null /dev/ad0s1f -- this takes 9 seconds to finish Phase II for all versions. dump 0hsf 0 1048576 /dev/null /dev/ad0s1f -- this takes 9 seconds to finish Phase II for all versions. chflags nodump /usr/ports ; dump 0sf 1048576 /dev/null /dev/ad0s1f -- this takes 9 seconds to finish Phase II for all versions. chflags nodump /usr/ports ; dump 0hsf 0 1048576 /dev/null /dev/ad0s1f -- this takes 9 seconds to finish Phase II for version 1.10.2.1 of src/sbin/dump/traverse.c chflags nodump /usr/ports ; dump 0hsf 0 1048576 /dev/null /dev/ad0s1f -- this takes 38 minutes to finish Phase II for version 1.10.2.1 of src/sbin/dump/traverse.c A I believe that it is because it repeats once for each file in the subtree: msg("mapping (Pass II) [directories]\n"); while (anydirskipped) { anydirskipped = mapdirs(maxino, &tapesize); } I have not yet tested: chflags -R nodump /usr/ports ; dump 0hsf 0 1048576 /dev/null /dev/ad0s1f To see if it is quicker. I think the problem may actually be in mapfiles() and not mapdirs(). The above test will tell me, I am also going to add a counter in the above loop to verify this theory. However I am in the middle of a build world back towards a more recent version. But after dinner I should be able to test this. I welcome independent testing. Jim -- /"\ ASCII Ribbon Campaign . \ / - NO HTML/RTF in e-mail . X - NO Word docs in e-mail . / \ ----------------------------------------------------------------- jeh@FreeBSD.org http://www.FreeBSD.org The Power to Serve jim@TheHousleys.Net http://www.TheHousleys.net --------------------------------------------------------------------- Progress (n) : What led from smart users in front of dumb terminals to dumb users in front of smart terminals. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 17: 8: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id CB1D937B71A; Fri, 16 Mar 2001 17:07:56 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f2H17tb01330; Fri, 16 Mar 2001 17:07:55 -0800 (PST) Date: Fri, 16 Mar 2001 17:07:55 -0800 From: Alfred Perlstein To: Jordan Hubbard Cc: jhb@FreeBSD.ORG, drosih@rpi.edu, tlambert@primenet.com, arch@FreeBSD.ORG Subject: Re: NO MORE '-BETA' Message-ID: <20010316170755.S29888@fw.wintelcom.net> References: <20010316140408.N29888@fw.wintelcom.net> <20010316164306W.jkh@osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010316164306W.jkh@osd.bsdi.com>; from jkh@osd.bsdi.com on Fri, Mar 16, 2001 at 04:43:06PM -0800 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Jordan Hubbard [010316 16:44] wrote: > > Let's just add something to cvsup to prompt the user? Or something > > in the build process that's interactive? or what? > > How about turning it off to all but authorized users (those who have > a registered cvsup key, as on freefall) during release periods? The real pain is that there doesn't seem to be a way stop users from upgrading before they actually do it. I think what'll happen is that sometime tomorrow I'll add an option to newvers.sh to detect a cross version change and have the world and installworld and installkernel targets check and prompt unless something like EARLY_ADOPTER=YES is set in make.conf or you're building a 'release'. Would that be ok? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 17: 8:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ohm.physics.purdue.edu (ohm.physics.purdue.edu [128.210.146.32]) by hub.freebsd.org (Postfix) with ESMTP id A130537B718; Fri, 16 Mar 2001 17:08:39 -0800 (PST) (envelope-from will@physics.purdue.edu) Received: (from will@localhost) by ohm.physics.purdue.edu (8.11.2/8.9.3) id f2H1BiN86455; Fri, 16 Mar 2001 20:11:44 -0500 (EST) (envelope-from will@physics.purdue.edu) X-Authentication-Warning: ohm.physics.purdue.edu: will set sender to will@physics.purdue.edu using -f Date: Fri, 16 Mar 2001 20:11:44 -0500 From: Will Andrews To: Jordan Hubbard Cc: bright@wintelcom.net, jhb@FreeBSD.ORG, cdillon@wolves.k12.mo.us, jkh@FreeBSD.ORG, arch@FreeBSD.ORG, sgk@troutmask.apl.washington.edu, kris@obsecurity.org Subject: Re: NO MORE '-BETA' Message-ID: <20010316201144.F61859@ohm.physics.purdue.edu> Reply-To: Will Andrews Mail-Followup-To: Will Andrews , Jordan Hubbard , bright@wintelcom.net, jhb@FreeBSD.ORG, cdillon@wolves.k12.mo.us, jkh@FreeBSD.ORG, arch@FreeBSD.ORG, sgk@troutmask.apl.washington.edu, kris@obsecurity.org References: <20010316134349.K29888@fw.wintelcom.net> <20010316163748Z.jkh@osd.bsdi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="WTIodBnYSlPqyvsK" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010316163748Z.jkh@osd.bsdi.com>; from jkh@osd.bsdi.com on Fri, Mar 16, 2001 at 04:37:48PM -0800 X-Operating-System: FreeBSD 4.2-STABLE i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --WTIodBnYSlPqyvsK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 16, 2001 at 04:37:48PM -0800, Jordan Hubbard wrote: > 3 weeks before 4.4 is due, I'll freeze the tree and not change > anything in newvers.sh or anywhere else which pertains to the release > number. 10 days before 4.4 is due, I'll change it to 4.4-RC. On the > day 4.4 comes out, I'll change it to 4.4-STABLE. Quick and easy. I think -PRERELEASE is perfectly fine. 10 days isn't nearly enough time. I didn't see any arguments against -PRERELEASE... --=20 wca --WTIodBnYSlPqyvsK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.3 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6srnPF47idPgWcsURAhl+AJ0eDFW47xkDvw5EFjWLSij/CbAvlQCePq2B h4iFC3+GJghk5QGotHDKXi4= =oh8U -----END PGP SIGNATURE----- --WTIodBnYSlPqyvsK-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 17:11:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [62.232.68.68]) by hub.freebsd.org (Postfix) with ESMTP id C912137B71A; Fri, 16 Mar 2001 17:11:46 -0800 (PST) (envelope-from paul@freebsd-services.co.uk) Received: from freebsd-services.co.uk (lobster.originative.co.uk [62.232.68.81]) by mailgate.originative.co.uk (Postfix) with ESMTP id F0D251D149; Sat, 17 Mar 2001 01:11:44 +0000 (GMT) Message-ID: <3AB2B9F4.B772ED78@freebsd-services.co.uk> Date: Sat, 17 Mar 2001 01:12:20 +0000 From: Paul "=?iso-8859-1?Q?Richards=FC?=" X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Chris Dillon Cc: Kris Kennaway , Alfred Perlstein , Jim Mock , Steve O'Hara-Smith , arch@FreeBSD.ORG, j mckitrick , jkh@FreeBSD.ORG Subject: Re: More BETA evilness Re: BETA induced nervousness References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Chris Dillon wrote: > > On Fri, 16 Mar 2001, Kris Kennaway wrote: > > > 4.3-PRERELEASE. Explains exactly what it is, and does so without > > the negative connotations of -BETA. > > After having seen everything else that was proposed and shot down, > this or something very similar (i.e. "PRE-RELEASE" or "PRE_RELEASE" or > whatthehellever) is probably the best alternative to "BETA". I can't > see any disadvantages to it other than it might still incur some > hysteria in some newbies, but not nearly as much. Just my $.01 of > course. Given that the process is a rolling one i.e. -stable continues on the same branch before during and after a release, why bother with beta versioning at all. At the moment we do the following -stable --> -beta --> -stable | --> -release The -beta phase doesn't really mean anything in terms of the repository or in really in terms of snapshots, it's more of an organisational phase where we MFC like made and pay a bit more attention to the quality of -stable. It doesn't seem like setting the OS version to beta gains us anything, we might as well do -stable --> -stable | --> -release As far as the project is concerned we pick a time period where we're preparing to branch off -stable and the usual MFC madness happens and people take care to stabilise -stable, we fork off a branch when the release looks good and -stable continues as normal. To the average -stable tracker nothing happens, to the release team nothing really changes except they save a bit of work setting the version. Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 17:16: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 2B1F537B718 for ; Fri, 16 Mar 2001 17:16:05 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2H1FMG71841; Fri, 16 Mar 2001 17:15:22 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010316170755.S29888@fw.wintelcom.net> Date: Fri, 16 Mar 2001 17:15:35 -0800 (PST) From: John Baldwin To: Alfred Perlstein Subject: Re: NO MORE '-BETA' Cc: arch@FreeBSD.org, tlambert@primenet.com, drosih@rpi.edu, Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 17-Mar-01 Alfred Perlstein wrote: > * Jordan Hubbard [010316 16:44] wrote: >> > Let's just add something to cvsup to prompt the user? Or something >> > in the build process that's interactive? or what? >> >> How about turning it off to all but authorized users (those who have >> a registered cvsup key, as on freefall) during release periods? > > The real pain is that there doesn't seem to be a way stop users from > upgrading before they actually do it. > > I think what'll happen is that sometime tomorrow I'll add an option > to newvers.sh to detect a cross version change and have the world > and installworld and installkernel targets check and prompt unless > something like EARLY_ADOPTER=YES is set in make.conf or you're > building a 'release'. > > Would that be ok? So you will prompt them wiht a question that will make them ignore it and cut and paste it into a message and mail it off to a dozen lists screaming about it? If they can't manage to follow -stable or read the FAQ, what makes you think they will bother with reading the message you output with going into hysteria? They've already demonstrated a lack of reading ability or willingness or something. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - 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 Fri Mar 16 17:18:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 9CCAA37B718; Fri, 16 Mar 2001 17:18:45 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f2H1Ij701695; Fri, 16 Mar 2001 17:18:45 -0800 (PST) Date: Fri, 16 Mar 2001 17:18:45 -0800 From: Alfred Perlstein To: John Baldwin Cc: arch@FreeBSD.org, tlambert@primenet.com, drosih@rpi.edu, Jordan Hubbard Subject: Re: NO MORE '-BETA' Message-ID: <20010316171845.U29888@fw.wintelcom.net> References: <20010316170755.S29888@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Fri, Mar 16, 2001 at 05:15:35PM -0800 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * John Baldwin [010316 17:16] wrote: > > On 17-Mar-01 Alfred Perlstein wrote: > > * Jordan Hubbard [010316 16:44] wrote: > >> > Let's just add something to cvsup to prompt the user? Or something > >> > in the build process that's interactive? or what? > >> > >> How about turning it off to all but authorized users (those who have > >> a registered cvsup key, as on freefall) during release periods? > > > > The real pain is that there doesn't seem to be a way stop users from > > upgrading before they actually do it. > > > > I think what'll happen is that sometime tomorrow I'll add an option > > to newvers.sh to detect a cross version change and have the world > > and installworld and installkernel targets check and prompt unless > > something like EARLY_ADOPTER=YES is set in make.conf or you're > > building a 'release'. > > > > Would that be ok? > > So you will prompt them wiht a question that will make them ignore it > and cut and paste it into a message and mail it off to a dozen lists > screaming about it? If they can't manage to follow -stable or read the > FAQ, what makes you think they will bother with reading the message you > output with going into hysteria? They've already demonstrated a lack > of reading ability or willingness or something. Those people can go fly a kite. You stated that -BETA actually is a bit less stable than -STABLE and hence should be -BETA. The problem is that: THERE'S NO WARNING UNTIL YOU ACTUALLY BOOT WITH YOUR '-BETA' SYSTEM This would address it and also give us an excuse to make fun of the people that ask without reading what the make targets output. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 17:18:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 8AED537B71C for ; Fri, 16 Mar 2001 17:18:49 -0800 (PST) (envelope-from dima@unixfreak.org) Received: from spike.unixfreak.org (spike [192.168.2.4]) by bazooka.unixfreak.org (Postfix) with ESMTP id EA9083E1E; Fri, 16 Mar 2001 17:18:47 -0800 (PST) To: James Housley Cc: freebsd-arch@freebsd.org Subject: Re: Inherate nodump cause significant slow down of dump In-Reply-To: <3AB2B8BA.29C5E58E@thehousleys.net>; from jim@thehousleys.net on "Fri, 16 Mar 2001 20:07:06 -0500" Date: Fri, 16 Mar 2001 17:18:47 -0800 From: Dima Dorfman Message-Id: <20010317011847.EA9083E1E@bazooka.unixfreak.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG James Housley writes: > The changes to src/sbin/dump/traverse.c (1.10.2.2) cause significant > slow down of the dump estimate phase. Specifically Phase II. My /usr > partition has about 2.5G of data including ports. I had just the > /usr/ports director flagged as nodump. I think that this needs to be > backed out, or fixed before the 4.3-RELEASE. I'm not terribly opposed to this, but OTOH I don't see why it's necessary. The slowdown only occurs if you set nodump on a directory. With the old behavior, this wouldn't do anything useful (AFAIK), so if you have nodump on a directory, you probably expect the new behavior. The latter has a problem with taking more time than it should (I think it actually takes the same amount of time as dumping everything under the nodump'd directory would). In other words, the only thing that's broken is the new feature. > chflags nodump /usr/ports ; dump 0hsf 0 1048576 /dev/null /dev/ad0s1f > -- this takes 38 minutes to finish Phase II for version 1.10.2.1 of > src/sbin/dump/traverse.c ITYM 1.10.2.2 Regards Dima Dorfman dima@unixfreak.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 17:18:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ohm.physics.purdue.edu (ohm.physics.purdue.edu [128.210.146.32]) by hub.freebsd.org (Postfix) with ESMTP id AD8A337B719; Fri, 16 Mar 2001 17:18:55 -0800 (PST) (envelope-from will@physics.purdue.edu) Received: (from will@localhost) by ohm.physics.purdue.edu (8.11.2/8.9.3) id f2H1JHO86487; Fri, 16 Mar 2001 20:19:17 -0500 (EST) (envelope-from will@physics.purdue.edu) X-Authentication-Warning: ohm.physics.purdue.edu: will set sender to will@physics.purdue.edu using -f Date: Fri, 16 Mar 2001 20:19:17 -0500 From: Will Andrews To: "=?iso-8859-1?Q?Paul_Richards=FC?=" Cc: Chris Dillon , Kris Kennaway , Alfred Perlstein , Jim Mock , "Steve O'Hara-Smith" , arch@FreeBSD.ORG, j mckitrick , jkh@FreeBSD.ORG Subject: Re: More BETA evilness Re: BETA induced nervousness Message-ID: <20010316201917.G61859@ohm.physics.purdue.edu> Reply-To: Will Andrews Mail-Followup-To: Will Andrews , "=?iso-8859-1?Q?Paul_Richards=FC?=" , Chris Dillon , Kris Kennaway , Alfred Perlstein , Jim Mock , Steve O'Hara-Smith , arch@FreeBSD.ORG, j mckitrick , jkh@FreeBSD.ORG References: <3AB2B9F4.B772ED78@freebsd-services.co.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="qfqzlDW52eQCflvV" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AB2B9F4.B772ED78@freebsd-services.co.uk>; from paul@freebsd-services.co.uk on Sat, Mar 17, 2001 at 01:12:20AM +0000 X-Operating-System: FreeBSD 4.2-STABLE i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --qfqzlDW52eQCflvV Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 17, 2001 at 01:12:20AM +0000, Paul Richards=FC=0E wrote: > It doesn't seem like setting the OS version to beta gains us anything, > we might as well do Wrong. You obviously never tried building ports before only to discover that they break in strange ways because of stupid version checking configure scripts or otherwise. This was a real problem in the olden days. We still need to do this to catch other mistakes. IMO we still need something, but it need not be called BETA, it can be called PRERELEASE (which is what Kris suggested). --=20 wca --qfqzlDW52eQCflvV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.3 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6sruVF47idPgWcsURAlPSAJ9xPlQ69VND1SeFBtxmffwI7cWQ5QCfXa1I 9Nl4MSYr1sRKZvP3CNeQ340= =YR5u -----END PGP SIGNATURE----- --qfqzlDW52eQCflvV-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 17:23: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [62.232.68.68]) by hub.freebsd.org (Postfix) with ESMTP id E174037B718; Fri, 16 Mar 2001 17:23:01 -0800 (PST) (envelope-from paul@freebsd-services.co.uk) Received: from freebsd-services.co.uk (lobster.originative.co.uk [62.232.68.81]) by mailgate.originative.co.uk (Postfix) with ESMTP id 339051D149; Sat, 17 Mar 2001 01:23:00 +0000 (GMT) Message-ID: <3AB2BC97.6CCF6F6B@freebsd-services.co.uk> Date: Sat, 17 Mar 2001 01:23:35 +0000 From: Paul "=?iso-8859-1?Q?Richards=FC?=" X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Will Andrews Cc: Chris Dillon , Kris Kennaway , Alfred Perlstein , Jim Mock , Steve O'Hara-Smith , arch@FreeBSD.ORG, j mckitrick , jkh@FreeBSD.ORG Subject: Re: More BETA evilness Re: BETA induced nervousness References: <3AB2B9F4.B772ED78@freebsd-services.co.uk> <20010316201917.G61859@ohm.physics.purdue.edu> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Will Andrews wrote: > > On Sat, Mar 17, 2001 at 01:12:20AM +0000, Paul Richardsü wrote: > > It doesn't seem like setting the OS version to beta gains us anything, > > we might as well do > > Wrong. You obviously never tried building ports before only to discover > that they break in strange ways because of stupid version checking configure > scripts or otherwise. This was a real problem in the olden days. We > still need to do this to catch other mistakes. > > IMO we still need something, but it need not be called BETA, it can be > called PRERELEASE (which is what Kris suggested). Or ports fixing happens after the -release tag is laid. That seems more logical to me, finalise the OS then check all the ports work. It would also be the case that if ports were more portable across FreeBSD versions this would be less of any issue. Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 17:26:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from thehousleys.net (frenchknot.ne.mediaone.net [24.147.224.201]) by hub.freebsd.org (Postfix) with ESMTP id A178637B718 for ; Fri, 16 Mar 2001 17:26:23 -0800 (PST) (envelope-from jim@thehousleys.net) Received: (from root@localhost) by thehousleys.net (8.11.3/8.11.2) id f2H1QLY02633; Fri, 16 Mar 2001 20:26:21 -0500 (EST) (envelope-from jim@thehousleys.net) Received: from thehousleys.net (baby.int.thehousleys.net [192.168.0.24]) by thehousleys.net (8.11.3/8.11.3) with ESMTP id f2H1QJf02625; Fri, 16 Mar 2001 20:26:19 -0500 (EST) (envelope-from jim@thehousleys.net) Message-ID: <3AB2BD3B.7E65D416@thehousleys.net> Date: Fri, 16 Mar 2001 20:26:19 -0500 From: James Housley X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Dima Dorfman Cc: freebsd-arch@freebsd.org Subject: Re: Inherate nodump cause significant slow down of dump References: <20010317011847.EA9083E1E@bazooka.unixfreak.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-10 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dima Dorfman wrote: > > James Housley writes: > > The changes to src/sbin/dump/traverse.c (1.10.2.2) cause significant > > slow down of the dump estimate phase. Specifically Phase II. My /usr > > partition has about 2.5G of data including ports. I had just the > > /usr/ports director flagged as nodump. I think that this needs to be > > backed out, or fixed before the 4.3-RELEASE. > > I'm not terribly opposed to this, but OTOH I don't see why it's > necessary. The slowdown only occurs if you set nodump on a directory. > With the old behavior, this wouldn't do anything useful (AFAIK), so if > you have nodump on a directory, you probably expect the new behavior. > The latter has a problem with taking more time than it should (I think > it actually takes the same amount of time as dumping everything under > the nodump'd directory would). In other words, the only thing that's > broken is the new feature. > I haven't tested this yet, but should be able to tomorrow. But I believe that if I do chflags -R nodump /usr/ports it will not a significant more amount of time to process, throught Phase II, then with out the nodump flags under the old version. I am also guessing the with the new version chflags -R nodump /usr/ports will be about the same amount of time as with the old code. I am not opposed to the feature. Acutally I was suprised that that is not the way it worked when I first found the flag. However, there has to be a better way to implement it. BTW it breaks amanda's dump estimates. Jim -- /"\ ASCII Ribbon Campaign . \ / - NO HTML/RTF in e-mail . X - NO Word docs in e-mail . / \ ----------------------------------------------------------------- jeh@FreeBSD.org http://www.FreeBSD.org The Power to Serve jim@TheHousleys.Net http://www.TheHousleys.net --------------------------------------------------------------------- microsoft: "where do you want to go today?" linux: "where do you want to go tomorrow?" BSD: "are you guys coming, or what?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 17:26:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 951FE37B718 for ; Fri, 16 Mar 2001 17:26:43 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2H1PgG72093; Fri, 16 Mar 2001 17:25:42 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010316171845.U29888@fw.wintelcom.net> Date: Fri, 16 Mar 2001 17:25:55 -0800 (PST) From: John Baldwin To: Alfred Perlstein Subject: Re: NO MORE '-BETA' Cc: Jordan Hubbard , drosih@rpi.edu, tlambert@primenet.com, arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 17-Mar-01 Alfred Perlstein wrote: > * John Baldwin [010316 17:16] wrote: >> >> On 17-Mar-01 Alfred Perlstein wrote: >> > * Jordan Hubbard [010316 16:44] wrote: >> >> > Let's just add something to cvsup to prompt the user? Or something >> >> > in the build process that's interactive? or what? >> >> >> >> How about turning it off to all but authorized users (those who have >> >> a registered cvsup key, as on freefall) during release periods? >> > >> > The real pain is that there doesn't seem to be a way stop users from >> > upgrading before they actually do it. >> > >> > I think what'll happen is that sometime tomorrow I'll add an option >> > to newvers.sh to detect a cross version change and have the world >> > and installworld and installkernel targets check and prompt unless >> > something like EARLY_ADOPTER=YES is set in make.conf or you're >> > building a 'release'. >> > >> > Would that be ok? >> >> So you will prompt them wiht a question that will make them ignore it >> and cut and paste it into a message and mail it off to a dozen lists >> screaming about it? If they can't manage to follow -stable or read the >> FAQ, what makes you think they will bother with reading the message you >> output with going into hysteria? They've already demonstrated a lack >> of reading ability or willingness or something. > > Those people can go fly a kite. These are the same people who complained about -BETA that got you started off on this whole thread to begin with. Please pick one position and stick with it, K PLZ THX. > You stated that -BETA actually is a bit less stable than -STABLE and > hence should be -BETA. The problem is that: > THERE'S NO WARNING UNTIL YOU ACTUALLY BOOT WITH YOUR '-BETA' SYSTEM Sure there is, it's called the mailing list. If you cvsup -current there's also no warning until you boot with your -CURRENT system, although I see you kindly ignored my pointing that out last time. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - 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 Fri Mar 16 17:30:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 16EC737B718; Fri, 16 Mar 2001 17:30:22 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2H1TfG72201; Fri, 16 Mar 2001 17:29:41 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3AB2BC97.6CCF6F6B@freebsd-services.co.uk> Date: Fri, 16 Mar 2001 17:29:55 -0800 (PST) From: John Baldwin To: "Paul "@FreeBSD.ORG, "=?iso-8859-1?Q?Richards=FC?="@FreeBSD.ORG, " "@meow.osd.bsdi.com Subject: Re: More BETA evilness Re: BETA induced nervousness Cc: jkh@FreeBSD.org, j mckitrick , arch@FreeBSD.org, "Steve O'Hara-Smith" , Jim Mock , Alfred Perlstein , Kris Kennaway , Chris Dillon , Will Andrews Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 17-Mar-01 Paul "Richardsü wrote: > Will Andrews wrote: >> >> On Sat, Mar 17, 2001 at 01:12:20AM +0000, Paul Richardsü wrote: >> > It doesn't seem like setting the OS version to beta gains us anything, >> > we might as well do >> >> Wrong. You obviously never tried building ports before only to discover >> that they break in strange ways because of stupid version checking configure >> scripts or otherwise. This was a real problem in the olden days. We >> still need to do this to catch other mistakes. >> >> IMO we still need something, but it need not be called BETA, it can be >> called PRERELEASE (which is what Kris suggested). > > Or ports fixing happens after the -release tag is laid. Umm, Paul, we usually release ports with the release you know. Like, at the same time. > That seems more logical to me, finalise the OS then check all the ports > work. This is called a release candidate and a release cycle. We do this work _before_ the release goes out, not after. > It would also be the case that if ports were more portable across > FreeBSD versions this would be less of any issue. No silly. This isn't bsd.port.mk junk this is stupid configure scripts that have hard-coded checks on the output of uname. > Paul. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - 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 Fri Mar 16 17:32:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id A9F0737B719; Fri, 16 Mar 2001 17:32:19 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f2H1WA502159; Fri, 16 Mar 2001 17:32:10 -0800 (PST) Date: Fri, 16 Mar 2001 17:32:09 -0800 From: Alfred Perlstein To: John Baldwin Cc: Jordan Hubbard , drosih@rpi.edu, tlambert@primenet.com, arch@FreeBSD.org Subject: Re: NO MORE '-BETA' Message-ID: <20010316173209.W29888@fw.wintelcom.net> References: <20010316171845.U29888@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Fri, Mar 16, 2001 at 05:25:55PM -0800 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * John Baldwin [010316 17:26] wrote: > > On 17-Mar-01 Alfred Perlstein wrote: > > * John Baldwin [010316 17:16] wrote: > >> > >> On 17-Mar-01 Alfred Perlstein wrote: > >> > * Jordan Hubbard [010316 16:44] wrote: > >> >> > Let's just add something to cvsup to prompt the user? Or something > >> >> > in the build process that's interactive? or what? > >> >> > >> >> How about turning it off to all but authorized users (those who have > >> >> a registered cvsup key, as on freefall) during release periods? > >> > > >> > The real pain is that there doesn't seem to be a way stop users from > >> > upgrading before they actually do it. > >> > > >> > I think what'll happen is that sometime tomorrow I'll add an option > >> > to newvers.sh to detect a cross version change and have the world > >> > and installworld and installkernel targets check and prompt unless > >> > something like EARLY_ADOPTER=YES is set in make.conf or you're > >> > building a 'release'. > >> > > >> > Would that be ok? > >> > >> So you will prompt them wiht a question that will make them ignore it > >> and cut and paste it into a message and mail it off to a dozen lists > >> screaming about it? If they can't manage to follow -stable or read the > >> FAQ, what makes you think they will bother with reading the message you > >> output with going into hysteria? They've already demonstrated a lack > >> of reading ability or willingness or something. > > > > Those people can go fly a kite. > > These are the same people who complained about -BETA that got you started off > on this whole thread to begin with. Please pick one position and stick with > it, K PLZ THX. I am, my point is that it sucks. Normally just saying something sucks is frowned on, but I'm also giving some ways to fix it. > > You stated that -BETA actually is a bit less stable than -STABLE and > > hence should be -BETA. The problem is that: > > THERE'S NO WARNING UNTIL YOU ACTUALLY BOOT WITH YOUR '-BETA' SYSTEM > > Sure there is, it's called the mailing list. If you cvsup -current there's > also no warning until you boot with your -CURRENT system, although I see you > kindly ignored my pointing that out last time. Because it was a silly point, you need to explicitly modify your cvsup file to do so. Also, my "world target checking with newver.sh" solution would protect you from that as well. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 17:34:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from jasper.nighttide.net (jasper.nighttide.net [209.222.117.162]) by hub.freebsd.org (Postfix) with ESMTP id 9269437B718; Fri, 16 Mar 2001 17:34:28 -0800 (PST) (envelope-from darren@nighttide.net) Received: from localhost (darren@localhost) by jasper.nighttide.net (8.11.2/8.11.1) with ESMTP id f2H1Xxu10749; Fri, 16 Mar 2001 20:34:00 -0500 (EST) (envelope-from darren@nighttide.net) Date: Fri, 16 Mar 2001 20:33:59 -0500 (EST) From: Darren Henderson To: Kris Kennaway Cc: Jordan Hubbard , , , Subject: Re: NO MORE '-BETA' In-Reply-To: <20010315215349.A70879@mollari.cthul.hu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Mar 2001, Kris Kennaway wrote: > There have been several people on -questions and -stable confused and > worried about why they got a beta release instead of a stable snapshot > like they "asked for". I think we could stand to find a better name, > perhaps 4.3-PRERELEASE. If the lack of the stable is what is confusing them then perhaps it should stay. Is there a limit on the length of the tag? Something like 4.2-STABLE(4.3-TRANSITION) would be clearer if overly verbose. ______________________________________________________________________ Darren Henderson darren@nighttide.net Help fight junk e-mail, visit http://www.cauce.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 17:35:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [62.232.68.68]) by hub.freebsd.org (Postfix) with ESMTP id BE9A137B718; Fri, 16 Mar 2001 17:35:36 -0800 (PST) (envelope-from paul@freebsd-services.co.uk) Received: from freebsd-services.co.uk (lobster.originative.co.uk [62.232.68.81]) by mailgate.originative.co.uk (Postfix) with ESMTP id 84AC01D149; Sat, 17 Mar 2001 01:35:33 +0000 (GMT) Message-ID: <3AB2BF88.A2AF290F@freebsd-services.co.uk> Date: Sat, 17 Mar 2001 01:36:08 +0000 From: Paul "=?iso-8859-1?Q?Richards=FC?=" X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: John Baldwin Cc: Paul@originative.co.uk, "=?iso-8859-1?Q?Richards=FC?="@originative.co.uk, , @meow.osd.bsdi.com, jkh@FreeBSD.org, j mckitrick , arch@FreeBSD.org, Steve O'Hara-Smith , Jim Mock , Alfred Perlstein , Kris Kennaway , Chris Dillon , Will Andrews Subject: Re: More BETA evilness Re: BETA induced nervousness References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Baldwin wrote: > > On 17-Mar-01 Paul "Richardsü wrote: > > Will Andrews wrote: > >> > >> On Sat, Mar 17, 2001 at 01:12:20AM +0000, Paul Richardsü wrote: > >> > It doesn't seem like setting the OS version to beta gains us anything, > >> > we might as well do > >> > >> Wrong. You obviously never tried building ports before only to discover > >> that they break in strange ways because of stupid version checking configure > >> scripts or otherwise. This was a real problem in the olden days. We > >> still need to do this to catch other mistakes. > >> > >> IMO we still need something, but it need not be called BETA, it can be > >> called PRERELEASE (which is what Kris suggested). > > > > Or ports fixing happens after the -release tag is laid. > > Umm, Paul, we usually release ports with the release you know. Like, at the > same time. > > > That seems more logical to me, finalise the OS then check all the ports > > work. > > This is called a release candidate and a release cycle. We do this work > _before_ the release goes out, not after. Well yes I know that, but when the release goes out the door and when the -release tag is laid aren't the same thing. The ports tree doesn't get branched so we can branch the src, then check the ports, then roll the release. The only change is that there's a delay between tagging the src tree and the release actually being rolled while the ports are checked over. > > It would also be the case that if ports were more portable across > > FreeBSD versions this would be less of any issue. > > No silly. This isn't bsd.port.mk junk this is stupid configure scripts that > have hard-coded checks on the output of uname. Ok, I understand. Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 17:36:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 19CBA37B719 for ; Fri, 16 Mar 2001 17:36:11 -0800 (PST) (envelope-from jkh@osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.2/8.11.1) with ESMTP id f2H1Z3H91203; Fri, 16 Mar 2001 17:35:04 -0800 (PST) (envelope-from jkh@osd.bsdi.com) To: arch@FreeBSD.ORG, TrimYourCC@nuxi.com Cc: bright@wintelcom.net Subject: Re: NO MORE '-BETA' In-Reply-To: <20010316164457.A57253@hub.freebsd.org> References: <20010316134349.K29888@fw.wintelcom.net> <20010316163748Z.jkh@osd.bsdi.com> <20010316164457.A57253@hub.freebsd.org> X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010316173503T.jkh@osd.bsdi.com> Date: Fri, 16 Mar 2001 17:35:03 -0800 From: Jordan Hubbard X-Dispatcher: imput version 20000228(IM140) Lines: 28 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > This doesn't solve the ports problem as ports maintainers cannot use > bento for their own build testing. To take this approach puts us back in > the FORTRAN, punched cards, batch days. Sure they can, they can either just brute-force set the release string on their own machines as well or, since this is hardly rocket science, they can use the mechanisms already provided. From bsd.port.subdir.mk: .if !defined(OSREL) OSREL!= /usr/bin/uname -r | sed -e 's/[-(].*//' .endif .if !defined(OSVERSION) .if exists(/sbin/sysctl) OSVERSION!= /sbin/sysctl -n kern.osreldate .else OSVERSION!= /usr/sbin/sysctl -n kern.osreldate .endif As you can see, both OSREL and OSVERSION can be set in /etc/make.conf or the command line to override the default setting. Contrary to past belief, I'm also seeing that Satoshi doesn't like or need to do the package building well in advance - he prefers to wait until the last practical moment in order to get in all the changes he can before rolling stuff off bento for "production" purposes. The ports collection is big! - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 17:38:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 497BA37B718; Fri, 16 Mar 2001 17:38:19 -0800 (PST) (envelope-from jkh@osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.2/8.11.1) with ESMTP id f2H1bBH91225; Fri, 16 Mar 2001 17:37:12 -0800 (PST) (envelope-from jkh@osd.bsdi.com) To: bright@wintelcom.net Cc: jhb@FreeBSD.ORG, drosih@rpi.edu, tlambert@primenet.com, arch@FreeBSD.ORG Subject: Re: NO MORE '-BETA' In-Reply-To: <20010316170755.S29888@fw.wintelcom.net> References: <20010316140408.N29888@fw.wintelcom.net> <20010316164306W.jkh@osd.bsdi.com> <20010316170755.S29888@fw.wintelcom.net> X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010316173711J.jkh@osd.bsdi.com> Date: Fri, 16 Mar 2001 17:37:11 -0800 From: Jordan Hubbard X-Dispatcher: imput version 20000228(IM140) Lines: 3 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG That would be really gross. Have you lost your marbles? :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 17:43: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 4DF4537B719 for ; Fri, 16 Mar 2001 17:43:06 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2H1h4k09306; Fri, 16 Mar 2001 17:43:04 -0800 (PST) (envelope-from obrien) Date: Fri, 16 Mar 2001 17:43:04 -0800 From: "David O'Brien" To: Alfred Perlstein Cc: arch@FreeBSD.ORG Subject: Re: NO MORE '-BETA' Message-ID: <20010316174303.A9267@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <20010316134349.K29888@fw.wintelcom.net> <20010316163748Z.jkh@osd.bsdi.com> <20010316164457.A57253@hub.freebsd.org> <20010316170000.R29888@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010316170000.R29888@fw.wintelcom.net>; from bright@wintelcom.net on Fri, Mar 16, 2001 at 05:00:00PM -0800 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 X-Loop: FreeBSD.ORG On Fri, Mar 16, 2001 at 05:00:00PM -0800, Alfred Perlstein wrote: > Or teach the ports committers the way to bump newver.sh themselves. > A minor step that should be trivial for them to do. That is an inappropriate response, from someone that hacks their kernel daily. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 17:44:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-202.dsl.lsan03.pacbell.net [63.207.60.202]) by hub.freebsd.org (Postfix) with ESMTP id E52C437B719 for ; Fri, 16 Mar 2001 17:44:49 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 788A266B2E; Fri, 16 Mar 2001 17:44:49 -0800 (PST) Date: Fri, 16 Mar 2001 17:44:49 -0800 From: Kris Kennaway To: "Rodney W. Grimes" Cc: arch@FreeBSD.ORG Subject: Re: More BETA evilness Re: BETA induced nervousness Message-ID: <20010316174449.A7859@mollari.cthul.hu> References: <20010316142527.B1278@mollari.cthul.hu> <200103170105.RAA55369@gndrsh.dnsmgr.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103170105.RAA55369@gndrsh.dnsmgr.net>; from freebsd@gndrsh.dnsmgr.net on Fri, Mar 16, 2001 at 05:05:29PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Mar 16, 2001 at 05:05:29PM -0800, Rodney W. Grimes wrote: > As far as the ports system needing the version bump for testing, well > the ports build testing _SHOULD_ be done on a system built from the > release engineers BETA bits, which if you'd all read very carefully > what I said, WOULD have the VERSION bump. People who are testing the ports need their system to say 4.3 so they can reproduce results. People who are testing/using packages also need their system to say 4.3 so they can reproduce runtime results, and so they get the correct packages (pkg_add -r uses the version number to figure out what directory to download from). Since this involves a large segment of the user community, it's unfair to ask each of them to hack their sources locally. Kris --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6ssGRWry0BWjoQKURAmWTAJ9IjdRJnZWIKc536jPBSsNuA84/hwCfcyOg emBKPG+3lxkshe+L86HKWNs= =VeaL -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 17:46:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 7D64F37B719 for ; Fri, 16 Mar 2001 17:46:29 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2H1kRv09368; Fri, 16 Mar 2001 17:46:27 -0800 (PST) (envelope-from obrien) Date: Fri, 16 Mar 2001 17:46:27 -0800 From: "David O'Brien" To: Alfred Perlstein Cc: arch@FreeBSD.org Subject: Re: NO MORE '-BETA' Message-ID: <20010316174627.B9267@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org References: <20010316170755.S29888@fw.wintelcom.net> <20010316171845.U29888@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010316171845.U29888@fw.wintelcom.net>; from bright@wintelcom.net on Fri, Mar 16, 2001 at 05:18:45PM -0800 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 X-Loop: FreeBSD.ORG On Fri, Mar 16, 2001 at 05:18:45PM -0800, Alfred Perlstein wrote: > You stated that -BETA actually is a bit less stable than -STABLE and > hence should be -BETA. The problem is that: > THERE'S NO WARNING UNTIL YOU ACTUALLY BOOT WITH YOUR '-BETA' SYSTEM Ok, so now you've pissed off JKH so much he has nixed 4.4-{BETA,PRERELEASE,whatever}. Well, the potential bugginess of -STABLE right before release will still be there, but there will be nothing to alert the user about it. All you've done is removed valuable testing of Ports building. Thank you from the bottom of my heart. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX Disclaimer: Not speaking for FreeBSD, just expressing my own opinion. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 17:49:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id B3FF037B71C for ; Fri, 16 Mar 2001 17:49:54 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2H1nih09404; Fri, 16 Mar 2001 17:49:44 -0800 (PST) (envelope-from obrien) Date: Fri, 16 Mar 2001 17:49:44 -0800 From: "David O'Brien" To: Jordan Hubbard Cc: arch@freebsd.org Subject: Re: NO MORE '-BETA' Message-ID: <20010316174944.C9267@dragon.nuxi.com> Reply-To: arch@freebsd.org References: <20010316134349.K29888@fw.wintelcom.net> <20010316163748Z.jkh@osd.bsdi.com> <20010316164457.A57253@hub.freebsd.org> <20010316173503T.jkh@osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010316173503T.jkh@osd.bsdi.com>; from jkh@osd.bsdi.com on Fri, Mar 16, 2001 at 05:35:03PM -0800 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 X-Loop: FreeBSD.ORG On Fri, Mar 16, 2001 at 05:35:03PM -0800, Jordan Hubbard wrote: > Contrary to past belief, I'm also seeing that Satoshi doesn't like or > need to do the package building well in advance - he prefers to wait > until the last practical moment in order to get in all the changes he > can before rolling stuff off bento for "production" purposes. The > ports collection is big! I'm not sure that this paragraph applies to. Satoshi != Joe Randome Ports Maintainer (which I'm not saying you are stating). So I'm having trouble parsing this part. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 17:52: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 57AE137B718 for ; Fri, 16 Mar 2001 17:52:01 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2H1q0S09424 for arch@FreeBSD.ORG; Fri, 16 Mar 2001 17:52:00 -0800 (PST) (envelope-from obrien) Date: Fri, 16 Mar 2001 17:52:00 -0800 From: "David O'Brien" To: arch@FreeBSD.ORG Subject: Re: NO MORE '-BETA' Message-ID: <20010316175200.D9267@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <20010316134349.K29888@fw.wintelcom.net> <20010316163748Z.jkh@osd.bsdi.com> <20010316164457.A57253@hub.freebsd.org> <20010316173503T.jkh@osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010316173503T.jkh@osd.bsdi.com>; from jkh@osd.bsdi.com on Fri, Mar 16, 2001 at 05:35:03PM -0800 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 X-Loop: FreeBSD.ORG On Fri, Mar 16, 2001 at 05:35:03PM -0800, Jordan Hubbard wrote: > .if !defined(OSREL) > OSREL!= /usr/bin/uname -r | sed -e 's/[-(].*//' > .endif > .if !defined(OSVERSION) > .if exists(/sbin/sysctl) > OSVERSION!= /sbin/sysctl -n kern.osreldate > .else > OSVERSION!= /usr/sbin/sysctl -n kern.osreldate > .endif > > As you can see, both OSREL and OSVERSION can be set in /etc/make.conf > or the command line to override the default setting. So who is going to make it their responsibility to remind all the ports maintainers this at code freeze? The current way was a nice centralized way of keeping everyone on the same sheet of music. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX P.S. again, I would like to think the non-ports maintainers for their role in this thread from the bottom of my heart To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 17:57: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 5266337B718 for ; Fri, 16 Mar 2001 17:56:59 -0800 (PST) (envelope-from dima@unixfreak.org) Received: from spike.unixfreak.org (spike [192.168.2.4]) by bazooka.unixfreak.org (Postfix) with ESMTP id C47D03E1E; Fri, 16 Mar 2001 17:56:57 -0800 (PST) To: James Housley Cc: freebsd-arch@freebsd.org Subject: Re: Inherate nodump cause significant slow down of dump In-Reply-To: <3AB2BD3B.7E65D416@thehousleys.net>; from jim@thehousleys.net on "Fri, 16 Mar 2001 20:26:19 -0500" Date: Fri, 16 Mar 2001 17:56:55 -0800 From: Dima Dorfman Message-Id: <20010317015657.C47D03E1E@bazooka.unixfreak.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ Should this really be on -arch? ] James Housley writes: > Dima Dorfman wrote: > > I'm not terribly opposed to this, but OTOH I don't see why it's > > necessary. The slowdown only occurs if you set nodump on a directory. > > With the old behavior, this wouldn't do anything useful (AFAIK), so if > > you have nodump on a directory, you probably expect the new behavior. > > The latter has a problem with taking more time than it should (I think > > it actually takes the same amount of time as dumping everything under > > the nodump'd directory would). In other words, the only thing that's > > broken is the new feature. > > > > I haven't tested this yet, but should be able to tomorrow. But I > believe that if I do chflags -R nodump /usr/ports it will not a > significant more amount of time to process, throught Phase II, then with > out the nodump flags under the old version. I just tried it, and, as I suspected, it isn't the case. The slowdown is caused by the fact that for every directory with subdirectories and the nodump flag set, mapdirs returns 1, which causes it to be run again. You can test this theory by commenting out lines 250 and 251 in rev. 1.12 of traverse.c (this will fix the slowdown, but break everything else). > I am also guessing the with the new version chflags -R nodump /usr/ports > will be about the same amount of time as with the old code. I am not > opposed to the feature. Acutally I was suprised that that is not the > way it worked when I first found the flag. However, there has to be a > better way to implement it. dump's tree-walker is braindead. It can be implemented by adding another pass; I don't know if that will make it better or worse. If I can't fix this, I'll try that. > BTW it breaks amanda's dump estimates. Regardless of whether nodump is used on directories? Dima Dorfman dima@unixfreak.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 17:57:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 2D4C537B718 for ; Fri, 16 Mar 2001 17:57:37 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2H1vL309517; Fri, 16 Mar 2001 17:57:21 -0800 (PST) (envelope-from obrien) Date: Fri, 16 Mar 2001 17:57:21 -0800 From: "David O'Brien" To: "=?iso-8859-1?Q?Paul_Richards=FC?=" Cc: arch@FreeBSD.ORG Subject: Re: More BETA evilness Re: BETA induced nervousness Message-ID: <20010316175721.E9267@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <3AB2B9F4.B772ED78@freebsd-services.co.uk> <20010316201917.G61859@ohm.physics.purdue.edu> <3AB2BC97.6CCF6F6B@freebsd-services.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Mutt/1.2.5i In-Reply-To: <3AB2BC97.6CCF6F6B@freebsd-services.co.uk>; from paul@freebsd-services.co.uk on Sat, Mar 17, 2001 at 01:23:35AM +0000 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 X-Loop: FreeBSD.ORG On Sat, Mar 17, 2001 at 01:23:35AM +0000, Paul Richards=FC=0E wrote: > > IMO we still need something, but it need not be called BETA, it can be > > called PRERELEASE (which is what Kris suggested). >=20 > Or ports fixing happens after the -release tag is laid. So now I have to keep Yet Another FreeBSD box around to keep on the release branch for a while? Most ports maintains, test and build their ports on their own desktop. Thus many are tracking -STABLE; but in your scheme either have to go off on a side branch for awhile, then return to the -current branch. That can be a alot of effort, and I don't want to cause port maintainers to spend effort that could be used elsewhere. --=20 -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 18: 4:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 969A637B718 for ; Fri, 16 Mar 2001 18:04:40 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2H24X409626; Fri, 16 Mar 2001 18:04:33 -0800 (PST) (envelope-from obrien) Date: Fri, 16 Mar 2001 18:04:33 -0800 From: "David O'Brien" To: "=?iso-8859-1?Q?Paul_Richards=FC?=" Cc: arch@freebsd.org Subject: Re: More BETA evilness Re: BETA induced nervousness Message-ID: <20010316180433.G9267@dragon.nuxi.com> Reply-To: arch@freebsd.org References: <3AB2BF88.A2AF290F@freebsd-services.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Mutt/1.2.5i In-Reply-To: <3AB2BF88.A2AF290F@freebsd-services.co.uk>; from paul@freebsd-services.co.uk on Sat, Mar 17, 2001 at 01:36:08AM +0000 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 X-Loop: FreeBSD.ORG On Sat, Mar 17, 2001 at 01:36:08AM +0000, Paul Richards=FC=0E wrote: > Well yes I know that, but when the release goes out the door and when > the -release tag is laid aren't the same thing. The ports tree doesn't > get branched so we can branch the src, then check the ports, then roll > the release. Who the heck do you think is going to do this check. Would you please go do `find /usr/ports -type f | xargs grep MAINTAINER | sort | uniq' and see the number of people involved. =46rom your past three emails, I can see you just don't get how things work. For the past many releases I've pushed to have newvers.sh edited early, we have fixed many problems early in the Ports Collection that before caused some packages to not make it into the release. The current practice exists for a reason, is liked by every Ports Committer I've talked to, and solves problems. Before you come out with this again, become a Ports Committer and see how most work before you tell us how to do our jobs. --=20 -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX Disclaimer: Not speaking for FreeBSD, just expressing my own opin= ion. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 18: 8:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from thehousleys.net (frenchknot.ne.mediaone.net [24.147.224.201]) by hub.freebsd.org (Postfix) with ESMTP id 6EB6E37B71A for ; Fri, 16 Mar 2001 18:08:39 -0800 (PST) (envelope-from jim@thehousleys.net) Received: (from root@localhost) by thehousleys.net (8.11.3/8.11.2) id f2H28RM03594; Fri, 16 Mar 2001 21:08:27 -0500 (EST) (envelope-from jim@thehousleys.net) Received: from thehousleys.net (baby.int.thehousleys.net [192.168.0.24]) by thehousleys.net (8.11.3/8.11.3) with ESMTP id f2H28Of03586; Fri, 16 Mar 2001 21:08:25 -0500 (EST) (envelope-from jim@thehousleys.net) Message-ID: <3AB2C718.B31B29C3@thehousleys.net> Date: Fri, 16 Mar 2001 21:08:24 -0500 From: James Housley X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Dima Dorfman Cc: freebsd-arch@freebsd.org Subject: Re: Inherate nodump cause significant slow down of dump References: <20010317015657.C47D03E1E@bazooka.unixfreak.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-10 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dima Dorfman wrote: > > [ Should this really be on -arch? ] > > James Housley writes: > > Dima Dorfman wrote: > > > I'm not terribly opposed to this, but OTOH I don't see why it's > > > necessary. The slowdown only occurs if you set nodump on a directory. > > > With the old behavior, this wouldn't do anything useful (AFAIK), so if > > > you have nodump on a directory, you probably expect the new behavior. > > > The latter has a problem with taking more time than it should (I think > > > it actually takes the same amount of time as dumping everything under > > > the nodump'd directory would). In other words, the only thing that's > > > broken is the new feature. > > > > > > > I haven't tested this yet, but should be able to tomorrow. But I > > believe that if I do chflags -R nodump /usr/ports it will not a > > significant more amount of time to process, throught Phase II, then with > > out the nodump flags under the old version. > > I just tried it, and, as I suspected, it isn't the case. The slowdown > is caused by the fact that for every directory with subdirectories and > the nodump flag set, mapdirs returns 1, which causes it to be run > again. You can test this theory by commenting out lines 250 and 251 > in rev. 1.12 of traverse.c (this will fix the slowdown, but break > everything else). Okay. > > > I am also guessing the with the new version chflags -R nodump /usr/ports > > will be about the same amount of time as with the old code. I am not > > opposed to the feature. Acutally I was suprised that that is not the > > way it worked when I first found the flag. However, there has to be a > > better way to implement it. > > dump's tree-walker is braindead. It can be implemented by adding > another pass; I don't know if that will make it better or worse. If I > can't fix this, I'll try that. > Talking about 1.12 traverse.c, about line #160 in mapfiles() /* * All dirs go in dumpdirmap; only inodes that are to * be dumped go in usedinomap and dumpinomap, however. */ if (mode == IFDIR) SETINO(ino, dumpdirmap); ------------------------^^^^^^^^^^^^^^^^^^^^^^^^ if (WANTTODUMP(dp)) { SETINO(ino, usedinomap); SETINO(ino, dumpinomap); if (mode != IFREG && mode != IFDIR && mode != IFLNK) *tapesize += 1; else *tapesize += blockest(dp); continue; } if (mode == IFDIR) anydirskipped = 1; Why is a directory added without checking for the nodump flag? Because isn't then just removed later in mapdirs()? Wouldn't this work better? I don't fully understand all the code yet, but I am looking. /* * All dirs go in dumpdirmap; only inodes that are to * be dumped go in usedinomap and dumpinomap, however. */ if (mode == IFDIR) - SETINO(ino, dumpdirmap); + if (WANTTODUMP(dp)) + SETINO(ino, dumpdirmap); + else { + anydirskipped = 1; + continue; + } if (WANTTODUMP(dp)) { SETINO(ino, usedinomap); SETINO(ino, dumpinomap); if (mode != IFREG && mode != IFDIR && mode != IFLNK) *tapesize += 1; else *tapesize += blockest(dp); continue; } if (mode == IFDIR) anydirskipped = 1; Jim -- /"\ ASCII Ribbon Campaign . \ / - NO HTML/RTF in e-mail . X - NO Word docs in e-mail . / \ ----------------------------------------------------------------- jeh@FreeBSD.org http://www.FreeBSD.org The Power to Serve jim@TheHousleys.Net http://www.TheHousleys.net --------------------------------------------------------------------- If it happens once, it's a bug. If it happens twice, it's a feature. If it happens more than twice, it's windows. -- Luiz de Barros To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 18:10:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id C894837B718 for ; Fri, 16 Mar 2001 18:10:43 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2H2Abd09678; Fri, 16 Mar 2001 18:10:37 -0800 (PST) (envelope-from obrien) Date: Fri, 16 Mar 2001 18:10:36 -0800 From: "David O'Brien" To: Dima Dorfman Cc: James Housley , freebsd-arch@freebsd.org Subject: Re: Inherate nodump cause significant slow down of dump Message-ID: <20010316181036.H9267@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <3AB2B8BA.29C5E58E@thehousleys.net> <20010317011847.EA9083E1E@bazooka.unixfreak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010317011847.EA9083E1E@bazooka.unixfreak.org>; from dima@unixfreak.org on Fri, Mar 16, 2001 at 05:18:47PM -0800 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 X-Loop: FreeBSD.ORG On Fri, Mar 16, 2001 at 05:18:47PM -0800, Dima Dorfman wrote: > I'm not terribly opposed to this, but OTOH I don't see why it's > necessary. Agreed. > The slowdown only occurs if you set nodump on a directory. ..snip.. > In other words, the only thing that's broken is the new feature. I guess I need to read the report again. I don't see where there is a bug. There is a great slowdown in operating time -- ie a performance nit, but no bug. But as you said, if you want -h; you have to spend the time processing. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 18:15: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 5A0B537B718 for ; Fri, 16 Mar 2001 18:15:00 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2H2EDG73186; Fri, 16 Mar 2001 18:14:13 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010316173209.W29888@fw.wintelcom.net> Date: Fri, 16 Mar 2001 18:14:27 -0800 (PST) From: John Baldwin To: Alfred Perlstein Subject: Re: NO MORE '-BETA' Cc: arch@FreeBSD.org, tlambert@primenet.com, drosih@rpi.edu, Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 17-Mar-01 Alfred Perlstein wrote: > * John Baldwin [010316 17:26] wrote: >> >> On 17-Mar-01 Alfred Perlstein wrote: >> > * John Baldwin [010316 17:16] wrote: >> >> >> >> On 17-Mar-01 Alfred Perlstein wrote: >> >> > * Jordan Hubbard [010316 16:44] wrote: >> >> >> > Let's just add something to cvsup to prompt the user? Or something >> >> >> > in the build process that's interactive? or what? >> >> >> >> >> >> How about turning it off to all but authorized users (those who have >> >> >> a registered cvsup key, as on freefall) during release periods? >> >> > >> >> > The real pain is that there doesn't seem to be a way stop users from >> >> > upgrading before they actually do it. >> >> > >> >> > I think what'll happen is that sometime tomorrow I'll add an option >> >> > to newvers.sh to detect a cross version change and have the world >> >> > and installworld and installkernel targets check and prompt unless >> >> > something like EARLY_ADOPTER=YES is set in make.conf or you're >> >> > building a 'release'. >> >> > >> >> > Would that be ok? >> >> >> >> So you will prompt them wiht a question that will make them ignore it >> >> and cut and paste it into a message and mail it off to a dozen lists >> >> screaming about it? If they can't manage to follow -stable or read the >> >> FAQ, what makes you think they will bother with reading the message you >> >> output with going into hysteria? They've already demonstrated a lack >> >> of reading ability or willingness or something. >> > >> > Those people can go fly a kite. >> >> These are the same people who complained about -BETA that got you started >> off >> on this whole thread to begin with. Please pick one position and stick with >> it, K PLZ THX. > > I am, my point is that it sucks. Normally just saying something sucks > is frowned on, but I'm also giving some ways to fix it. No you are switching positions. First, we have to remove all mention of -BETA to be nice to people, and now you say that those same people can "go fly a kite". Why not tell them that when they complained about -BETA? >> > You stated that -BETA actually is a bit less stable than -STABLE and >> > hence should be -BETA. The problem is that: >> > THERE'S NO WARNING UNTIL YOU ACTUALLY BOOT WITH YOUR '-BETA' SYSTEM >> >> Sure there is, it's called the mailing list. If you cvsup -current there's >> also no warning until you boot with your -CURRENT system, although I see you >> kindly ignored my pointing that out last time. > > Because it was a silly point, you need to explicitly modify your > cvsup file to do so. Or use the wrong one because you didn't read the docco. The only people who are confused about -BETA are the ones who haven't bothered to read the release schedule posted to -stable or the entry in the FAQ, so they are just as likely the same people who cvsup current accidentally due to lack of reading docco. > Also, my "world target checking with newver.sh" solution would protect > you from that as well. It will annoy those who already know what they are doing, and it won't do any good for those who don't because if they are this far along w/o knowing they obviously aren't reading the docco. If they didn't read it the first time, they aren't going to read it the 10th. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - 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 Fri Mar 16 18:15: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 6031837B719 for ; Fri, 16 Mar 2001 18:15:04 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2H2EEG73189; Fri, 16 Mar 2001 18:14:14 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010316173503T.jkh@osd.bsdi.com> Date: Fri, 16 Mar 2001 18:14:29 -0800 (PST) From: John Baldwin To: Jordan Hubbard Subject: Re: NO MORE '-BETA' Cc: bright@wintelcom.net, arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 17-Mar-01 Jordan Hubbard wrote: >> This doesn't solve the ports problem as ports maintainers cannot use >> bento for their own build testing. To take this approach puts us back in >> the FORTRAN, punched cards, batch days. > > Sure they can, they can either just brute-force set the release string > on their own machines as well or, since this is hardly rocket science, > they can use the mechanisms already provided. From bsd.port.subdir.mk: > > .if !defined(OSREL) > OSREL!= /usr/bin/uname -r | sed -e 's/[-(].*//' > .endif > .if !defined(OSVERSION) > .if exists(/sbin/sysctl) > OSVERSION!= /sbin/sysctl -n kern.osreldate > .else > OSVERSION!= /usr/sbin/sysctl -n kern.osreldate > .endif > > As you can see, both OSREL and OSVERSION can be set in /etc/make.conf > or the command line to override the default setting. Actually, the biggest problem in the past has been configure scripts which call uname directly and try to parse the output, so setting OSREL or OSVERSION doesn't help at all there. :) For that you need to tweak newvers.sh in your own kernel. Plus, you need to do it for your the ports cluster so it can run through the ports generating error logs people can look at and try to get fixes in before the final build is done. Just committing it to the tree is a rather simple way of achieving all of this. It would be nice to also know how many people are confused vs. how many people _aren't_ confused. If 2% of our -stable userbase doesn't get it, then I'm not sure that is justification for axeing it. This is even documented and announced on the lists for crying out loud. :) -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - 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 Fri Mar 16 18:19:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [62.232.68.68]) by hub.freebsd.org (Postfix) with ESMTP id DA73A37B71A for ; Fri, 16 Mar 2001 18:19:47 -0800 (PST) (envelope-from paul@freebsd-services.co.uk) Received: from freebsd-services.co.uk (lobster.originative.co.uk [62.232.68.81]) by mailgate.originative.co.uk (Postfix) with ESMTP id E8D5C1D149 for ; Sat, 17 Mar 2001 02:19:46 +0000 (GMT) Message-ID: <3AB2C9E6.263459AE@freebsd-services.co.uk> Date: Sat, 17 Mar 2001 02:20:22 +0000 From: Paul Richards X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: arch@freebsd.org Subject: Re: More BETA evilness Re: BETA induced nervousness References: <3AB2BF88.A2AF290F@freebsd-services.co.uk> <20010316180433.G9267@dragon.nuxi.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David O'Brien wrote: > > On Sat, Mar 17, 2001 at 01:36:08AM +0000, Paul Richardsü wrote: > > Well yes I know that, but when the release goes out the door and when > > the -release tag is laid aren't the same thing. The ports tree doesn't > > get branched so we can branch the src, then check the ports, then roll > > the release. > > Who the heck do you think is going to do this check. Would you please go > do `find /usr/ports -type f | xargs grep MAINTAINER | sort | uniq' and see > the number of people involved. If the idea of dropping -beta was adopted then the timing of the release would change so that the src tree was branched some time before the actual release date so that there is time for ports to be checked. Some change in our release procedures would be required to support this way of working, but it's only a proposal. Everyone in this project is allowed to offer proposals. There's no reason to shout it down just because it's not how things are done at the moment. > From your past three emails, I can see you just don't get how things > work. For the past many releases I've pushed to have newvers.sh edited > early, we have fixed many problems early in the Ports Collection that > before caused some packages to not make it into the release. The current > practice exists for a reason, is liked by every Ports Committer I've > talked to, and solves problems. > > Before you come out with this again, become a Ports Committer and see how > most work before you tell us how to do our jobs. I am a ports committer. Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 19: 0:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id BAE9237B718 for ; Fri, 16 Mar 2001 19:00:47 -0800 (PST) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (monica.cs.rpi.edu [128.213.7.2]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id WAA92623; Fri, 16 Mar 2001 22:00:43 -0500 (EST) Message-Id: <200103170300.WAA92623@cs.rpi.edu> To: Terry Lambert Cc: crossd@cs.rpi.edu (David E. Cross), freebsd-arch@FreeBSD.ORG, crossd@cs.rpi.edu Subject: Re: idle wonderings about 'struct pcred' In-Reply-To: Message from Terry Lambert of "Fri, 16 Mar 2001 19:57:38 GMT." <200103161957.MAA16801@usr02.primenet.com> Date: Fri, 16 Mar 2001 22:00:43 -0500 From: "David E. Cross" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Good idea. I have been pushing for something like this for years. Heh... and I was about to get the asbestos undies on. Good to know I am not totally insane in all of my musings :) > > It would let you "preauthenticate" (ala a "password cache" on > login, or an explicit "add credential for XXX" program) for things > like per user authentication for an SMB or Appletalk client, on > a per user basis (most SMBFS implementations are useless, because > they do not offer per user security, unless you are using a single > user client OS like Windows). *nod*, This was the exact type of idea that I had in mind. > The next neat step would be a "session manager", which would sit > on an fd listening for "new credential needed" requests from the > kernel, and interrogating the user. > > For example, you could have a KDE program that sat there and waited, > and when the user tried to access a password protected file, a network > share, /dev/io, the CDROM, tape backup unit, mount an FS as someone > other than root, or whatever, it could pop up a dialog and say: > I have no idea even how to begin that part. How would 'sessiond' know which terminal to forward the request to? Could it even know that 'terminal' is an xterm on a remote machine? What if the user is logged in multiple times (on console in the office, and also from home). What I had in mind in the short term is a series of utility programs (like klog for afs) that would add the required auth data (via syscalls) to the proc structure. And various parts of the kernel would update the structure as they progressed. To use the kerberos example... :) the PAM module krb5 auths the user, gets the TGT and hands it off to the kernel. The filesystem layer accesses the auth structure for auth data of type PCRED_AUTH_KRB5, and service filesystem/HOST@REALM. Not finding it, it would do whatever it takes to get it (alert the user, issue the krb requests itself, whatever) and issue the commands to the krb5 auth module to insert the new key. This last step implies that the auth modules within the kernel will have some sort of API. This is clearly needed, but I would not consider any sort of standard API since the various methods differ so dramatically in the type of data and how it is handled. What does need to be standardized is a method of reference counting and sharing data among proc structures (apparently the current method has some of this, not sure of the details yet). -- David Cross | email: crossd@cs.rpi.edu Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 19: 9:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id 80B7137B718 for ; Fri, 16 Mar 2001 19:09:15 -0800 (PST) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (monica.cs.rpi.edu [128.213.7.2]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id WAA92739; Fri, 16 Mar 2001 22:09:12 -0500 (EST) Message-Id: <200103170309.WAA92739@cs.rpi.edu> To: Jack Rusher Cc: "David E. Cross" , freebsd-arch@freebsd.org, crossd@cs.rpi.edu Subject: Re: idle wonderings about 'struct pcred' In-Reply-To: Message from Jack Rusher of "Fri, 16 Mar 2001 11:59:34 PST." <3AB270A6.77ADBBBD@integratus.com> Date: Fri, 16 Mar 2001 22:09:11 -0500 From: "David E. Cross" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I think something like what you have proposed is pretty reasonable. I >would say that more would be required to make this useful. My >discussion will be constrained to PKI as part of kernel. I think the power in this is that it is 'useless'. That is to say that this is just a method for placing and identifying authentication information in the kernel, and leaving everything else up to the authors of the authentication modules. We do need some basic set of APIs (to do reference counting, etc... see email to Terry Lambert), but we need to keep this as minimal as possible. > > After you have a means to store a public/private key pair in the >kernel you will need to provide a syscall like interface to the service >that uses the credential that is stored in the kernel. Something like: > > o login gets key pair from new /etc/passwd (or whatever), uses >password typed by user to unencrypt 3DES'd private key, verifies that >the key really has been unlocked by using the public/private key pair to >encrypt and decrypt a message, stores private key in pcred for use by >later syscalls. > > o Later programs use a syscall interface to to sign, unencrypt, etc, >by calling a ksign_message(...) style routine. > > You would need to avoid any syscall interface that allows the user to >fetch the unlocked private key from kernel space. Otherwise, any >program the user runs can snatch a password equivalent and store it for >later. > > What this functionally means is that you would need to make a generic >crypto services API at the kernel level and use loadable modules to >support the algorithms you are interested in. This means moving a lot >of openssl into kernel space. This is daunting for most people. > > I want to see this happen to support an NIS replacement I am working >on right now. I would want to see the kernel crypto API published and >lobbied to the other BSDs & Linux so that we would be able to write >portable applications that expect kernel crypto support. > > How many other people are interested in something like this? Does >everyone else think we should just use PAM and get over it? :-) Everything that you have listed here would be implemented in an auth module. I certainly would be interested in a NIS replacement. I wouldn't worry about it conflicting with PAM, they answer fundamentally different questions. PAM is a method for authenticating a user/service. NIS and its cousins is a method of distributing database type information. The way computers work there is some overlap between PAM and NIS (I need to know user 'X's password, I look it up in some form of database). -- David Cross | email: crossd@cs.rpi.edu Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 19:11: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 147C437B719; Fri, 16 Mar 2001 19:11:07 -0800 (PST) (envelope-from nectar@nectar.com) Received: by gw.nectar.com (Postfix, from userid 1001) id 8588B1938A; Fri, 16 Mar 2001 21:11:06 -0600 (CST) Date: Fri, 16 Mar 2001 21:11:06 -0600 From: "Jacques A. Vidrine" To: John Baldwin Cc: arch@FreeBSD.org Subject: Re: NO MORE '-BETA' Message-ID: <20010316211106.A34611@spawn.nectar.com> References: <20010316173503T.jkh@osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Fri, Mar 16, 2001 at 06:14:29PM -0800 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Mar 16, 2001 at 06:14:29PM -0800, John Baldwin wrote: > If 2% of our -stable userbase doesn't get it, then I'm not sure that > is justification for axeing it. This is even documented and announced > on the lists for crying out loud. :) Along these lines ... am I the only one who thinks that the branch _needs_ to be called BETA at this time? With all the MFCs that inevitably hit near release, a little more caution than usual is required by those tracking -STABLE. IMHO, of course. Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 19:48:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 0D72337B718 for ; Fri, 16 Mar 2001 19:48:07 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id UAA01564; Fri, 16 Mar 2001 20:42:28 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp05.primenet.com, id smtpdAAAx1a4bd; Fri Mar 16 20:42:26 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id UAA03669; Fri, 16 Mar 2001 20:47:58 -0700 (MST) From: Terry Lambert Message-Id: <200103170347.UAA03669@usr05.primenet.com> Subject: Re: man pages/more formal def enable_intr/disable_intr/restore_intr To: mjacob@feral.com Date: Sat, 17 Mar 2001 03:47:48 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), arch@FreeBSD.ORG In-Reply-To: from "Matthew Jacob" at Mar 16, 2001 04:59:30 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG MUCH better! > 1. Formal Definition > > disable_intr: Disables interrupts being dispatched to at least the calling > CPU. Returns an intrmask_t (should probably be an opaque type) > to be possibly used in a future call to restore_intr. -------------- which can be > restore_intr: Restores the state prior to the call to disable_intr such that > the calling CPU now can have interrupts dispatched to it. ------- - will now , if the state prior to the call had interrupts enabled. [ this assumes that there are no pareameters, and it's nestable, which may be better state explicitly; if it's like splx, then a different description might be better... ] > > enable_intr: Irrespective of any prior state, enables interrupts to be > dispatched to the calling CPU. > > (this narrows things down) Yep. > Does this help? If not, just leave it noted that I'm not satisfying you and > we'll move on. [ ... ] It's nearly perfect. It will keep someone in x86 land from shooting the Alpha people in the foot, and will keep the Alpha people from doing something that might require a big firefight in order to do a SPARC or some other port. It's exactly what the doctor ordered. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 19:48:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail-100baset.rpi.edu [128.113.26.45]) by hub.freebsd.org (Postfix) with ESMTP id CF94237B718 for ; Fri, 16 Mar 2001 19:48:20 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id WAA26182; Fri, 16 Mar 2001 22:48:19 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20010316160957.A98966@dragon.nuxi.com> References: <20010316151120.B98051@dragon.nuxi.com> <200103162339.QAA18793@usr07.primenet.com> <20010316160957.A98966@dragon.nuxi.com> Date: Fri, 16 Mar 2001 22:48:16 -0500 To: arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: NO MORE '-BETA' Cc: arch@FreeBSD.ORG, Terry Lambert Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 4:09 PM -0800 3/16/01, David O'Brien wrote: >Uh all other OS's I know of use these same terms -- Beta is >right before a release, during a time annoying bugs can be >fixed. Release Candidate is pretty self-explanatory, nor >did we invent it. I would say that for most companies, the above is the "marketing definition" of beta. Ie, it's what the marketing department would like to claim. Please note that there are several million computer users who are very familiar with the following definitions of 'beta', as described in the 'jargon' dictionary: 1. Mostly working, but still under test. Beta releases are generally made to a group of lucky (or unlucky) trusted customers. 2. Anything that is new and experimental. "His girlfriend is in beta" means that he is still testing for compatibility and reserving judgment. 3. Flaky; dubious; suspect (since beta software is notoriously buggy). You may not LIKE those definitions, but those are the most common meanings that real users pick up from the word "beta". By the above definitions, there isn't really all THAT much more "beta" about 4.3-beta than there was in an average day of 4.2-stable. Note that isn't just that we're using the word "beta", but that we STOPPED labelling it as "stable". The problem with claiming that "freebsd's cycle is just like any other company", is that other companies do NOT have the equivalent of "stable". When Windows98 went into beta, it had several million lines of coding changes which had not been tested on any customers machines. THAT is what they mean by beta. We mean "there is something of a code-freeze going on in the life of -stable". When Windows98 went beta, it meant that Microsoft was within six months of releasing the real version. We mean we're within four weeks of it. Apple had their public-beta of MacOS 10 -- last September. The final candidate will be available in a week. There are areas where the final release will look and work quite a bit different than the beta. The difference between the first day of 4.3-beta and the final 4.3-release is about two orders of magnitude less dramatic. I'm not saying these because I'm mad at anyone. Those are just observations of the real world. That is how "beta" is used. >So maybe you should have said something to the effect that even >though 100% of the OSs today have "Betas" the 99% of the user >population is totally clueless as to these words meanings. So, we should pander to the 1% of users who are using your definitions, instead of the 99% of users who are familiar with the above definitions? And the benefit would be, .... what???? -- Garance Alistair Drosehn = gad@eclipse.acs.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 Fri Mar 16 19:49:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail-100baset.rpi.edu [128.113.26.45]) by hub.freebsd.org (Postfix) with ESMTP id 9F24937B719; Fri, 16 Mar 2001 19:49:55 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id WAA44120; Fri, 16 Mar 2001 22:49:54 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Fri, 16 Mar 2001 22:49:52 -0500 To: John Baldwin From: Garance A Drosihn Subject: Re: NO MORE '-BETA' Cc: Alfred Perlstein , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 2:31 PM -0800 3/16/01, John Baldwin wrote: >On 16-Mar-01 Chris Faulhaber wrote: > > On Fri, Mar 16, 2001 at 01:59:36PM -0800, John Baldwin wrote: > >> Is this in the FAQ yet? > >> >> >> http://www.FreeBSD.org/FAQ/admin.html#RELEASE-CANDIDATE > >Woo, cool. Then it seems people aren't using the resources >normally available to them either in the form of mailing lists >or the FAQ. I'm not sure we need to sacrifice our release >engineering process for the sake of people doing cvsup upgrades >that can't be bothered to either read the mailing lists or look >in the FAQ. :( Why don't we call it 4.3-crash-and-burn, but "just document it in the FAQ"? Why *must* we persist in using a word that has a very definite (and unpalatable) meaning in most computer contexts? In what way are we "sacrificing" the release engineering process? Is Jordan going to get lost unless he sees the word 'beta' when he works on testing? I understand the advantage of having SOME different name for this period, but why must it be 'beta' and no other combination of letters? I do not see how the freebsd release process could be corrupted by using some other term instead of 'beta'. There is no technical advantage to using that particular combination of letters. If it confuses some of our users, and holds no specific benefit to any other of our users, then why not change it? -- Garance Alistair Drosehn = gad@eclipse.acs.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 Fri Mar 16 20: 0:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from thehousleys.net (frenchknot.ne.mediaone.net [24.147.224.201]) by hub.freebsd.org (Postfix) with ESMTP id 0A3B137B718 for ; Fri, 16 Mar 2001 20:00:45 -0800 (PST) (envelope-from jim@thehousleys.net) Received: (from root@localhost) by thehousleys.net (8.11.3/8.11.2) id f2H40ZU04977; Fri, 16 Mar 2001 23:00:35 -0500 (EST) (envelope-from jim@thehousleys.net) Received: from thehousleys.net (baby.int.thehousleys.net [192.168.0.24]) by thehousleys.net (8.11.3/8.11.3) with ESMTP id f2H40Xf04969; Fri, 16 Mar 2001 23:00:33 -0500 (EST) (envelope-from jim@thehousleys.net) Message-ID: <3AB2E161.949AE10C@thehousleys.net> Date: Fri, 16 Mar 2001 23:00:33 -0500 From: James Housley X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Dima Dorfman Cc: freebsd-arch@freebsd.org Subject: Re: Inherate nodump cause significant slow down of dump References: <20010317015657.C47D03E1E@bazooka.unixfreak.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-10 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I see that my suggested code below won't work because we are pasring the tree in inode number instead of a depth traversal of the tree. I know with out inheriting the nodump flag the code would beable to read from the disk much faster in sequential order. Maybe what we now need is a second verion of mapfiles() that does a depth traversal of the tree iff dump is called with -h. This will be quicker then the current if a directory actually has the nodump flag set, but will be slower (hopefully not much) if there is no nodump flag. With the depth traversal processing can stop when a directory is found that is flaged as no dump. A second copy of mapdirs() might also be needed. Jim > > Why is a directory added without checking for the nodump flag? Because > isn't then just removed later in mapdirs()? Wouldn't this work better? > I don't fully understand all the code yet, but I am looking. > > /* > * All dirs go in dumpdirmap; only inodes that are to > * be dumped go in usedinomap and dumpinomap, however. > */ > if (mode == IFDIR) > - SETINO(ino, dumpdirmap); > + if (WANTTODUMP(dp)) > + SETINO(ino, dumpdirmap); > + else { > + anydirskipped = 1; > + continue; > + } > if (WANTTODUMP(dp)) { > SETINO(ino, usedinomap); > SETINO(ino, dumpinomap); > if (mode != IFREG && mode != IFDIR && mode != IFLNK) > *tapesize += 1; > else > *tapesize += blockest(dp); > continue; > } > if (mode == IFDIR) > anydirskipped = 1; > > > Jim -- /"\ ASCII Ribbon Campaign . \ / - NO HTML/RTF in e-mail . X - NO Word docs in e-mail . / \ ----------------------------------------------------------------- jeh@FreeBSD.org http://www.FreeBSD.org The Power to Serve jim@TheHousleys.Net http://www.TheHousleys.net --------------------------------------------------------------------- If it happens once, it's a bug. If it happens twice, it's a feature. If it happens more than twice, it's windows. -- Luiz de Barros To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 20:16:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail-100baset.rpi.edu [128.113.26.45]) by hub.freebsd.org (Postfix) with ESMTP id 3AA5F37B71A; Fri, 16 Mar 2001 20:16:20 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id XAA47072; Fri, 16 Mar 2001 23:16:19 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Fri, 16 Mar 2001 23:16:16 -0500 To: John Baldwin , Jordan Hubbard From: Garance A Drosihn Subject: Re: NO MORE '-BETA' Cc: arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 6:14 PM -0800 3/16/01, John Baldwin wrote: >On 17-Mar-01 Jordan Hubbard wrote: > > As you can see, both OSREL and OSVERSION can be set in > > /etc/make.conf or the command line to override the > > default setting. > >Actually, the biggest problem in the past has been configure >scripts which call uname directly and try to parse the output, >so setting OSREL or OSVERSION doesn't help at all there. :) > >Just committing it to the tree is a rather simple way of >achieving all of this. For what it's worth, I am 100% convinced that it is very worthwhile that SOME kind of name-change occur at the point that we currently change to -beta. I do believe there are very practical and worthwhile benefits. >It would be nice to also know how many people are confused >vs. how many people _aren't_ confused. If 2% of our >-stable userbase doesn't get it, then I'm not sure that is >justification for axeing it. I do not want to axe it. I just want to use a different combination of letters. There is no one who has given a TECHNICAL reason that we must use the specific four letters of 'beta' to denote this stage in the release cycle. Many good reasons (IMO) have been offered for why SOME name change should occur, but not one as to why those specific letters must be used. I think we can benefit (or at least, reassure) that tiny 2% of our user population without doing one single bit of harm in any way, shape or form to the other 98%. We can change from using "beta" to using "pre-release" by typing in about two dozen letters. If it takes so little effort to improve something for even 0.2% of our users, without hurting any of the rest of our users, then why would we not JUST DO IT? Why are we expending tens of thousands of characters arguing about it? -- Garance Alistair Drosehn = gad@eclipse.acs.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 Fri Mar 16 20:22:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id C0EEF37B718; Fri, 16 Mar 2001 20:22:11 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id UAA55781; Fri, 16 Mar 2001 20:22:08 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200103170422.UAA55781@gndrsh.dnsmgr.net> Subject: Re: Proposal for the CPU interrupt API In-Reply-To: <200103162138.f2GLc8d74959@earth.backplane.com> from Matt Dillon at "Mar 16, 2001 01:38:08 pm" To: dillon@earth.backplane.com (Matt Dillon) Date: Fri, 16 Mar 2001 20:22:07 -0800 (PST) Cc: jhb@FreeBSD.ORG (John Baldwin), arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :Every committer should be slapped on the hand every time they make a > :commit that changes source code that does not update the related > :documentation (man page or otherwise). ^^^^^^^^^^^^^^^^^^^^^^^ and by otherwise I included comments in code. Take this one for example: From sys/i386/isa/if_sr.c /* * XXX Disable all interrupts for now. I think if you are using the * dmac you don't use these interrupts. */ SRC_PUT8(hc->sca_base, msci->ie0, 0); SRC_PUT8(hc->sca_base, msci->ie1, 0x0C); writting 0x0C to msci->ie1 does NOT disable all interrupts!!! > : > :5 slapps on the hand and a commit bit should be suspended. Three > :suspensions and it should be revoked. > : > :The excuse that they don't know how to deal with nroff and mandoc is > :not really acceptable. They can always inlist the help of those that > :do understand these things, and hold the commit until both parts are > :ready. > : > :Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net > > Well, the problem is that only 1% of the kernel interfaces are > documented with man pages. So if you are requiring every single committer > working on the kernel to go and check to see if a man 9 section exists > for some of the dozens of files they just touched, well, I'm afraid that > is a bit over the top. FreeBSD's committers have historically *NOT* > done that, so depending on it now is a bad idea. It just won't happen. > This isn't to say that man 9 pages are useless... but I would say that > they are not as useful in an environment that is changing as quickly > as -current is. On the otherhand, documenting the procedures in the > source itself is a whole lot easier for the committers to do. It > represents a relatively small burden instead of a large one, which means > that the source code comments wind up being more up to date and more > complete. > > -Matt > > -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 20:25: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 415A737B718; Fri, 16 Mar 2001 20:25:06 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id VAA00726; Fri, 16 Mar 2001 21:21:42 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpdAAAa9aywb; Fri Mar 16 21:21:37 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id VAA04684; Fri, 16 Mar 2001 21:24:52 -0700 (MST) From: Terry Lambert Message-Id: <200103170424.VAA04684@usr05.primenet.com> Subject: Re: More BETA evilness Re: BETA induced nervousness To: will@physics.purdue.edu Date: Sat, 17 Mar 2001 04:24:42 +0000 (GMT) Cc: paul@freebsd-services.co.uk (=?iso-8859-1?Q?Paul_Richards=FC??=), cdillon@wolves.k12.mo.us (Chris Dillon), kris@obsecurity.org (Kris Kennaway), bright@wintelcom.net (Alfred Perlstein), mij@osdn.com (Jim Mock), steveo@eircom.net (Steve O'Hara-Smith), arch@FreeBSD.ORG, jcm@FreeBSD-uk.eu.org (j mckitrick), jkh@FreeBSD.ORG In-Reply-To: <20010316201917.G61859@ohm.physics.purdue.edu> from "Will Andrews" at Mar 16, 2001 08:19:17 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG If you were Microsoft, you'd call it "EA" for "Early Availability", or the marketing-speak term "PREVIEW". Actually, I like the idea of riding on their marketing of the word "PREVIEW", since they've spent the money, time, and energy to make people think they are getting a special deal to be beta testers... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 20:32: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 610B037B71C for ; Fri, 16 Mar 2001 20:32:03 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=9c7d65ecb1023802277cda8c86002542) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14e8OE-0000EY-00; Fri, 16 Mar 2001 21:32:30 -0700 Message-ID: <3AB2E8DE.CEBC23D9@softweyr.com> Date: Fri, 16 Mar 2001 21:32:30 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Jordan Hubbard Cc: bright@wintelcom.net, arch@FreeBSD.ORG Subject: Re: NO MORE '-BETA' References: <20010315201500.A2484@troutmask.apl.washington.edu> <20010316071040.V29888@fw.wintelcom.net> <20010316104124Z.jkh@osd.bsdi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jordan Hubbard wrote: > > > Ok, so we have reports of confusion on the mailing lists, usenet and > > IRC. Jordan, where can I pick up a set those blinders you have on? > > Chill, Albert. I think we've already established that a) It's the > newvers.sh "BETAness" that's really freaking people out and b) That > you've yet to supply any practical name alternative, you're just > whining about it at this point. DELTA, GAMMA, OMICRON, or OMEGA. And I though bikeshed arguments were stoopid. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 20:40:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail-100baset.rpi.edu [128.113.26.45]) by hub.freebsd.org (Postfix) with ESMTP id 112C237B718; Fri, 16 Mar 2001 20:40:57 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id XAA64404; Fri, 16 Mar 2001 23:40:55 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20010316211106.A34611@spawn.nectar.com> References: <20010316173503T.jkh@osd.bsdi.com> <20010316211106.A34611@spawn.nectar.com> Date: Fri, 16 Mar 2001 23:40:53 -0500 To: John Baldwin From: Garance A Drosihn Subject: Re: NO MORE '-BETA' Cc: arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 9:11 PM -0600 3/16/01, Jacques A. Vidrine wrote: >Along these lines ... am I the only one who thinks that >the branch _needs_ to be called BETA at this time? Speaking only for myself, I do not think there is any need for it to be called 'beta'. Not when we're just going from one release of stable into the next one. Stable also breaks when it is not in this "beta stage" of the release cycle. Problems during beta? Yes, occasionally. Unusually serious ones? No. -- Garance Alistair Drosehn = gad@eclipse.acs.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 Fri Mar 16 21: 3:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail-100baset.rpi.edu [128.113.26.45]) by hub.freebsd.org (Postfix) with ESMTP id 4411437B71C for ; Fri, 16 Mar 2001 21:03:08 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id AAA21118 for ; Sat, 17 Mar 2001 00:03:07 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: <20010316151120.B98051@dragon.nuxi.com> <200103162339.QAA18793@usr07.primenet.com> <20010316160957.A98966@dragon.nuxi.com> Date: Sat, 17 Mar 2001 00:03:06 -0500 To: arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: Some more '-BETA', but not for -STABLE Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 10:48 PM -0500 3/16/01, Garance A Drosihn wrote: >The problem with claiming that "freebsd's cycle is just like >any other company", is that other companies do NOT have the >equivalent of "stable". When Windows98 went into beta, it >had several million lines of coding changes which had not >been tested on any customers machines. THAT is what they >mean by beta. We mean "there is something of a code-freeze >going on in the life of -stable". Something of a revelation hit me. Okay now, stop yawning. The issue with comparing OS releases between freebsd and standard OS companies is exactly that those companies do not really have anything like -stable and current. What *WE* call "freebsd-current" is (in practice) very close to what a company like Microsoft or Apple would call a "beta release". From this comes the thought: In the release cycle of a *-CURRENT-* branch, we definitely SHOULD call it "beta" as we are get close to releasing it. I will have absolutely no misgivings when it comes time for freebsd-current to turn into 5.0-beta. In that case, it IS beta. We DO want more people using it than would usually use -current, but IT IS STILL BETA. It has a lot of very dramatic changes in it wrt -stable, and people SHOULD be wary of it. I (for one) do not have the same feeling when 4.2-stable turned into 4.3-beta. While there is some rush to MFC things for release, the rate of change isn't really all that much different than it is on any other day in the life of stable. In fact, as we get further into 4.3-beta, the code in that branch is changing LESS rapidly than usual, as the "code slush" turns into a code freeze. The more this is discussed, the more I think it is just plain wrong to use the same term for the "pre-release" of a minor version as we also use for the TRULY BETA release of a major version. So I think the life of a major branch should be, eg: 5.0-current 5.0-beta 5.0-release-candidate [1,2,3,4,...] 5.0-release 5.0-stable 5.1-pre-release (or 5.1-preview, or 5.1-precursor) 5.1-release 5.1-stable How does this sound to people? C'mon. At least stop yawning. -- Garance Alistair Drosehn = gad@eclipse.acs.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 Fri Mar 16 21:44:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from tongue.purplefrog.com (tongue.purplefrog.com [63.209.2.84]) by hub.freebsd.org (Postfix) with ESMTP id 074B337B71A for ; Fri, 16 Mar 2001 21:44:25 -0800 (PST) (envelope-from jar@integratus.com) Received: from integratus.com (adsl-64-164-192-194.dsl.snfc21.pacbell.net [64.164.192.194]) by tongue.purplefrog.com (8.9.1/8.9.1) with ESMTP id AAA13099; Sat, 17 Mar 2001 00:43:46 -0500 Message-ID: <3AB2F994.8F64924@integratus.com> Date: Fri, 16 Mar 2001 21:43:48 -0800 From: Jack Rusher X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "David E. Cross" Cc: freebsd-arch@freebsd.org Subject: Re: idle wonderings about 'struct pcred' References: <200103170309.WAA92739@cs.rpi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "David E. Cross" wrote: > > authentication modules. We do need some basic set of APIs (to do > reference counting, etc... see email to Terry Lambert), but we need to Sure, I see the design philosophy that you have in mind for this. It should work well for what you have in mind, but might not do what I need. > I certainly would be interested in a NIS replacement. I wouldn't worry > about it conflicting with PAM, they answer fundamentally different questions. > PAM is a method for authenticating a user/service. NIS and its cousins is > a method of distributing database type information. The way computers work > there is some overlap between PAM and NIS (I need to know user 'X's password, > I look it up in some form of database). I wasn't suggesting PAM was a replacement for NIS. I was asking whether people would be interested in having additional auth information in the kernel, or whether they would rather see all such things constrained to PAM modules. Some of the services I would like to use with my network authentication system include a novel network filesystem layer that doesn't have a trust model that implicitly assumes client kernels are telling the truth. This may require kernel access to PKI routines to work properly--that's why I am considering a model that allows loadable crypto modules to be accessed directly from the kernel. Thanks, Jack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 16 22:38:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 3F92037B719 for ; Fri, 16 Mar 2001 22:38:37 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2H6cYg11651; Fri, 16 Mar 2001 22:38:34 -0800 (PST) (envelope-from obrien) Date: Fri, 16 Mar 2001 22:38:34 -0800 From: "David O'Brien" To: Garance A Drosihn Cc: arch@FreeBSD.ORG Subject: Re: NO MORE '-BETA' Message-ID: <20010316223834.A11575@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from drosih@rpi.edu on Fri, Mar 16, 2001 at 10:49:52PM -0500 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 X-Loop: FreeBSD.ORG On Fri, Mar 16, 2001 at 10:49:52PM -0500, Garance A Drosihn wrote: > In what way are we "sacrificing" the release engineering process? > Is Jordan going to get lost unless he sees the word 'beta' when > he works on testing? You think Jordan is the only person testing the release?? The release engineering process isn't just Jordan either. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 0:29:26 2001 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 C8F6B37B719 for ; Sat, 17 Mar 2001 00:29:23 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f2H8TJ124430; Sat, 17 Mar 2001 09:29:19 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Kris Kennaway Cc: Peter Pentchev , arch@FreeBSD.ORG Subject: Re: add MD5Chunk(filename, .., offset, length) to libmd In-Reply-To: Your message of "Fri, 16 Mar 2001 14:24:23 PST." <20010316142423.A1278@mollari.cthul.hu> Date: Sat, 17 Mar 2001 09:29:19 +0100 Message-ID: <24428.984817759@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010316142423.A1278@mollari.cthul.hu>, Kris Kennaway writes: >I'm not claiming you didn't write at least some of that code, but >libmd as it stands today clearly has a large amount in common with >OpenSSL. Look at the CVS history, OK ? -- 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 Sat Mar 17 0:32:27 2001 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 82E5137B719 for ; Sat, 17 Mar 2001 00:32:25 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f2H8WJ124539; Sat, 17 Mar 2001 09:32:19 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Jordan Hubbard Cc: kris@obsecurity.org, roam@orbitel.bg, arch@FreeBSD.ORG Subject: Re: add MD5Chunk(filename, .., offset, length) to libmd In-Reply-To: Your message of "Fri, 16 Mar 2001 16:27:11 PST." <20010316162711S.jkh@osd.bsdi.com> Date: Sat, 17 Mar 2001 09:32:19 +0100 Message-ID: <24537.984817939@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010316162711S.jkh@osd.bsdi.com>, Jordan Hubbard writes: >libmd was innovative? Hmmm. We ARE inflating things a bit now, >aren't we. :) Well, at least back then a lot of people didn't see the point so it must have been :-) I think it is already established that your threshold for "innovative" is way out... -- 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 Sat Mar 17 1:56:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-202.dsl.lsan03.pacbell.net [63.207.60.202]) by hub.freebsd.org (Postfix) with ESMTP id 70B2937B71A for ; Sat, 17 Mar 2001 01:56:43 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id C9B5D66B25; Sat, 17 Mar 2001 01:56:42 -0800 (PST) Date: Sat, 17 Mar 2001 01:56:42 -0800 From: Kris Kennaway To: Poul-Henning Kamp Cc: Kris Kennaway , Peter Pentchev , arch@FreeBSD.ORG Subject: Re: add MD5Chunk(filename, .., offset, length) to libmd Message-ID: <20010317015642.A13218@mollari.cthul.hu> References: <20010316142423.A1278@mollari.cthul.hu> <24428.984817759@critter> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <24428.984817759@critter>; from phk@critter.freebsd.dk on Sat, Mar 17, 2001 at 09:29:19AM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 17, 2001 at 09:29:19AM +0100, Poul-Henning Kamp wrote: > In message <20010316142423.A1278@mollari.cthul.hu>, Kris Kennaway writes: >=20 > >I'm not claiming you didn't write at least some of that code, but > >libmd as it stands today clearly has a large amount in common with > >OpenSSL. >=20 > Look at the CVS history, OK ? I did, prior to sending that mail. Like I said, you wrote part of that code, but a lot of it came from OpenSSL. Kris --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6szTWWry0BWjoQKURArndAKCkfJ0hO6X3kd+WVcgK7TGPAGyuGACfW7zW O5oW9HgD9hcMBt2LzCpz4kk= =Syww -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 2: 2:22 2001 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 14F9537B71C for ; Sat, 17 Mar 2001 02:02:18 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f2HA2E125863; Sat, 17 Mar 2001 11:02:14 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Kris Kennaway Cc: Peter Pentchev , arch@FreeBSD.ORG Subject: Re: add MD5Chunk(filename, .., offset, length) to libmd In-Reply-To: Your message of "Sat, 17 Mar 2001 01:56:42 PST." <20010317015642.A13218@mollari.cthul.hu> Date: Sat, 17 Mar 2001 11:02:14 +0100 Message-ID: <25861.984823334@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010317015642.A13218@mollari.cthul.hu>, Kris Kennaway writes: > >--r5Pyd7+fXNt84Ff3 >Content-Type: text/plain; charset=us-ascii >Content-Disposition: inline >Content-Transfer-Encoding: quoted-printable > >On Sat, Mar 17, 2001 at 09:29:19AM +0100, Poul-Henning Kamp wrote: >> In message <20010316142423.A1278@mollari.cthul.hu>, Kris Kennaway writes: >>=20 >> >I'm not claiming you didn't write at least some of that code, but >> >libmd as it stands today clearly has a large amount in common with >> >OpenSSL. >>=20 >> Look at the CVS history, OK ? > >I did, prior to sending that mail. Like I said, you wrote part of >that code, but a lot of it came from OpenSSL. Could be, I'm not disputing that, I was merely pointing out that in this case we know that the egg came before the hen... -- 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 Sat Mar 17 2:56:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from logatome.francenet.fr (logatome-2.francenet.fr [193.149.96.2]) by hub.freebsd.org (Postfix) with ESMTP id 0F2EF37B718; Sat, 17 Mar 2001 02:56:11 -0800 (PST) (envelope-from e-masson@kisoft-services.com) Received: from notbsdems.nantes.kisoft-services.com (pppA144.francenet.fr [193.149.100.54]) by logatome.francenet.fr (8.10.1/8.11.1) with ESMTP id f2HAsQV99973; Sat, 17 Mar 2001 11:54:34 +0100 (CET) Received: by notbsdems.nantes.kisoft-services.com (Postfix, from userid 1001) id E9403E6C90; Sat, 17 Mar 2001 11:42:52 +0100 (CET) To: Alfred Perlstein Cc: Jim Mock , "Steve O'Hara-Smith" , arch@FreeBSD.ORG, j mckitrick , jkh@FreeBSD.ORG Subject: Re: More BETA evilness Re: BETA induced nervousness References: <20010316214210.5a3dc591.steveo@eircom.net> <20010316160949.A3791@guinness.osdn.com> <20010316134113.I29888@fw.wintelcom.net> From: Eric Masson In-Reply-To: <20010316134113.I29888@fw.wintelcom.net> (Alfred Perlstein's message of "Fri, 16 Mar 2001 13:41:13 -0800") Date: 17 Mar 2001 11:42:52 +0100 Message-ID: <86bsr07k2b.fsf@notbsdems.nantes.kisoft-services.com> Lines: 30 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Alfred" == Alfred Perlstein writes: Alfred> My current solution is instead of -BETA have -STABLE-RC, the Alfred> '-RC' is there to give knowledgeable people a heads-up and the Alfred> '-STABLE' is prominent enough to reduce the amount of concern. Don't you think that the same question will appear again & again "I'm tracking STABLE, what the h... is STABLE-RC", it probably won't be as frequent as with the BETA tag, but IMHO it will last. The real problem with the BETA tag is that we meet more and more users that cvsup their installs without really understanding what they're doing, It's soooo harassing to read the manuals . It would be interesting to post an expunged version of the faq on cubfm as already stated, and in -questions as well on a regular basis. A technical answer to a human problem has never been the best one you can find, but I'll try anyway. What about a selective access to cvsup while release cycle, (whether it's controlled from cvsup servers or make.conf has no interest here), is this way interesting enough ? Eric Masson -- A noter que si on a installé Macsbug, on peut avoir accès à une fenêtre bien plus grande, bourrée d'information passionnantes, en couleur et clickodrome. Et tout pour planter geekement son Mac. -+- Ol. in Guide du Macounet Pervers : Savez-vous planter des choux..-+- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 6:21:44 2001 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 7B14837B71A; Sat, 17 Mar 2001 06:21:40 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id PAA73186; Sat, 17 Mar 2001 15:21:35 +0100 (CET) (envelope-from des@ofug.org) 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: "Rodney W. Grimes" Cc: chat@FreeBSD.org Subject: Re: More BETA evilness Re: BETA induced nervousness References: <200103170105.RAA55369@gndrsh.dnsmgr.net> From: Dag-Erling Smorgrav Date: 17 Mar 2001 15:21:33 +0100 In-Reply-To: "Rodney W. Grimes"'s message of "Fri, 16 Mar 2001 17:05:29 -0800 (PST)" Message-ID: Lines: 9 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Rodney W. Grimes" writes: > A rose is a rose by any other name... "That which we call a rose / by any other name would smell as sweet", you acultural git. 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 Sat Mar 17 7:20:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id B02CE37B71A; Sat, 17 Mar 2001 07:20:18 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=4e7a02b09227bf69bdcc79d1e1386543) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14eHte-0007Bw-00; Sat, 17 Mar 2001 07:41:34 -0700 Message-ID: <3AB3779E.6A448E9@softweyr.com> Date: Sat, 17 Mar 2001 07:41:34 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Kris Kennaway Cc: Terry Lambert , Alfred Perlstein , arch@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: More BETA evilness Re: BETA induced nervousness References: <20010316134113.I29888@fw.wintelcom.net> <200103162300.QAA17472@usr07.primenet.com> <20010316155307.A41507@citusc17.usc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kris Kennaway wrote: > > On Fri, Mar 16, 2001 at 11:00:56PM +0000, Terry Lambert wrote: > > > -METASTABLE > > I actually like this one: metastable means "stable, but may > spontaneously transition to something else at any point without > warning" which is a pretty good description of what happens during the > early phases of code freeze :-) > > Probably a bit too technical for most users, though :-) Given the path this discussion has taken, it seem OBVIOUS TO THE MOST CASUAL OBSERVER the "one true tag" must be "-BIKESHED". Now, if we could move the discussion back to fixing the actual problem, instead of just renaming the problem. a) STABLE users have been told they can keep up to date on STABLE by cvsupping RELENG_X (where X is currently 4). b) This is not true, that only gets them -STABLE when -STABLE is the top of the RELENG branch. c) "BETA" is not really "STABLE". During the BETA phase, we often introduce short-term instability in the process of adding some functionality for the next release. This is a necessary and desirable phase of development, and lasts for a short period of time. d) How can we produce a "STABLE" cvsup target that gets only the -STABLE bits, i.e. "stalls" during the BETA phase and then begins advancing again at RELEASE? Thank you. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 7:20:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 47F6437B71A for ; Sat, 17 Mar 2001 07:20:45 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=5b9c7b101962985aa8677c7e0ffbcb7b) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14eHXH-0007BX-00; Sat, 17 Mar 2001 07:18:27 -0700 Message-ID: <3AB37233.2B2B3C45@softweyr.com> Date: Sat, 17 Mar 2001 07:18:27 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: arch@FreeBSD.ORG Subject: Re: NO MORE '-BETA' References: <200103162250.PAA17018@usr07.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > > So either quit doing '2' or use a variant of > > > Terry's suggestion '-stable-rc' > > > > > > ~ % uname -srm > > > FreeBSD 4.3-STABLE-RC i386 > > > > Except that it's not a real release candidate. Which is why we don't > > just use -RC the whole time. -RC means that we would actually feel > > confident releasing that exact source on the CD's as foo-RELEASE. > > This is not true for foo-BETA, as it is a time for people to test > > stuff out and spot things that need to be fixed. > > So what's the difference in tags between a release candidate and > a beta? The real problem here is that the user isn't really asking (or cvsupping) "-STABLE", they're really asking for "RELENG_4" and have been told that is synonymous with "-STABLE". Is there some way we can produce a "STABLE" tag that tracks the head of the RELENG branch up to BETA, sticks there until the release cycle has finished, then moves to the RELEASE point and advances again? > ..."Beta" is well known to be a synonym for "my cat wrote the > floppy disk driver"... If only we were so lucky. He's a great programmer, but far too lazy to write open source device drivers. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 7:44:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nebula.cybercable.fr (d217.dhcp212-126.cybercable.fr [212.198.126.217]) by hub.freebsd.org (Postfix) with ESMTP id 39CEC37B718 for ; Sat, 17 Mar 2001 07:44:39 -0800 (PST) (envelope-from mux@qualys.com) Received: (from mux@localhost) by nebula.cybercable.fr (8.11.3/8.11.3) id f2HFiBq05616 for arch@FreeBSD.org; Sat, 17 Mar 2001 16:44:11 +0100 (CET) (envelope-from mux) Date: Sat, 17 Mar 2001 16:44:11 +0100 From: Maxime Henrion To: arch@FreeBSD.org Subject: Proposal for a new syscall Message-ID: <20010317164411.A420@nebula.cybercable.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, While I was writing a network application, I was thinking that it would be nice to have a syscall that could "bind" two file descriptors, of any type (socket, file...), a bit like funopen() does in the libc. Having such a syscall in the kernel would allow to implement "zero-copy" wherever it is feasible. Then, sendfile() would just be a particular case of this syscall, where the input fd is a file and the output fd is a socket, and it could be rewritten using it. Do you think this makes sense and it would be useful to have ? Just my $0.02, Maxime -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code Key fingerprint = F9B6 1D5A 4963 331C 88FC CA6A AB50 1EF2 8CBE 99D6 Public Key : http://www.epita.fr/~henrio_m/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 7:50:21 2001 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 A7D3237B718 for ; Sat, 17 Mar 2001 07:50:18 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id QAA73518; Sat, 17 Mar 2001 16:50:16 +0100 (CET) (envelope-from des@ofug.org) 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: Maxime Henrion Cc: arch@FreeBSD.ORG Subject: Re: Proposal for a new syscall References: <20010317164411.A420@nebula.cybercable.fr> From: Dag-Erling Smorgrav Date: 17 Mar 2001 16:50:16 +0100 In-Reply-To: Maxime Henrion's message of "Sat, 17 Mar 2001 16:44:11 +0100" Message-ID: Lines: 23 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Maxime Henrion writes: > While I was writing a network application, I was thinking that it would > be nice to have a syscall that could "bind" two file descriptors, of any > type (socket, file...), a bit like funopen() does in the libc. You don't seem to understand what funopen() really does... > Having > such a syscall in the kernel would allow to implement "zero-copy" > wherever it is feasible. No. It would save you two copies and a bunch of syscalls, but it wouldn't be real zero-copy, just "n-2 copy" instead of "n copy". > Then, sendfile() would just be a particular case of this syscall, where > the input fd is a file and the output fd is a socket, and it could be > rewritten using it. No. Have you looked at the sendfile() code? 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 Sat Mar 17 8:35:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nebula.cybercable.fr (d217.dhcp212-126.cybercable.fr [212.198.126.217]) by hub.freebsd.org (Postfix) with ESMTP id 0F08737B718 for ; Sat, 17 Mar 2001 08:35:12 -0800 (PST) (envelope-from mux@qualys.com) Received: (from mux@localhost) by nebula.cybercable.fr (8.11.3/8.11.3) id f2HGYjf05956; Sat, 17 Mar 2001 17:34:45 +0100 (CET) (envelope-from mux) Date: Sat, 17 Mar 2001 17:34:44 +0100 From: Maxime Henrion To: arch@FreeBSD.org Cc: des@ofug.org Subject: Re: Proposal for a new syscall Message-ID: <20010317173444.B420@nebula.cybercable.fr> References: <20010317164411.A420@nebula.cybercable.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from des@ofug.org on Sat, Mar 17, 2001 at 04:50:16PM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > Maxime Henrion writes: > > While I was writing a network application, I was thinking that it would > > be nice to have a syscall that could "bind" two file descriptors, of any > > type (socket, file...), a bit like funopen() does in the libc. > You don't seem to understand what funopen() really does... I think I do, since I already used it successfully. Look at how it is used in libfetch (AFAIK, you are the author of libfetch, I'm not sure if you wrote this part though), it's given a read function to read the socket and a write function that will then write this into a file, and this is used to download a file. I would like to do the same thing but with the read/write functions done in the kernel so that it can be optimized, and with any type of fd (not just from a socket to a file, or from a file to a socket like sendfile() does). Something like : int foo(int fdin, int fdout, off_t offset, size_t nbytes); > > Having > > such a syscall in the kernel would allow to implement "zero-copy" > > wherever it is feasible. > No. It would save you two copies and a bunch of syscalls, but it > wouldn't be real zero-copy, just "n-2 copy" instead of "n copy". And if n == 2 ? It sounds like it would definitely be useful anyway, no ? :-) > > Then, sendfile() would just be a particular case of this syscall, where > > the input fd is a file and the output fd is a socket, and it could be > > rewritten using it. > No. Have you looked at the sendfile() code? Probably not enough ; however I don't understand why it wouldn't be possible to write a more generic function than sendfile() dealing with any type of file descriptors that sendfile() could call then. Maxime -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code Key fingerprint = F9B6 1D5A 4963 331C 88FC CA6A AB50 1EF2 8CBE 99D6 Public Key : http://www.epita.fr/~henrio_m/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 9: 7:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 948C237B719 for ; Sat, 17 Mar 2001 09:07:48 -0800 (PST) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f2HH4Im97804; Sat, 17 Mar 2001 11:04:18 -0600 (CST) (envelope-from jlemon) Date: Sat, 17 Mar 2001 11:04:18 -0600 From: Jonathan Lemon To: Maxime Henrion Cc: arch@FreeBSD.ORG Subject: Re: Proposal for a new syscall Message-ID: <20010317110418.Z82645@prism.flugsvamp.com> References: <20010317164411.A420@nebula.cybercable.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20010317164411.A420@nebula.cybercable.fr> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Mar 17, 2001 at 04:44:11PM +0100, Maxime Henrion wrote: > Hello, > > While I was writing a network application, I was thinking that it would > be nice to have a syscall that could "bind" two file descriptors, of any > type (socket, file...), a bit like funopen() does in the libc. Having > such a syscall in the kernel would allow to implement "zero-copy" > wherever it is feasible. > > Then, sendfile() would just be a particular case of this syscall, where > the input fd is a file and the output fd is a socket, and it could be > rewritten using it. > > Do you think this makes sense and it would be useful to have ? Yes, but it is decidedly non-trivial to implement. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 9:18:35 2001 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 A111337B719 for ; Sat, 17 Mar 2001 09:18:31 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id SAA73983; Sat, 17 Mar 2001 18:18:29 +0100 (CET) (envelope-from des@ofug.org) 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: Maxime Henrion Cc: arch@FreeBSD.org Subject: Re: Proposal for a new syscall References: <20010317164411.A420@nebula.cybercable.fr> <20010317173444.B420@nebula.cybercable.fr> From: Dag-Erling Smorgrav Date: 17 Mar 2001 18:18:28 +0100 In-Reply-To: Maxime Henrion's message of "Sat, 17 Mar 2001 17:34:44 +0100" Message-ID: Lines: 48 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Maxime Henrion writes: > Dag-Erling Smorgrav wrote: > > You don't seem to understand what funopen() really does... > I think I do, since I already used it successfully. Look at how it is > used in libfetch (AFAIK, you are the author of libfetch, I'm not sure > if you wrote this part though), Yes, I did. If you read that code you'll see it does a *lot* more than just pumping data from one file to another. > it's given a read function to read the > socket and a write function that will then write this into a file, and > this is used to download a file. This has absolutely nothing to do with zero-copy anything. The reader function doesn't need to be backed by a file - it can do *anything* it wants, even return a constant stream of "Maxime Henrion doesn't know what funopen() is for" :) > > > Having > > > such a syscall in the kernel would allow to implement "zero-copy" > > > wherever it is feasible. > > No. It would save you two copies and a bunch of syscalls, but it > > wouldn't be real zero-copy, just "n-2 copy" instead of "n copy". > And if n == 2 ? It's never the case. I think the best you can do in userland is n = 3, from a device to a file or socket, or from a file or socket to a device, by using mmap(2) on one side (can't do it on both - you have to mmap one device and write its contents to a file, or read from a file into an mmapped device). In the general case (file to file, file to socket, socket to file, socket to socket) the best you can do, even with mmap(), is n = 4. > > > Then, sendfile() would just be a particular case of this syscall, where > > > the input fd is a file and the output fd is a socket, and it could be > > > rewritten using it. > > No. Have you looked at the sendfile() code? > Probably not enough ; however I don't understand why it wouldn't be > possible to write a more generic function than sendfile() dealing with > any type of file descriptors that sendfile() could call then. It's not impossible, but it'd be a lot of work and it wouldn't be zero-copy. 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 Sat Mar 17 9:20:50 2001 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 BD43B37B718 for ; Sat, 17 Mar 2001 09:20:47 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f2HHKch33037; Sat, 17 Mar 2001 12:20:38 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sat, 17 Mar 2001 12:20:38 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: "David E. Cross" Cc: freebsd-arch@freebsd.org Subject: Re: idle wonderings about 'struct pcred' In-Reply-To: <200103161910.OAA81258@cs.rpi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I think you're describing the direction that ucred is already moving in. Take a look at struct ucred in -CURRENT, where things like the jail pointer are now there instead of directly under struct proc. If you look at the various POSIX.1e capability and MAC patches, you'll see that they introduce new stuff in ucred. I actually submitted patches years ago to add a extension field to proc, but the place to put it is really ucred. However, you run into conflicts concerning owners of the extension field -- I also have fairly extensive patches underway that make ucred run-time extensible more generally, but they're at least 8 - 12 months away from being ready to integrate because we need to do substantial performance analysis, need better support for run-time extension and ownership, etc. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services On Fri, 16 Mar 2001, David E. Cross wrote: > How would people feel about a fairly significant change to the pcred > structure? The change would be to facilitate different types of > authentication information about each process (say perhaps kerberos > credentials, or private keys, or encryption keys for a file, ACL type > info, etc. The possibilities are enormous). > > What got me thinking about this is how AFS handles this problem... it > takes the first 2 GID slots away from the process to store kernel data > into (yuck), there must be a better way, especially with the proliferation > of authentication systems, and the need to store and manage that data > easily and securely. NFSv4 will use GSS-API, for example, I think this > system would be a much better approach than trying to store the > authentication information in userland and needing to communicate that > with the kernel somehow. > > What I had in mind would be something like the following: > > struct pcred { > enum p_type; > void *p_data; > struct pcred *next; > }; > > (That is a _very_ rough idea). > > Our current, traditional, 'struct pcred' would become 'pcred_unix', with > a p_type of 0 (#define-d to PCRED_TYPE_UNIX) and would be stuffed into the > p_data pointer). > > What do people think? > > -- > David Cross | email: crossd@cs.rpi.edu > Lab Director | Rm: 308 Lally Hall > Rensselaer Polytechnic Institute, | Ph: 518.276.2860 > Department of Computer Science | Fax: 518.276.4033 > I speak only for myself. | WinNT:Linux::Linux:FreeBSD > > 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 Sat Mar 17 9:32:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nebula.cybercable.fr (d217.dhcp212-126.cybercable.fr [212.198.126.217]) by hub.freebsd.org (Postfix) with ESMTP id 171D737B719 for ; Sat, 17 Mar 2001 09:32:05 -0800 (PST) (envelope-from mux@qualys.com) Received: (from mux@localhost) by nebula.cybercable.fr (8.11.3/8.11.3) id f2HHVcx06226; Sat, 17 Mar 2001 18:31:38 +0100 (CET) (envelope-from mux) Date: Sat, 17 Mar 2001 18:31:38 +0100 From: Maxime Henrion To: arch@FreeBSD.org Cc: Dag-Erling Smorgrav Subject: Re: Proposal for a new syscall Message-ID: <20010317183137.C420@nebula.cybercable.fr> References: <20010317164411.A420@nebula.cybercable.fr> <20010317173444.B420@nebula.cybercable.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from des@ofug.org on Sat, Mar 17, 2001 at 06:18:28PM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > Maxime Henrion writes: > > Dag-Erling Smorgrav wrote: > > > You don't seem to understand what funopen() really does... > > I think I do, since I already used it successfully. Look at how it is > > used in libfetch (AFAIK, you are the author of libfetch, I'm not sure > > if you wrote this part though), > Yes, I did. If you read that code you'll see it does a *lot* more than > just pumping data from one file to another. I never said funopen() does only this. You should re-read my first mail. I probably wasn't clear enough, because of my poor english skills. > > it's given a read function to read the > > socket and a write function that will then write this into a file, and > > this is used to download a file. > This has absolutely nothing to do with zero-copy anything. The reader I never said funopen() had anything to do with zero-copy too... :-) > function doesn't need to be backed by a file - it can do *anything* it > wants, even return a constant stream of "Maxime Henrion doesn't know > what funopen() is for" :) Sure, and it could event return "DES doesn't understand what Maxime Henrion is trying to tell him" :P > > > > Having > > > > such a syscall in the kernel would allow to implement "zero-copy" > > > > wherever it is feasible. > > > No. It would save you two copies and a bunch of syscalls, but it > > > wouldn't be real zero-copy, just "n-2 copy" instead of "n copy". > > And if n == 2 ? > It's never the case. I think the best you can do in userland is n = 3, ^^^^^^^^ I'm talking about a syscall. > from a device to a file or socket, or from a file or socket to a > device, by using mmap(2) on one side (can't do it on both - you have > to mmap one device and write its contents to a file, or read from a > file into an mmapped device). In the general case (file to file, file > to socket, socket to file, socket to socket) the best you can do, even > with mmap(), is n = 4. > > > > Then, sendfile() would just be a particular case of this syscall, where > > > > the input fd is a file and the output fd is a socket, and it could be > > > > rewritten using it. > > > No. Have you looked at the sendfile() code? > > Probably not enough ; however I don't understand why it wouldn't be > > possible to write a more generic function than sendfile() dealing with > > any type of file descriptors that sendfile() could call then. > It's not impossible, but it'd be a lot of work and it wouldn't be > zero-copy. Sure, it's a lot of work. Why couldn't it be zero-copy if sendfile() already does this ? Maxime -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code Key fingerprint = F9B6 1D5A 4963 331C 88FC CA6A AB50 1EF2 8CBE 99D6 Public Key : http://www.epita.fr/~henrio_m/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 9:42:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from moby.geekhouse.net (moby.geekhouse.net [64.81.6.36]) by hub.freebsd.org (Postfix) with ESMTP id D8F8537B718 for ; Sat, 17 Mar 2001 09:42:26 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@dhcp152.geekhouse.net [192.168.1.152]) by moby.geekhouse.net (8.11.0/8.9.3) with ESMTP id f2HHiX189291; Sat, 17 Mar 2001 09:44:34 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sat, 17 Mar 2001 09:42:00 -0800 (PST) From: John Baldwin To: Garance A Drosihn Subject: Re: NO MORE '-BETA' Cc: arch@FreeBSD.org, Alfred Perlstein Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 17-Mar-01 Garance A Drosihn wrote: > At 2:31 PM -0800 3/16/01, John Baldwin wrote: >>On 16-Mar-01 Chris Faulhaber wrote: >> > On Fri, Mar 16, 2001 at 01:59:36PM -0800, John Baldwin wrote: >> >> Is this in the FAQ yet? >> >> >>> >>> http://www.FreeBSD.org/FAQ/admin.html#RELEASE-CANDIDATE >> >>Woo, cool. Then it seems people aren't using the resources >>normally available to them either in the form of mailing lists >>or the FAQ. I'm not sure we need to sacrifice our release >>engineering process for the sake of people doing cvsup upgrades >>that can't be bothered to either read the mailing lists or look >>in the FAQ. :( In case you haven't seen the previous posts in this thread, I have said that PRERELEASE was ok (though the same clueless people will probably gripe about it as well) and that I was arguing for _not_ completely taking this away. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - 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 Sat Mar 17 9:54:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id BE5EF37B71B for ; Sat, 17 Mar 2001 09:54:55 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f2HHrq945848; Sat, 17 Mar 2001 10:53:52 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200103171753.f2HHrq945848@harmony.village.org> To: Cy Schubert - ITSD Open Systems Group Subject: Re: flags settings for modules Cc: freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "Fri, 16 Mar 2001 09:37:42 PST." <200103161737.f2GHbua04336@cwsys.cwsent.com> References: <200103161737.f2GHbua04336@cwsys.cwsent.com> Date: Sat, 17 Mar 2001 10:53:51 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200103161737.f2GHbua04336@cwsys.cwsent.com> Cy Schubert - ITSD Open Systems Group writes: : Let's keep the change. Yes we should use schg in a lot more places for : the reason you've articulated above. Let's kill the change. It is so premature that it will cause us a lot of headaches. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 10: 3:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id C2FA737B718; Sat, 17 Mar 2001 10:03:26 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f2HI3Q945895; Sat, 17 Mar 2001 11:03:26 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200103171803.f2HI3Q945895@harmony.village.org> To: John Baldwin Subject: Re: man pages Cc: Matthew Jacob , arch@FreeBSD.ORG In-reply-to: Your message of "Fri, 16 Mar 2001 14:31:18 PST." References: Date: Sat, 17 Mar 2001 11:03:26 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message John Baldwin writes: : Actually, the cy(4) driver uses explicit enable_intr()'s as does : some of the 386 fpu code, and the pre-spinlock variant of the sio(4) : driver also used explicit enable_intr(). I'm not a big fan out of : it myself, but some things do need it. The manpages look good : though I'd be inclined personally to collapse them into a single : intr.9 manpage. Also, the actual functions are declared in : , and I didn't write these, I am just tweaking : them. :) I have a device that I've written a driver for. The device has a data pump <-> FIFO <-> DMA ENGINE on it. So far fairly standard. However, I get an interrupt when the first byte hits the FIFO. I then have a very small window to program the DMA ENGINE before the FIFO fills up. When I'm in my interrupt handler, I want to disable *ALL* interrupts so that I can do the complicated handsprings necessary to turn on the DMA ENGINE as fast as possible without *ANY* interruption. If I miss my window, I either miss data, or due to a hardware bug, I hang the PCI bus. This is an embedded system, so I don't have to worry about the mouse being responsive :-) I tried using splhigh(), but found that intr_disable() and intr_enable() in the old code proved to work more reliably in practice than splhigh(). No, I don't know why. Just wanted to show an example that needed it, not for syncronization, but to assume total control of the CPU and to make everyone else wait while I do my semi-time critical hardware frobbing. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 10: 5:57 2001 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 92C5637B718; Sat, 17 Mar 2001 10:05:52 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f2HI5k130211; Sat, 17 Mar 2001 19:05:46 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Warner Losh Cc: John Baldwin , Matthew Jacob , arch@FreeBSD.ORG Subject: Re: man pages In-Reply-To: Your message of "Sat, 17 Mar 2001 11:03:26 MST." <200103171803.f2HI3Q945895@harmony.village.org> Date: Sat, 17 Mar 2001 19:05:45 +0100 Message-ID: <30209.984852345@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200103171803.f2HI3Q945895@harmony.village.org>, Warner Losh writes: >Just wanted to show >an example that needed it, not for syncronization, but to assume total >control of the CPU and to make everyone else wait while I do my >semi-time critical hardware frobbing. I agree, there are lots of applications where it is a must to be able to do that, and we can either provide a civilized API for it or suffer all the weird hacks people will implement themselves... -- 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 Sat Mar 17 10: 8:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 1F62637B71A; Sat, 17 Mar 2001 10:08:54 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f2HI8F945937; Sat, 17 Mar 2001 11:08:20 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200103171808.f2HI8F945937@harmony.village.org> To: Chris Dillon Subject: Re: More BETA evilness Re: BETA induced nervousness Cc: Kris Kennaway , Alfred Perlstein , Jim Mock , "Steve O'Hara-Smith" , arch@FreeBSD.ORG, j mckitrick , jkh@FreeBSD.ORG In-reply-to: Your message of "Fri, 16 Mar 2001 18:04:38 CST." References: Date: Sat, 17 Mar 2001 11:08:15 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Chris Dillon writes: : this or something very similar (i.e. "PRE-RELEASE" or "PRE_RELEASE" or I'll not comment on the name overmuch. However, many scripts out there do not deal well with _ in release names, while they do with -. I was running FreeBSD 4.0_19991003_TSC for a while and found that too much software in the ports collection would freak out on this name, but not 4.0-19991003-TSC. So I don't care if you call it 4.3-ALL-YOUR-RELEASE-ARE-BELONG-TO-US or 4.3-CAT-WROTE-FLOPPY-DRIVER just don't use underscores. Thank you. Warner "with Zig for great justice" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 10:20:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id D9FDC37B718; Sat, 17 Mar 2001 10:20:56 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f2HIKq945996; Sat, 17 Mar 2001 11:20:52 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200103171820.f2HIKq945996@harmony.village.org> To: Poul-Henning Kamp Subject: Re: man pages Cc: John Baldwin , Matthew Jacob , arch@FreeBSD.ORG In-reply-to: Your message of "Sat, 17 Mar 2001 19:05:45 +0100." <30209.984852345@critter> References: <30209.984852345@critter> Date: Sat, 17 Mar 2001 11:20:52 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <30209.984852345@critter> Poul-Henning Kamp writes: : In message <200103171803.f2HI3Q945895@harmony.village.org>, Warner Losh writes: : >Just wanted to show : >an example that needed it, not for synchronization, but to assume total : >control of the CPU and to make everyone else wait while I do my : >semi-time critical hardware frobbing. : : I agree, there are lots of applications where it is a must to be : able to do that, and we can either provide a civilized API for it : or suffer all the weird hacks people will implement themselves... My hardware was UP. I don't know what I'd want this to mean in an MP environment. For my app, one CPU is fine (since the bus bandwidth I use in my handsprings is minimal). This likely is the typical case. I have trouble thinking of why someone would want to do this on multiple CPUs at the same time, unless it involved synchronization. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 10:33:16 2001 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 17DFD37B718 for ; Sat, 17 Mar 2001 10:33:13 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id TAA74242; Sat, 17 Mar 2001 19:33:11 +0100 (CET) (envelope-from des@ofug.org) 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: Maxime Henrion Cc: arch@FreeBSD.org Subject: Re: Proposal for a new syscall References: <20010317164411.A420@nebula.cybercable.fr> <20010317173444.B420@nebula.cybercable.fr> <20010317183137.C420@nebula.cybercable.fr> From: Dag-Erling Smorgrav Date: 17 Mar 2001 19:33:10 +0100 In-Reply-To: Maxime Henrion's message of "Sat, 17 Mar 2001 18:31:38 +0100" Message-ID: Lines: 22 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Maxime Henrion writes: > > > > > such a syscall in the kernel would allow to implement "zero-copy" > > > > > wherever it is feasible. > > > > No. It would save you two copies and a bunch of syscalls, but it > > > > wouldn't be real zero-copy, just "n-2 copy" instead of "n copy". > > > And if n == 2 ? > > It's never the case. I think the best you can do in userland is n = 3, > I'm talking about a syscall. Yes. I already told you that your proposed syscall would at best reduce the number of copies by two. Now I'm telling you that the minimum number of copies, without your proposed syscall, can't be less than 3. You do the math. > Why couldn't it be zero-copy if sendfile() already does this ? Sendfile(2) doesn't do zero-copy, it does 2-copy (in the best of cases). 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 Sat Mar 17 10:38:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id E0E2B37B719; Sat, 17 Mar 2001 10:38:42 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id KAA27848; Sat, 17 Mar 2001 10:38:41 -0800 Date: Sat, 17 Mar 2001 10:38:37 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Warner Losh Cc: Poul-Henning Kamp , John Baldwin , arch@FreeBSD.ORG Subject: Re: man pages In-Reply-To: <200103171820.f2HIKq945996@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kernel Functions for Drivers ddi_enter_critical(9F) NAME ddi_enter_critical, ddi_exit_critical - enter and exit a critical region of control SYNOPSIS #include #include #include unsigned int ddi_enter_critical(void); void ddi_exit_critical(unsigned int ddic); INTERFACE LEVEL Solaris DDI specific (Solaris DDI). ARGUMENTS ddic The returned value from the call to ddi_enter_critical() must be passed to ddi_exit_critical(). DESCRIPTION Nearly all driver operations can be done without any special synchronization and protection mechanisms beyond those pro- vided by, e.g., mutexes (see mutex(9F)). However, for cer- tain devices there can exist a very short critical region of code which must be allowed to run uninterrupted. The func- tion ddi_enter_critical() provides a mechanism by which a driver can ask the system to guarantee to the best of its ability that the current thread of execution will neither be preempted nor interrupted. This stays in effect until a bracketing call to ddi_exit_critical() is made (with an argument which was the returned value from ddi_enter_critical()). The driver may not call any functions external to itself in between the time it calls ddi_enter_critical() and the time it calls ddi_exit_critical(). RETURN VALUES ddi_enter_critical() returns an opaque unsigned integer which must be used in the subsequent call to ddi_exit_critical(). CONTEXT This function can be called from user or interrupt context. WARNINGS Driver writers should note that in a multiple processor sys- tem this function does not temporarily suspend other proces- sors from executing. This function also cannot guarantee to actually block the hardware from doing such things as SunOS 5.6 Last change: 4 Nov 1991 1 Kernel Functions for Drivers ddi_enter_critical(9F) interrupt acknowledge cycles. What it can do is guarantee that the currently executing thread will not be preempted. Do not write code bracketed by ddi_enter_critical() and ddi_exit_critical() that can get caught in an infinite loop, as the machine may crash if you do. SEE ALSO mutex(9F) Writing Device Drivers SunOS 5.6 Last change: 4 Nov 1991 2 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 10:41:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nebula.cybercable.fr (d217.dhcp212-126.cybercable.fr [212.198.126.217]) by hub.freebsd.org (Postfix) with ESMTP id 6AE3A37B718 for ; Sat, 17 Mar 2001 10:41:55 -0800 (PST) (envelope-from mux@qualys.com) Received: (from mux@localhost) by nebula.cybercable.fr (8.11.3/8.11.3) id f2HIfS106445; Sat, 17 Mar 2001 19:41:28 +0100 (CET) (envelope-from mux) Date: Sat, 17 Mar 2001 19:41:27 +0100 From: Maxime Henrion To: arch@FreeBSD.org Cc: Dag-Erling Smorgrav Subject: Re: Proposal for a new syscall Message-ID: <20010317194127.D420@nebula.cybercable.fr> References: <20010317164411.A420@nebula.cybercable.fr> <20010317173444.B420@nebula.cybercable.fr> <20010317183137.C420@nebula.cybercable.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from des@ofug.org on Sat, Mar 17, 2001 at 07:33:10PM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > Maxime Henrion writes: > > > > > > such a syscall in the kernel would allow to implement "zero-copy" > > > > > > wherever it is feasible. > > > > > No. It would save you two copies and a bunch of syscalls, but it > > > > > wouldn't be real zero-copy, just "n-2 copy" instead of "n copy". > > > > And if n == 2 ? > > > It's never the case. I think the best you can do in userland is n = 3, > > I'm talking about a syscall. > Yes. I already told you that your proposed syscall would at best > reduce the number of copies by two. Now I'm telling you that the > minimum number of copies, without your proposed syscall, can't be less > than 3. You do the math. Ok. > > Why couldn't it be zero-copy if sendfile() already does this ? > Sendfile(2) doesn't do zero-copy, it does 2-copy (in the best of > cases). Thanks, I stand corrected. Perhaps that should be mentioned in the man page ? Currently, it says this : IMPLEMENTATION NOTES The FreeBSD implementation of sendfile() is "zero-copy", meaning that it has been optimized so that copying of the file data is avoided. Maxime -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code Key fingerprint = F9B6 1D5A 4963 331C 88FC CA6A AB50 1EF2 8CBE 99D6 Public Key : http://www.epita.fr/~henrio_m/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 10:56:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 3555337B719 for ; Sat, 17 Mar 2001 10:56:25 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f2HIuPF27382 for arch@FreeBSD.ORG; Sat, 17 Mar 2001 10:56:25 -0800 (PST) Date: Sat, 17 Mar 2001 10:56:24 -0800 From: Alfred Perlstein To: arch@FreeBSD.ORG Subject: Re: NO MORE '-BETA' Message-ID: <20010317105624.A29888@fw.wintelcom.net> References: <20010316134349.K29888@fw.wintelcom.net> <20010316163748Z.jkh@osd.bsdi.com> <20010316164457.A57253@hub.freebsd.org> <20010316170000.R29888@fw.wintelcom.net> <20010316174303.A9267@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010316174303.A9267@dragon.nuxi.com>; from TrimYourCc@NUXI.com on Fri, Mar 16, 2001 at 05:43:04PM -0800 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * David O'Brien [010316 17:43] wrote: > On Fri, Mar 16, 2001 at 05:00:00PM -0800, Alfred Perlstein wrote: > > Or teach the ports committers the way to bump newver.sh themselves. > > A minor step that should be trivial for them to do. > > That is an inappropriate response, from someone that hacks their kernel > daily. I'm not sure what you mean. This whole -BETA topic is about us getting so removed from the users that we don't realize when we do evil things to them. Are you saying that I've lost touch with the abilities of the ports developers? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 10:59:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id B160137B718 for ; Sat, 17 Mar 2001 10:59:10 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f2HIx8946196; Sat, 17 Mar 2001 11:59:08 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200103171859.f2HIx8946196@harmony.village.org> To: mjacob@feral.com Subject: Re: man pages Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Sat, 17 Mar 2001 10:38:37 PST." References: Date: Sat, 17 Mar 2001 11:59:07 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Matthew Jacob writes: : ddi_enter_critical, ddi_exit_critical - enter and exit a : critical region of control ... : The driver may not call any functions external to itself in between : the time it calls ddi_enter_critical() and the time it calls : ddi_exit_critical(). ... Hmmm. That's what I need, with the above exception being too restrictive. I'd need to call functions that frob the hardware. :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 11: 2: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id EF66337B718; Sat, 17 Mar 2001 11:02:02 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f2HJ1pE27520; Sat, 17 Mar 2001 11:01:51 -0800 (PST) Date: Sat, 17 Mar 2001 11:01:51 -0800 From: Alfred Perlstein To: Jordan Hubbard Cc: jhb@FreeBSD.ORG, drosih@rpi.edu, tlambert@primenet.com, arch@FreeBSD.ORG Subject: Re: NO MORE '-BETA' Message-ID: <20010317110151.B29888@fw.wintelcom.net> References: <20010316140408.N29888@fw.wintelcom.net> <20010316164306W.jkh@osd.bsdi.com> <20010316170755.S29888@fw.wintelcom.net> <20010316173711J.jkh@osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010316173711J.jkh@osd.bsdi.com>; from jkh@osd.bsdi.com on Fri, Mar 16, 2001 at 05:37:11PM -0800 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Jordan Hubbard [010316 17:38] wrote: > That would be really gross. Have you lost your marbles? :) I'm guessing you're upset about the build checking with newvers.sh? Why is this a problem? It seems like if I implemented what I said (barfing on interactive installs during BETA period unless a variable is set) it would prevent foot shooting and stupid questions while still allowing for the -BETA testing period for ports people. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 11:14:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 3619937B719 for ; Sat, 17 Mar 2001 11:14:39 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f2HJEag27775; Sat, 17 Mar 2001 11:14:36 -0800 (PST) Date: Sat, 17 Mar 2001 11:14:36 -0800 From: Alfred Perlstein To: Maxime Henrion Cc: arch@FreeBSD.ORG, Dag-Erling Smorgrav Subject: Re: Proposal for a new syscall Message-ID: <20010317111436.C29888@fw.wintelcom.net> References: <20010317164411.A420@nebula.cybercable.fr> <20010317173444.B420@nebula.cybercable.fr> <20010317183137.C420@nebula.cybercable.fr> <20010317194127.D420@nebula.cybercable.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010317194127.D420@nebula.cybercable.fr>; from mux@qualys.com on Sat, Mar 17, 2001 at 07:41:27PM +0100 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Maxime Henrion [010317 10:42] wrote: > Dag-Erling Smorgrav wrote: > > Maxime Henrion writes: > > > > > > > such a syscall in the kernel would allow to implement "zero-copy" > > > > > > > wherever it is feasible. > > > > > > No. It would save you two copies and a bunch of syscalls, but it > > > > > > wouldn't be real zero-copy, just "n-2 copy" instead of "n copy". > > > > > And if n == 2 ? > > > > It's never the case. I think the best you can do in userland is n = 3, > > > I'm talking about a syscall. > > Yes. I already told you that your proposed syscall would at best > > reduce the number of copies by two. Now I'm telling you that the > > minimum number of copies, without your proposed syscall, can't be less > > than 3. You do the math. > > Ok. > > > > Why couldn't it be zero-copy if sendfile() already does this ? > > Sendfile(2) doesn't do zero-copy, it does 2-copy (in the best of > > cases). > > Thanks, I stand corrected. Perhaps that should be mentioned in the man > page ? Currently, it says this : > > IMPLEMENTATION NOTES > The FreeBSD implementation of sendfile() is "zero-copy", meaning that it > has been optimized so that copying of the file data is avoided. That's market speak. There's at least one copy when the kernel asks the disk to DMA the data in. And there's _always_ another copy when the ethernet hardware reads the data to translate it into whatever it speaks over the cable. My viewpoint is that you don't understand funopen() (which is really ok because I haven't bothered to look into it either) and DES is being somewhat evil by not getting to the above mentioned point... that almost nothing is trully "zero copy". So go knock yourself out, it'd be nice to have a generic tee(2) or kdma(2) syscall to effeciently pipe data from one fd to another. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 11:24:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 02E7037B718 for ; Sat, 17 Mar 2001 11:24:14 -0800 (PST) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id LAA27957; Sat, 17 Mar 2001 11:24:15 -0800 Date: Sat, 17 Mar 2001 11:24:11 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Warner Losh Cc: arch@FreeBSD.ORG Subject: Re: man pages In-Reply-To: <200103171859.f2HIx8946196@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In message Matthew Jacob writes: > : ddi_enter_critical, ddi_exit_critical - enter and exit a > : critical region of control > ... > : The driver may not call any functions external to itself in between > : the time it calls ddi_enter_critical() and the time it calls > : ddi_exit_critical(). > ... > > Hmmm. That's what I need, with the above exception being too > restrictive. I'd need to call functions that frob the hardware. :-) Well, At that time Solaris assumed that you've ddi_map_reg'd the h/w and just have a virtual address pointing to registers. The man page needs to be updated to say "calling ddi_{put,get}{8,16,32,64} or ddi_rep_{put,get}{8,16,32,64} is okay" -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 11:25:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 06AA337B718; Sat, 17 Mar 2001 11:25:09 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f2HJP4x95161; Sat, 17 Mar 2001 11:25:04 -0800 (PST) (envelope-from dillon) Date: Sat, 17 Mar 2001 11:25:04 -0800 (PST) From: Matt Dillon Message-Id: <200103171925.f2HJP4x95161@earth.backplane.com> To: "Rodney W. Grimes" Cc: jhb@FreeBSD.ORG (John Baldwin), arch@FreeBSD.ORG Subject: Re: Proposal for the CPU interrupt API References: <200103170422.UAA55781@gndrsh.dnsmgr.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :and by otherwise I included comments in code. Take this one for example: :>From sys/i386/isa/if_sr.c : /* : * XXX Disable all interrupts for now. I think if you are using the : * dmac you don't use these interrupts. : */ : SRC_PUT8(hc->sca_base, msci->ie0, 0); : SRC_PUT8(hc->sca_base, msci->ie1, 0x0C); : :writting 0x0C to msci->ie1 does NOT disable all interrupts!!! Well, those XXX's seem to indicate that the author wasn't so sure about what he was doing either. Quite a useful comment, I think! % fgrep XXX vm/* | wc -l 108 -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 12:32:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from moby.geekhouse.net (moby.geekhouse.net [64.81.6.36]) by hub.freebsd.org (Postfix) with ESMTP id 9FC3A37B718 for ; Sat, 17 Mar 2001 12:32:26 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@dhcp152.geekhouse.net [192.168.1.152]) by moby.geekhouse.net (8.11.0/8.9.3) with ESMTP id f2HKYO189867; Sat, 17 Mar 2001 12:34:25 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200103171859.f2HIx8946196@harmony.village.org> Date: Sat, 17 Mar 2001 12:31:50 -0800 (PST) From: John Baldwin To: Warner Losh Subject: Re: man pages Cc: arch@FreeBSD.org, mjacob@feral.com Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 17-Mar-01 Warner Losh wrote: > In message Matthew > Jacob writes: >: ddi_enter_critical, ddi_exit_critical - enter and exit a >: critical region of control > ... >: The driver may not call any functions external to itself in between >: the time it calls ddi_enter_critical() and the time it calls >: ddi_exit_critical(). > ... > > Hmmm. That's what I need, with the above exception being too > restrictive. I'd need to call functions that frob the hardware. :-) This would allow us to get rid of most of the (ab)uses of *_intr as it is right now. If we were to use a more abstract name for this than just intr_restore/disable, would critical_enter() and critical_exit() work? If I do this, I may not even mess with the current set of foo_intr() functions as they may turn out to no longer be useful. Some things like the ACPI code would need to be taught to not assume cli/sti though. (Intel's ACPICA code is Linux-centric in some places, but I think they are very open to fixes, so I don't expect that will be a problem.) > Warner -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - 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 Sat Mar 17 12:43:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id AF29537B71C; Sat, 17 Mar 2001 12:43:18 -0800 (PST) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id MAA28194; Sat, 17 Mar 2001 12:43:21 -0800 Date: Sat, 17 Mar 2001 12:43:17 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Baldwin Cc: arch@FreeBSD.org Subject: 'final' man pages In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Incorporating Terry's comments, here's my last cut for the three functions... I think it's better if they're separate man pages. Can we all move to closure on this? The only other issue I can think of here is the semantics of an enable_intr() in between a disable_intr/restore_intr call. .\" -*- nroff -*- .\" .\" Copyright (c) 2001 Matthew Jacob .\" .\" All rights reserved. .\" .\" This program is free software. .\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions .\" are met: .\" 1. Redistributions of source code must retain the above copyright .\" notice, this list of conditions and the following disclaimer. .\" 2. Redistributions in binary form must reproduce the above copyright .\" notice, this list of conditions and the following disclaimer in the .\" documentation and/or other materials provided with the distribution. .\" .\" THIS SOFTWARE IS PROVIDED BY THE DEVELOPERS ``AS IS'' AND ANY EXPRESS OR .\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES .\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. .\" IN NO EVENT SHALL THE DEVELOPERS BE LIABLE FOR ANY DIRECT, INDIRECT, .\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT .\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, .\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY .\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT .\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF .\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. .\" .\" $FreeBSD: $ .\" .Dd March 16, 2001 .Dt RESTORE_INTR 9 .Os FreeBSD .Sh NAME .Nm restore_intr .Nd restore interrupt dispatch .Sh SYNOPSIS .Fd #include .Ft void .Fn restore_intr "intrmask_t" .Sh DESCRIPTION .Pp This function restores the state prior to a previous call to .Xr disable_intr 9 such that the calling CPU may now have interrupts dispatched to it again. The argument is the value returned from a previous call to .Xr disable_intr 9 . .Pp It is undefined what will occur if random values are passed to .Xr enable_intr 9 . .Sh SEE ALSO .Xr disable_intr 9 .Xr enable_intr 9 .Sh AUTHORS .An arch@freebsd.org ------- .\" -*- nroff -*- .\" .\" Copyright (c) 2001 Matthew Jacob .\" .\" All rights reserved. .\" .\" This program is free software. .\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions .\" are met: .\" 1. Redistributions of source code must retain the above copyright .\" notice, this list of conditions and the following disclaimer. .\" 2. Redistributions in binary form must reproduce the above copyright .\" notice, this list of conditions and the following disclaimer in the .\" documentation and/or other materials provided with the distribution. .\" .\" THIS SOFTWARE IS PROVIDED BY THE DEVELOPERS ``AS IS'' AND ANY EXPRESS OR .\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES .\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. .\" IN NO EVENT SHALL THE DEVELOPERS BE LIABLE FOR ANY DIRECT, INDIRECT, .\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT .\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, .\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY .\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT .\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF .\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. .\" .\" $FreeBSD: $ .\" .Dd March 16, 2001 .Dt DISABLE_INTR 9 .Os FreeBSD .Sh NAME .Nm disable_intr .Nd disable interrupt dispatch .Sh SYNOPSIS .Fd #include .Ft intrmask_t .Fn disable_intr "void" .Sh DESCRIPTION .Pp This function inhibits interrupts from being be dispatched to the CPU this function is called from. It returns an interrupt mask value which must be used in a future call to .Xr restore_intr 9 . .Pp The purpose of this function is inhibit interrupts from being dispatched to the calling CPU. It may be used to ensure the timely execution of short segments of hardware dependent critical code. It may also be used to ensure the preservation of certain platform specific machine state when calls outside of the kernel (e.g., to supporting PROM code) are made. .Pp This function cannot guarantee that interrupts will also be blocked from delivery to other CPUs. Therefore, it cannot be used as a replacement for the appropriate SMP locking. .Pp Use this function with caution, as misuse will likely hang the system. .Sh RETURN VALUES Returns a interrupt mask value that is to be later passed .Xr restore_intr 9 . .Xr .Sh SEE ALSO .Xr restore_intr 9 , .Xr enable_intr 9 .Sh AUTHORS .An arch@freebsd.org ------- .\" -*- nroff -*- .\" .\" Copyright (c) 2001 Matthew Jacob .\" .\" All rights reserved. .\" .\" This program is free software. .\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions .\" are met: .\" 1. Redistributions of source code must retain the above copyright .\" notice, this list of conditions and the following disclaimer. .\" 2. Redistributions in binary form must reproduce the above copyright .\" notice, this list of conditions and the following disclaimer in the .\" documentation and/or other materials provided with the distribution. .\" .\" THIS SOFTWARE IS PROVIDED BY THE DEVELOPERS ``AS IS'' AND ANY EXPRESS OR .\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES .\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. .\" IN NO EVENT SHALL THE DEVELOPERS BE LIABLE FOR ANY DIRECT, INDIRECT, .\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT .\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, .\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY .\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT .\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF .\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. .\" .\" $FreeBSD: $ .\" .Dd March 16, 2001 .Dt ENABLE_INTR 9 .Os FreeBSD .Sh NAME .Nm enable_intr .Nd enable interrupt dispatch .Sh SYNOPSIS .Fd #include .Ft void .Fn enable_intr "void" .Sh DESCRIPTION .Pp This function enables interrupt dispatching to the calling CPU. .Sh SEE ALSO .Xr disable_intr 9 .Xr restore_intr 9 .Sh AUTHORS .An arch@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 12:45:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 658B237B719; Sat, 17 Mar 2001 12:45:24 -0800 (PST) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id MAA28210; Sat, 17 Mar 2001 12:45:27 -0800 Date: Sat, 17 Mar 2001 12:45:23 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Baldwin Cc: Warner Losh , arch@FreeBSD.ORG Subject: Re: man pages In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >: critical region of control > > ... > >: The driver may not call any functions external to itself in between > >: the time it calls ddi_enter_critical() and the time it calls > >: ddi_exit_critical(). > > ... > > > > Hmmm. That's what I need, with the above exception being too > > restrictive. I'd need to call functions that frob the hardware. :-) > > This would allow us to get rid of most of the (ab)uses of *_intr as it is right > now. If we were to use a more abstract name for this than just > intr_restore/disable, would critical_enter() and critical_exit() work? If I do > this, I may not even mess with the current set of foo_intr() functions as they > may turn out to no longer be useful. Some things like the ACPI code would need > to be taught to not assume cli/sti though. (Intel's ACPICA code is > Linux-centric in some places, but I think they are very open to fixes, so I > don't expect that will be a problem.) Personally, I like the 'intr' aspect- this is, in fact, what we are doing. ddi_enter_critical/ddi_exit_critical as an attempt to be a bit more generic, and the restriction against calling other functions is too restrictive now (IMO)- you could interpret this as prohibiting calls to the PROM, for instance. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 15:25:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id B96DD37B718 for ; Sat, 17 Mar 2001 15:25:27 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.2/8.11.2) with ESMTP id f2HNPjm13127; Sat, 17 Mar 2001 23:25:49 GMT (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f2HNSdm55352; Sat, 17 Mar 2001 23:28:39 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200103172328.f2HNSdm55352@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Warner Losh Cc: Cy Schubert - ITSD Open Systems Group , freebsd-arch@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: flags settings for modules In-Reply-To: Message from Warner Losh of "Sat, 17 Mar 2001 10:53:51 MST." <200103171753.f2HHrq945848@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 17 Mar 2001 23:28:38 +0000 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In message <200103161737.f2GHbua04336@cwsys.cwsent.com> Cy Schubert - ITSD Open Systems Group writes: > : Let's keep the change. Yes we should use schg in a lot more places for > : the reason you've articulated above. > > Let's kill the change. It is so premature that it will cause us a lot > of headaches. And it's a joke if /boot and /boot/kernel aren't protected appropriately. Not only should schg be taken back off the modules, but it should be taken off the kernel as it's useless since it moved out of /. > Warner -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 15:42:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 52D2037B719; Sat, 17 Mar 2001 15:42:28 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id PAA59546; Sat, 17 Mar 2001 15:42:14 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200103172342.PAA59546@gndrsh.dnsmgr.net> Subject: Re: Proposal for the CPU interrupt API In-Reply-To: <200103171925.f2HJP4x95161@earth.backplane.com> from Matt Dillon at "Mar 17, 2001 11:25:04 am" To: dillon@earth.backplane.com (Matt Dillon) Date: Sat, 17 Mar 2001 15:42:13 -0800 (PST) Cc: jhb@FreeBSD.ORG (John Baldwin), arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :and by otherwise I included comments in code. Take this one for example: > :>From sys/i386/isa/if_sr.c > : /* > : * XXX Disable all interrupts for now. I think if you are using the > : * dmac you don't use these interrupts. > : */ > : SRC_PUT8(hc->sca_base, msci->ie0, 0); > : SRC_PUT8(hc->sca_base, msci->ie1, 0x0C); > : > :writting 0x0C to msci->ie1 does NOT disable all interrupts!!! > > Well, those XXX's seem to indicate that the author wasn't so sure about > what he was doing either. Quite a useful comment, I think! The XXX is more than likely with regards to the ``I think if you are...'' part of the comment. (And it is wrong about that as well, you need to use most of the interrupts, even when using the dmac, to deal with things like DMA underruns and overruns.) > > % fgrep XXX vm/* | wc -l > 108 > > -Matt > -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 15:58:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ohm.physics.purdue.edu (ohm.physics.purdue.edu [128.210.146.32]) by hub.freebsd.org (Postfix) with ESMTP id A45F337B718 for ; Sat, 17 Mar 2001 15:58:26 -0800 (PST) (envelope-from will@physics.purdue.edu) Received: (from will@localhost) by ohm.physics.purdue.edu (8.11.2/8.9.3) id f2I01kR91050; Sat, 17 Mar 2001 19:01:46 -0500 (EST) (envelope-from will@physics.purdue.edu) X-Authentication-Warning: ohm.physics.purdue.edu: will set sender to will@physics.purdue.edu using -f Date: Sat, 17 Mar 2001 19:01:45 -0500 From: Will Andrews To: arch@FreeBSD.org Cc: Luke Mewburn Subject: Re: [PATCH] add a SITE MD5 command to ftpd Message-ID: <20010317190145.K61859@ohm.physics.purdue.edu> Reply-To: Will Andrews Mail-Followup-To: Will Andrews , arch@FreeBSD.org, Luke Mewburn Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="NLszGGfvVP7rUs9N" Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 4.2-STABLE i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --NLszGGfvVP7rUs9N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi -arch, Luke Mewburn's reply on this issue. Luke, check out the archive here: http://docs.freebsd.org/cgi/mailindex.cgi?sort=3Ddate&file=3Dcurrent/freebs= d-arch I think your issues have probably already been hashed out. So I'll not say any more until you have a look at the archive. Others may comment, though. ----- Forwarded message from Luke Mewburn ----- Date: Sun, 18 Mar 2001 10:53:23 +1100 From: Luke Mewburn To: Will Andrews Subject: Re: FW: [PATCH] add a SITE MD5 command to ftpd User-Agent: Mutt/1.2.5i Sender: lukem@limb.com.au On Wed, Mar 14, 2001 at 03:49:19PM -0500, Will Andrews wrote: > What do you think of this? I'm forwarding in case you hadn't heard > about ideas like this. Some discussion that ensued indicated that this > would be an excellent idea for mirroring purposes, among other things. >=20 > Since FreeBSD is considering (and some have been working on patches > towards) simply bringing in lukemftpd into FreeBSD's repository and > using it as its ftpd, it would be nice to hear your opinion on this. I think it's possibly a bit messy :-/. Also, NetBSD itself is moving to newer digests (SHA1, RMD160), and I can see the explosion of problems supporting multiple hashes from that point :/ Also, it's only useful if all the servers support it, and the majority of your distfiles (except those you locally mirror on ftp.freebsd.org) probably won't be on servers that support SITE MD5 anyway. Sorry to seem so negative about the idea. I'm a bit conservative about adding features like this without considering the `cleanest' and best long-term solution. Can you point me at a mail archive discussing this? Maybe my issues will have been covered there already. BTW: I've got a beta version of an auto-conf aware version of ftpd available (aka lukemftpd :). This would allow an up-to-date ftpd to be installed other systems (Solaris, Linux) as well as older NetBSD/FreeBSD releases. I've even got the most recent DoS problem solved in my source. I could make it available for testing to you if you wanted to try it on old FreeBSD releases if you were interested. > ----- Forwarded message from Peter Pentchev ----- >=20 > Date: Tue, 13 Mar 2001 21:15:44 +0200 > From: Peter Pentchev > To: freebsd-arch@FreeBSD.ORG > Subject: [PATCH] add a SITE MD5 command to ftpd > User-Agent: Mutt/1.2.5i > Sender: owner-freebsd-arch@FreeBSD.ORG >=20 > Hi, >=20 > A recent thread about Bill Fenner's distfiles-checking scripts > set me thinking about easy detection of MD5 checksum mismatches. > Bill Fenner pointed out that these checks are not done because > of the sheer volume of the network traffic needed to download > all the distfiles from all the distsites. >=20 > I know that adding a ``SITE MD5 filename'' command to our ftpd > is a *very* little step in a possibly wrong direction (this will > not automagically make all the ftp daemons on all the distsites > implement this command), but IMHO, it's a start.. I'm thinking > of adding similar functionality to wu-ftpd and ProFTPd soon, and > submitting patches to the authors, in the hope of starting a ball > rolling :) >=20 > G'luck, > Peter >=20 > --=20 > because I didn't think of a good beginning of it. >=20 > Index: src/libexec/ftpd/ftpcmd.y > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /home/ncvs/src/libexec/ftpd/ftpcmd.y,v > retrieving revision 1.21 > diff -u -r1.21 ftpcmd.y > --- src/libexec/ftpd/ftpcmd.y 2001/02/19 21:51:26 1.21 > +++ src/libexec/ftpd/ftpcmd.y 2001/03/13 18:48:54 > @@ -58,6 +58,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -92,6 +93,7 @@ > extern char tmpline[]; > extern int readonly; > extern int noepsv; > +extern int nomd5; > =20 > off_t restart_point; > =20 > @@ -126,7 +128,7 @@ > CDUP STOU SMNT SYST SIZE MDTM > LPRT LPSV EPRT EPSV > =20 > - UMASK IDLE CHMOD > + UMASK IDLE CHMOD MD5 > =20 > LEXERR > =20 > @@ -648,6 +650,34 @@ > } > } > } > + | SITE SP check_login MD5 SP pathname CRLF > + { > + if ($3) { > + struct stat stbuf; > + char hash[33]; > + > + if (nomd5) > + reply(500, > + "SITE MD5 command disabled", > + $6); > + else if (stat($6, &stbuf) < 0) > + reply(550, > + "%s: %s", > + $6, strerror(errno)); > + else if (!S_ISREG(stbuf.st_mode)) > + reply(550, > + "%s: not a plain file", > + $6); > + else if (MD5File($6, hash) =3D=3D NULL) > + reply(550, > + "%s: %s", > + $6, strerror(errno)); > + else > + reply(200, > + "MD5 %s %s", > + hash, $6); > + } > + } > | STOU check_login_ro SP pathname CRLF > { > if ($2 && $4 !=3D NULL) > @@ -1088,6 +1118,7 @@ > { "IDLE", IDLE, ARGS, 1, "[ maximum-idle-time ]" }, > { "CHMOD", CHMOD, NSTR, 1, " mode file-name" }, > { "HELP", HELP, OSTR, 1, "[ ]" }, > + { "MD5", MD5, STR1, 1, " file-name" }, > { NULL, 0, 0, 0, 0 } > }; > =20 > Index: src/libexec/ftpd/ftpd.8 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /home/ncvs/src/libexec/ftpd/ftpd.8,v > retrieving revision 1.36 > diff -u -r1.36 ftpd.8 > --- src/libexec/ftpd/ftpd.8 2000/12/18 08:33:25 1.36 > +++ src/libexec/ftpd/ftpd.8 2001/03/13 18:48:54 > @@ -42,6 +42,7 @@ > .Sh SYNOPSIS > .Nm > .Op Fl 4 > +.Op Fl 5 > .Op Fl 6 > .Op Fl d > .Op Fl l Op Fl l > @@ -153,6 +154,10 @@ > When > .Fl 6 > is not specified, accept IPv4 connection via AF_INET socket. > +.It Fl 5 > +Disable the SITE MD5 command. > +This is useful for preventing possible denial of service attacks, > +especially on servers allowing anonymous ftp access. > .It Fl A > Allow only anonymous ftp access. > .It Fl r > Index: src/libexec/ftpd/ftpd.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /home/ncvs/src/libexec/ftpd/ftpd.c,v > retrieving revision 1.73 > diff -u -r1.73 ftpd.c > --- src/libexec/ftpd/ftpd.c 2001/03/11 13:20:44 1.73 > +++ src/libexec/ftpd/ftpd.c 2001/03/13 18:48:56 > @@ -150,6 +150,7 @@ > int pdata =3D -1; /* for passive mode */ > int readonly=3D0; /* Server is in readonly mode. */ > int noepsv=3D0; /* EPSV command is disabled. */ > +int nomd5=3D0; /* SITE MD5 command is disabled. */ > sig_atomic_t transflag; > off_t file_size; > off_t byte_count; > @@ -292,7 +293,7 @@ > #endif /* OLD_SETPROCTITLE */ > =20 > =20 > - while ((ch =3D getopt(argc, argv, "AdlDESURrt:T:u:va:p:46")) !=3D -1) { > + while ((ch =3D getopt(argc, argv, "AdlDESURrt:T:u:va:p:456")) !=3D -1) { > switch (ch) { > case 'D': > daemon_mode++; > @@ -369,6 +370,10 @@ > enable_v4 =3D 1; > if (family =3D=3D AF_UNSPEC) > family =3D AF_INET; > + break; > + > + case '5': > + nomd5 =3D 1; > break; > =20 > case '6': >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message >=20 > ----- End forwarded message ----- >=20 > --=20 > wca --=20 Luke Mewburn http://www.wasabisystems.com Luke Mewburn http://www.netbsd.org Wasabi Systems - providing NetBSD sales, support and service. ----- End forwarded message ----- --=20 wca --NLszGGfvVP7rUs9N Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.3 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6s/rpF47idPgWcsURAq36AKCFfiLIv48V0+CtJhjauEvJqmgS8gCfY7Du myKxnMEwbDe9+S4CG4r+jnM= =VbYw -----END PGP SIGNATURE----- --NLszGGfvVP7rUs9N-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 16:29:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 1A77F37B718; Sat, 17 Mar 2001 16:29:16 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f2I0TD896802; Sat, 17 Mar 2001 16:29:13 -0800 (PST) (envelope-from dillon) Date: Sat, 17 Mar 2001 16:29:13 -0800 (PST) From: Matt Dillon Message-Id: <200103180029.f2I0TD896802@earth.backplane.com> To: "Rodney W. Grimes" Cc: jhb@FreeBSD.ORG (John Baldwin), arch@FreeBSD.ORG Subject: Re: Proposal for the CPU interrupt API References: <200103172342.PAA59546@gndrsh.dnsmgr.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :The XXX is more than likely with regards to the ``I think if you are...'' :part of the comment. (And it is wrong about that as well, you need to :use most of the interrupts, even when using the dmac, to deal with things :like DMA underruns and overruns.) : :Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net The point is that it's an eye catcher. "Hey, maybe someone should look at this at some point, it may not be doing the right thing or may not have all the functionality it should or, hey, it could even be just plain broken and the only thing preventing the system from shredding itself is luck!". -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 16:35:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-202.dsl.lsan03.pacbell.net [63.207.60.202]) by hub.freebsd.org (Postfix) with ESMTP id 579E237B718 for ; Sat, 17 Mar 2001 16:35:41 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id EC63366B2E; Sat, 17 Mar 2001 16:35:40 -0800 (PST) Date: Sat, 17 Mar 2001 16:35:40 -0800 From: Kris Kennaway To: Brian Somers Cc: Warner Losh , Cy Schubert - ITSD Open Systems Group , freebsd-arch@FreeBSD.ORG Subject: Re: flags settings for modules Message-ID: <20010317163540.A5397@mollari.cthul.hu> References: <200103172328.f2HNSdm55352@hak.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103172328.f2HNSdm55352@hak.lan.Awfulhak.org>; from brian@Awfulhak.org on Sat, Mar 17, 2001 at 11:28:38PM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 17, 2001 at 11:28:38PM +0000, Brian Somers wrote: > > In message <200103161737.f2GHbua04336@cwsys.cwsent.com> Cy Schubert - I= TSD Open Systems Group writes: > > : Let's keep the change. Yes we should use schg in a lot more places f= or=20 > > : the reason you've articulated above. > >=20 > > Let's kill the change. It is so premature that it will cause us a lot > > of headaches. >=20 > And it's a joke if /boot and /boot/kernel aren't protected=20 > appropriately. Not only should schg be taken back off the modules,=20 > but it should be taken off the kernel as it's useless since it moved=20 > out of /. I've always seen schg as an anti-foot-shooting device..if you accidentally spam that file and don't have any other kernels around, you're screwed. If you spam modules, you're probably less screwed (though you still might be). Kris --2fHTh5uZTiUOsy+g Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6tALcWry0BWjoQKURAs/oAJ9t0Zda/4j7HHuwoJRcB2WsESqg1QCgkpua hqBza+Z6QJ4oy7EovQfT6og= =35Kt -----END PGP SIGNATURE----- --2fHTh5uZTiUOsy+g-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 16:54:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 88AF237B719 for ; Sat, 17 Mar 2001 16:54:41 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.2/8.11.2) with ESMTP id f2I0sxm13564; Sun, 18 Mar 2001 00:54:59 GMT (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f2I0vqm56252; Sun, 18 Mar 2001 00:57:52 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200103180057.f2I0vqm56252@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Kris Kennaway Cc: Brian Somers , Warner Losh , Cy Schubert - ITSD Open Systems Group , freebsd-arch@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: flags settings for modules In-Reply-To: Message from Kris Kennaway of "Sat, 17 Mar 2001 16:35:40 PST." <20010317163540.A5397@mollari.cthul.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 18 Mar 2001 00:57:52 +0000 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I've always seen schg as an anti-foot-shooting device..if you > accidentally spam that file and don't have any other kernels around, > you're screwed. If you spam modules, you're probably less screwed > (though you still might be). $ ls -lo /etc/*p*wd* -rw------- 1 root wheel - 2466 Mar 6 17:48 /etc/master.passwd -rw-r--r-- 1 root wheel - 2027 Mar 6 17:48 /etc/passwd -rw-r--r-- 1 root wheel - 40960 Mar 6 17:48 /etc/pwd.db -rw------- 1 root wheel - 40960 Mar 6 17:48 /etc/spwd.db There's more than one foot waiting to be shot. I think this sort of half-baked protection should really be turn-on-and-offable somewhere (maybe /etc/make.conf) and shouldn't be on by default. I'm not arguing that there are no good usages for file flags. I'm just saying that I think everything we've done with them in the base system so far is .... surprising. I find it a bit embarrassing. > Kris -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 18:16:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 4294B37B719; Sat, 17 Mar 2001 18:16:14 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id NAA23100; Sun, 18 Mar 2001 13:15:48 +1100 Date: Sun, 18 Mar 2001 13:15:30 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: "Rodney W. Grimes" Cc: Matt Dillon , John Baldwin , arch@FreeBSD.ORG Subject: Re: Proposal for the CPU interrupt API In-Reply-To: <200103172342.PAA59546@gndrsh.dnsmgr.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 17 Mar 2001, Rodney W. Grimes wrote: > > :and by otherwise I included comments in code. Take this one for example: > > :>From sys/i386/isa/if_sr.c > > : /* > > : * XXX Disable all interrupts for now. I think if you are using the > > : * dmac you don't use these interrupts. > > : */ > > : SRC_PUT8(hc->sca_base, msci->ie0, 0); > > : SRC_PUT8(hc->sca_base, msci->ie1, 0x0C); > > : > > :writting 0x0C to msci->ie1 does NOT disable all interrupts!!! > > > > Well, those XXX's seem to indicate that the author wasn't so sure about > > what he was doing either. Quite a useful comment, I think! > > The XXX is more than likely with regards to the ``I think if you are...'' > part of the comment. (And it is wrong about that as well, you need to > use most of the interrupts, even when using the dmac, to deal with things > like DMA underruns and overruns.) Anyway, this has nothing to do with the subject of this thread. "all" in this context means "all interrupts for this device". Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 19: 1:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 4DA7F37B71A for ; Sat, 17 Mar 2001 19:01:35 -0800 (PST) (envelope-from jkh@osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.2/8.11.1) with ESMTP id f2I307H98062; Sat, 17 Mar 2001 19:00:08 -0800 (PST) (envelope-from jkh@osd.bsdi.com) To: wes@softweyr.com Cc: bright@wintelcom.net, arch@FreeBSD.ORG Subject: Re: NO MORE '-BETA' In-Reply-To: <3AB2E8DE.CEBC23D9@softweyr.com> References: <20010316071040.V29888@fw.wintelcom.net> <20010316104124Z.jkh@osd.bsdi.com> <3AB2E8DE.CEBC23D9@softweyr.com> X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010317190007Z.jkh@osd.bsdi.com> Date: Sat, 17 Mar 2001 19:00:07 -0800 From: Jordan Hubbard X-Dispatcher: imput version 20000228(IM140) Lines: 10 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > And I though bikeshed arguments were stoopid. No, this is without question the stupidest thread on record and a gross abuse of the "arch" mailing list. Special thanks must go to Alfred Perlstein for raising this issue to the point of absurdity and hijacking god-only-knows how many hours of developer time in debating this whole thing. With friends like this, who needs competition from Linux? ;) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 20:24:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 91C4937B71A; Sat, 17 Mar 2001 20:24:06 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id PAA28881; Sun, 18 Mar 2001 15:23:58 +1100 Date: Sun, 18 Mar 2001 15:23:40 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Warner Losh Cc: John Baldwin , Matthew Jacob , arch@FreeBSD.ORG Subject: Re: man pages In-Reply-To: <200103171803.f2HI3Q945895@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 17 Mar 2001, Warner Losh wrote: > I have a device that I've written a driver for. The device has a data > pump <-> FIFO <-> DMA ENGINE on it. So far fairly standard. However, > I get an interrupt when the first byte hits the FIFO. I then have a > very small window to program the DMA ENGINE before the FIFO fills up. > When I'm in my interrupt handler, I want to disable *ALL* interrupts > so that I can do the complicated handsprings necessary to turn on the > DMA ENGINE as fast as possible without *ANY* interruption. If I miss > my window, I either miss data, or due to a hardware bug, I hang the > PCI bus. This is an embedded system, so I don't have to worry about > the mouse being responsive :-) > > I tried using splhigh(), but found that intr_disable() and > intr_enable() in the old code proved to work more reliably in > practice than splhigh(). This is a good bad example. It's too late to disable interrupts in the interrupt handler, because the handler might not be called until long after the hardware asserts an interrupt (a delay of 20 msec is not impossible, especially in -current). > No, I don't know why. Just wanted to show > an example that needed it, not for syncronization, but to assume total > control of the CPU and to make everyone else wait while I do my > semi-time critical hardware frobbing. You should know better :-). A device where you start i/o in a non-interrupt-driven way and have to continue the i/o within a certain time would give a better example. In your example, if missing the window would be fatal, to work under FreeBSD you need to use a fast interrupt handler under FreeBSD-4.x or better (fast interrupt handlers are broken in -current), and arrange for all other fast interrupt handlers combined to not break the window (this probably involves not having any other active ones). If missing the windows wouldn't be fatal, then just use a normal interrupt handler and recover from errors. Fast interrupt handlers are too hard to use to use routinely. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 21:23: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id AE7F337B718; Sat, 17 Mar 2001 21:22:59 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id QAA31596; Sun, 18 Mar 2001 16:22:55 +1100 Date: Sun, 18 Mar 2001 16:22:37 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Matthew Jacob Cc: John Baldwin , arch@FreeBSD.ORG Subject: Re: 'final' man pages In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 17 Mar 2001, Matthew Jacob wrote: > Incorporating Terry's comments, here's my last cut for the three > functions... I think it's better if they're separate man pages. > > Can we all move to closure on this? The only other issue I can think of here > is the semantics of an enable_intr() in between a disable_intr/restore_intr > call. No. I don't agree that these functions have the correct semantics. The Solaris ddi functions that you quoted are much better. > .Sh SYNOPSIS > .Fd #include > .Ft void > .Fn restore_intr "intrmask_t" Should be: .Fd #include .Fd #include ... ( is an implementation detail. It should never be included directly.) >... > .Fn disable_intr "void" > .Sh DESCRIPTION >... > The purpose of this function is inhibit interrupts from being dispatched > to the calling CPU. It may be used to ensure the timely execution of short > segments of hardware dependent critical code. It may also be used > to ensure the preservation of certain platform specific machine state > when calls outside of the kernel (e.g., to supporting PROM code) are made. I think MD functions should be used for preserving MD state. The MI functions may do things that are irrelevant or just wrong for entering PROMs... > .Sh RETURN VALUES > Returns a interrupt mask value that is to be later passed state (masks and levels have very different semantics which should probably be opaque here; better rename intrmask_t too) > .Xr restore_intr 9 . It's not even clear that interrupt states can be restored in a nested way. Some cases need to be handled like ithread priorities: a handler for a high priority interrupt may have to yield to the handler for a lower priority interrupt to contest a lock. This requires some non-nested handling of interrupt states. I discussed this with John (jhb). He was more pessimistic about it than me. I think things currently work on i386's because the interrupt state isn't all actually returned by save_intr() or restored by restore_intr(). Most of the state is in the ICU or APIC, and we depend on this because the state is a mask and not a level. Priority propagation is more complicated because low priority interrupts aren't masked while high priority ones are being handled; we let them occur and then mask them. If we didn't have the global state in the ICU/APIC, then we would have to adjust the saved state in various stack frames, but this is too hard. OTOH, on alphas the interrupt state is controlled by a level and not a mask, so lower priority interrupts can't occur and I think nested handling of interrupt states works right provided ithread priorities work right. Only the case where the interrupt state is a mask and is all returned by save_intr() is broken, and we don't support any machines that require that. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 22:35:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id B555137B71A; Sat, 17 Mar 2001 22:35:21 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id WAA29192; Sat, 17 Mar 2001 22:35:16 -0800 Date: Sat, 17 Mar 2001 22:35:12 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Bruce Evans Cc: John Baldwin , arch@FreeBSD.ORG Subject: Re: 'final' man pages In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 18 Mar 2001, Bruce Evans wrote: > On Sat, 17 Mar 2001, Matthew Jacob wrote: > > > Incorporating Terry's comments, here's my last cut for the three > > functions... I think it's better if they're separate man pages. > > > > Can we all move to closure on this? The only other issue I can think of here > > is the semantics of an enable_intr() in between a disable_intr/restore_intr > > call. > > No. I don't agree that these functions have the correct semantics. The > Solaris ddi functions that you quoted are much better. *chortle* Heads I win, Tails you lose (I wrote that function and man page for Solaris 2.0). > > > .Sh SYNOPSIS > > .Fd #include > > .Ft void > > .Fn restore_intr "intrmask_t" > > Should be: > > .Fd #include > .Fd #include > ... > > ( is an implementation detail. It should never be > included directly.) Urmm.. Huh. John told me to do it! It's his fault! > > >... > > .Fn disable_intr "void" > > .Sh DESCRIPTION > >... > > The purpose of this function is inhibit interrupts from being dispatched > > to the calling CPU. It may be used to ensure the timely execution of short > > segments of hardware dependent critical code. It may also be used > > to ensure the preservation of certain platform specific machine state > > when calls outside of the kernel (e.g., to supporting PROM code) are made. > > I think MD functions should be used for preserving MD state. The MI > functions may do things that are irrelevant or just wrong for entering > PROMs... I'm not following this. Entry to the PROM is certainly an MD function. It may start as an MI function, but has to go through MD code. > > > .Sh RETURN VALUES > > Returns a interrupt mask value that is to be later passed > state (masks and levels have very different semantics > which should probably be opaque here; better > rename intrmask_t too) > > .Xr restore_intr 9 . > > It's not even clear that interrupt states can be restored in a nested > way. Yes. Bruce- the following paragrahph is really hard to parse. I *think* you're saying that we cannot guarantee nesting. That's a fair addition. Anything else? > Some cases need to be handled like ithread priorities: a handler > for a high priority interrupt may have to yield to the handler for a > lower priority interrupt to contest a lock. This requires some non-nested > handling of interrupt states. I discussed this with John (jhb). He was > more pessimistic about it than me. I think things currently work on > i386's because the interrupt state isn't all actually returned by > save_intr() or restored by restore_intr(). Most of the state is in the > ICU or APIC, and we depend on this because the state is a mask and not > a level. Priority propagation is more complicated because low priority > interrupts aren't masked while high priority ones are being handled; we > let them occur and then mask them. If we didn't have the global state > in the ICU/APIC, then we would have to adjust the saved state in various > stack frames, but this is too hard. OTOH, on alphas the interrupt state > is controlled by a level and not a mask, so lower priority interrupts > can't occur and I think nested handling of interrupt states works right > provided ithread priorities work right. Only the case where the interrupt > state is a mask and is all returned by save_intr() is broken, and we don't > support any machines that require that. > > Bruce > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 23:23:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 80C1E37B719; Sat, 17 Mar 2001 23:23:38 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f2I7NY948714; Sun, 18 Mar 2001 00:23:34 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200103180723.f2I7NY948714@harmony.village.org> To: Bruce Evans Subject: Re: man pages t Cc: John Baldwin , Matthew Jacob , arch@FreeBSD.ORG In-reply-to: Your message of "Sun, 18 Mar 2001 15:23:40 +1100." References: Date: Sun, 18 Mar 2001 00:23:34 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Bruce Evans writes: : This is a good bad example. It's too late to disable interrupts in the : interrupt handler, because the handler might not be called until long : after the hardware asserts an interrupt (a delay of 20 msec is not : impossible, especially in -current). Even for fast interrupts? On other hardware for the job I have now we see indications that 20ms might not be unreasonable a delay (we have interrupts going off 22x a second, which is really more like 45ms, and we seem to be missing interrupts on a heavily loaded system). : > No, I don't know why. Just wanted to show : > an example that needed it, not for syncronization, but to assume total : > control of the CPU and to make everyone else wait while I do my : > semi-time critical hardware frobbing. : : You should know better :-). : : A device where you start i/o in a non-interrupt-driven way and have to : continue the i/o within a certain time would give a better example. True. But all I had was the example at hand :-). This is real hardware with a real FreeBSD device driver. : In your example, if missing the window would be fatal, to work under : FreeBSD you need to use a fast interrupt handler under FreeBSD-4.x : or better (fast interrupt handlers are broken in -current), and : arrange for all other fast interrupt handlers combined to not break : the window (this probably involves not having any other active ones). I use a fast interrupt handler :-). I thought that disabling all interrupts kept even other fast interrupt handlers from running. And that was the difference between splhigh() and disable_intr(). The window is actually fairly large to get things going (something on the order of 500 longwords in the fifo, which gives a latency of something like 5ms since the frames come in every 33ms (60 fields a second is 30 frames a second and the data is squirted out such that 500 longwords is just under 5ms of data). We had all kinds of problems with 4.0 and non-fast interrupts on slow machines. On fast (600MHz+) machines we could likely get away with non-fast interrupts, but I haven't bothered to recode it since those are the only CPUs that the client can obtain for the boards in question (don't ask me why, I long since gave up trying to argue with them). : If missing the windows wouldn't be fatal, then just use a normal : interrupt handler and recover from errors. Fast interrupt handlers : are too hard to use to use routinely. Agreed. They should be easier. But with enough patience and skill, they can be used when you gotta have the response time. I've found that fast interrupts work out best when you have just a circular buffer of stuff and you don't need to do selwake from the interrupt handler (I'm not even sure you are allowed to do selwake from a fast interrupt handler). Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 17 23:40:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 549A637B725; Sat, 17 Mar 2001 23:40:09 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id SAA05202; Sun, 18 Mar 2001 18:40:03 +1100 Date: Sun, 18 Mar 2001 18:39:44 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Matthew Jacob Cc: John Baldwin , arch@FreeBSD.ORG Subject: Re: 'final' man pages In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 17 Mar 2001, Matthew Jacob wrote: > On Sun, 18 Mar 2001, Bruce Evans wrote: > > > On Sat, 17 Mar 2001, Matthew Jacob wrote: > > >... > > > .Fn disable_intr "void" > > > .Sh DESCRIPTION > > >... > > > The purpose of this function is inhibit interrupts from being dispatched > > > to the calling CPU. It may be used to ensure the timely execution of short > > > segments of hardware dependent critical code. It may also be used > > > to ensure the preservation of certain platform specific machine state > > > when calls outside of the kernel (e.g., to supporting PROM code) are made. > > > > I think MD functions should be used for preserving MD state. The MI > > functions may do things that are irrelevant or just wrong for entering > > PROMs... > > I'm not following this. Entry to the PROM is certainly an MD function. It may > start as an MI function, but has to go through MD code. It's MD, so the MI functions shouldn't be burdened with semantics to make them usable for it. If you start the PROM entry as an MI function, better reach the MD parts early so you can use them. This stuff is too MD to really share much code. > > > .Sh RETURN VALUES > > > Returns a interrupt mask value that is to be later passed > > state (masks and levels have very different semantics > > which should probably be opaque here; better > > rename intrmask_t too) > > > .Xr restore_intr 9 . > > > > It's not even clear that interrupt states can be restored in a nested > > way. > > Yes. > > Bruce- the following paragrahph is really hard to parse. I *think* you're > saying that we cannot guarantee nesting. That's a fair addition. Anything > else? I think there is no problem with guaranteeing nesting in drivers if drivers follow the rules, and this must be guaranteed so that drivers don't have to worry about. The public interfaces that we are discussing are mainly for drivers. If there is a problem with interrupt nesting, then it is in the implementation of mutexes and/or ithread scheduling. Whatever is used there need not be the same as the public interface. [Hard to parse paragraph repeated] > > Some cases need to be handled like ithread priorities: a handler > > for a high priority interrupt may have to yield to the handler for a > > lower priority interrupt to contest a lock. This requires some non-nested > > handling of interrupt states. I discussed this with John (jhb). He was > > more pessimistic about it than me. I think things currently work on > > i386's because the interrupt state isn't all actually returned by > > save_intr() or restored by restore_intr(). Most of the state is in the > > ICU or APIC, and we depend on this because the state is a mask and not > > a level. Priority propagation is more complicated because low priority > > interrupts aren't masked while high priority ones are being handled; we > > let them occur and then mask them. If we didn't have the global state > > in the ICU/APIC, then we would have to adjust the saved state in various > > stack frames, but this is too hard. OTOH, on alphas the interrupt state > > is controlled by a level and not a mask, so lower priority interrupts > > can't occur and I think nested handling of interrupt states works right > > provided ithread priorities work right. Only the case where the interrupt > > state is a mask and is all returned by save_intr() is broken, and we don't > > support any machines that require that. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message