From owner-freebsd-arch@FreeBSD.ORG Sun Oct 17 00:07:55 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91B4C16A4CE; Sun, 17 Oct 2004 00:07:55 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3977A43D1D; Sun, 17 Oct 2004 00:07:55 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.200] ([192.168.254.200]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i9H07v6U031895; Sat, 16 Oct 2004 18:07:58 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <4171B781.7010106@freebsd.org> Date: Sat, 16 Oct 2004 18:06:25 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Garance A Drosihn References: <20041016174419.GA96297@dragon.nuxi.com> In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-arch@freebsd.org Subject: Re: Proposal to restore traditional BSD behavior in . X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Oct 2004 00:07:55 -0000 Garance A Drosihn wrote: > At 10:44 AM -0700 10/16/04, David O'Brien wrote: > >> I'd like to restore the traditional BSD behavior that >> includes the content of in addition to the BSD bcmp, >> et. al. We changed our between 4.x and 5.x and now >> that we're at 5-STABLE I'm finding software that built fine on >> 4.x has an issue on 5.x. > > > I think it is definitely too late to do this for 5.3-RELEASE, > because we have no idea what software might be compiling fine > right now, but may break due to namespace conflicts if > starts pulling in . > > It looks like 5.x has gone 2 and a half years with not > including , and if we also ship 5.3-release in that state > then I suspect there isn't much point in switching back after > 5.3-release. I have no particular objection to the *idea*, but I > think we are past the point were we could make such a change. > We are indeed past the point for doing this for 5.3 and also RELENG_5. Scott From owner-freebsd-arch@FreeBSD.ORG Sun Oct 17 01:16:09 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D70316A4CE for ; Sun, 17 Oct 2004 01:16:09 +0000 (GMT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DE7C43D31 for ; Sun, 17 Oct 2004 01:16:09 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.13.1/8.13.1) with ESMTP id i9H1G8wr006207 for ; Sat, 16 Oct 2004 18:16:08 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id i9H1G8sn006206 for freebsd-arch@FreeBSD.ORG; Sat, 16 Oct 2004 18:16:08 -0700 (PDT) (envelope-from obrien) Date: Sat, 16 Oct 2004 18:16:08 -0700 From: "David O'Brien" To: freebsd-arch@FreeBSD.ORG Message-ID: <20041017011608.GA6140@dragon.nuxi.com> References: <20041016174419.GA96297@dragon.nuxi.com> <20041016183202.GA76917@VARK.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041016183202.GA76917@VARK.MIT.EDU> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 6.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 Subject: Re: Proposal to restore traditional BSD behavior in . X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@FreeBSD.ORG List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Oct 2004 01:16:09 -0000 On Sat, Oct 16, 2004 at 02:32:02PM -0400, David Schultz wrote: > On Sat, Oct 16, 2004, David O'Brien wrote: > > I'd like to restore the traditional BSD behavior that > > includes the content of in addition to the BSD bcmp, et. al. > > We changed our between 4.x and 5.x and now that we're at > > 5-STABLE I'm finding software that built fine on 4.x has an issue on 5.x. > > It has been this way for 2.5 years, and nobody has complained > until now AFAIK. Therefore, it seems unlikely that there's enough > affected unportable software out there to justify undoing the > efforts at reducing namespace pollution now. > > Moreover, there's a *lot* of pollution in string.h, where as > strings.h has very little. Polluting strings.h again increases > the chances that portable applications that use strings.h will > break due to naming conflicts. An application using is only portable across BSD's. isn't POSIX. I totally don't understand why we made a that is incompatible with our BSD breathern. -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Sun Oct 17 01:17:14 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B02F316A4CE; Sun, 17 Oct 2004 01:17:14 +0000 (GMT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84A0C43D41; Sun, 17 Oct 2004 01:17:14 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.13.1/8.13.1) with ESMTP id i9H1HD1K006239; Sat, 16 Oct 2004 18:17:13 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id i9H1HDF0006238; Sat, 16 Oct 2004 18:17:13 -0700 (PDT) (envelope-from obrien) Date: Sat, 16 Oct 2004 18:17:13 -0700 From: "David O'Brien" To: Scott Long Message-ID: <20041017011712.GB6140@dragon.nuxi.com> References: <20041016174419.GA96297@dragon.nuxi.com> <4171B781.7010106@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4171B781.7010106@freebsd.org> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 6.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 cc: Garance A Drosihn cc: freebsd-arch@freebsd.org Subject: Re: Proposal to restore traditional BSD behavior in . X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Oct 2004 01:17:14 -0000 On Sat, Oct 16, 2004 at 06:06:25PM -0600, Scott Long wrote: > Garance A Drosihn wrote: > >At 10:44 AM -0700 10/16/04, David O'Brien wrote: > > > >>I'd like to restore the traditional BSD behavior that > >>includes the content of in addition to the BSD bcmp, > >>et. al. We changed our between 4.x and 5.x and now > >>that we're at 5-STABLE I'm finding software that built fine on > >>4.x has an issue on 5.x. > > > > > >I think it is definitely too late to do this for 5.3-RELEASE, > >because we have no idea what software might be compiling fine > >right now, but may break due to namespace conflicts if > >starts pulling in . > > > >It looks like 5.x has gone 2 and a half years with not > >including , and if we also ship 5.3-release in that state > >then I suspect there isn't much point in switching back after > >5.3-release. I have no particular objection to the *idea*, but I > >think we are past the point were we could make such a change. > > > > We are indeed past the point for doing this for 5.3 and also RELENG_5. Why? It is a bug that BSD strings.h doesn't include definintions for str*. Bugs can't be fixed in RELENG_5? I never asked for it to be fixed in 5.3. -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Sun Oct 17 04:37:14 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E116316A4D1 for ; Sun, 17 Oct 2004 04:37:14 +0000 (GMT) Received: from node15.coopprint.com (node15.cooperativeprinting.com [208.4.77.15]) by mx1.FreeBSD.org (Postfix) with SMTP id 78A8D43D45 for ; Sun, 17 Oct 2004 04:37:14 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 67960 invoked by uid 0); 17 Oct 2004 04:36:13 -0000 Received: from unknown (HELO ?192.168.0.5?) (63.231.165.205) by node15.coopprint.com with SMTP; 17 Oct 2004 04:36:13 -0000 Message-ID: <4171F702.9020405@gamersimpact.com> Date: Sat, 16 Oct 2004 23:37:22 -0500 From: Ryan Sommers User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: arch@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Removal of /stand Directory X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Oct 2004 04:37:15 -0000 After a thread on current@ and private discussion following, myself and the other party were in agreement that /stand serves no purpose after the initial install. Most of /stand is duplicated in /rescue with the exception of a few members. This makes the approx. 3mb of space consumed by /stand wasted space. The only post-install dependency on /stand I can find is the diskless rc script. This script uses /stand/cpio and /stand/gzip for unpacking template archives to populate memory disks. I have come up with two solutions that would solve this problem. The first involves /bin/pax and moving gzip to /bin/gzip. This would be enough to unpack archives for diskless systems. The other is to use /rescue/tar and /rescue/gzip. Currently /rescue uses gtar, however, this will likely be switched to bsdtar after 5.3-RELEASE (see PR bin/72549). This will add cpio and pax support to /rescue/tar (in addition to saving approx. 40k). I don't believe using /rescue is the correct solution for diskless systems. Which is why I propose moving gzip to /bin. This would increase /bin by about 46k. However, upon removing /stand the net would be a savings in the root partition. /bin/pax and gzip are capable of handling the diskless template archives and will also be updated as part of world to receive any bugfixes. If people agree with this, after providing patches for moving gzip to /bin I plan on addressing sysinstall to have /stand removed as part of the post-install cleanup/configuration. And then after I'd like to work on bringing our support and instructions for diskless environments up to date with 5.X. Anyone have any thoughts, objections, feelings on this? If anyone has already started work on this but doesn't have the time let me know and I'd be happy to pick up where they left off. Otherwise I'm willing to put in the grunt work if anyone is willing to help commit it once 5.3-release is out of the way. -- Ryan Sommers ryans@gamersimpact.com From owner-freebsd-arch@FreeBSD.ORG Sun Oct 17 04:44:59 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49DA016A4CE; Sun, 17 Oct 2004 04:44:59 +0000 (GMT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id D341243D54; Sun, 17 Oct 2004 04:44:58 +0000 (GMT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id i9H4iuqw077076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Sun, 17 Oct 2004 00:44:57 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id i9H4iu1M077075; Sun, 17 Oct 2004 00:44:56 -0400 (EDT) (envelope-from wollman) Date: Sun, 17 Oct 2004 00:44:56 -0400 (EDT) From: Garrett Wollman Message-Id: <200410170444.i9H4iu1M077075@khavrinen.lcs.mit.edu> To: obrien@freebsd.org In-Reply-To: <20041017011608.GA6140@dragon.nuxi.com> References: <20041016174419.GA96297@dragon.nuxi.com> <20041016183202.GA76917@VARK.MIT.EDU> Organization: MIT Laboratory for Computer Science X-Spam-Score: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.37 cc: arch@freebsd.org Subject: Re: Proposal to restore traditional BSD behavior in . X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Oct 2004 04:44:59 -0000 In article <20041017011608.GA6140@dragon.nuxi.com> you write: >On Sat, Oct 16, 2004 at 02:32:02PM -0400, David Schultz wrote: >> On Sat, Oct 16, 2004, David O'Brien wrote: >> > I'd like to restore the traditional BSD behavior that >> > includes the content of in addition to the BSD bcmp, et. al. >> > We changed our between 4.x and 5.x and now that we're at >> > 5-STABLE I'm finding software that built fine on 4.x has an issue on 5.x. >> >> It has been this way for 2.5 years, and nobody has complained >> until now AFAIK. Therefore, it seems unlikely that there's enough >> affected unportable software out there to justify undoing the >> efforts at reducing namespace pollution now. >> >> Moreover, there's a *lot* of pollution in string.h, where as >> strings.h has very little. Polluting strings.h again increases >> the chances that portable applications that use strings.h will >> break due to naming conflicts. > > isn't POSIX. BZZZT! Wrong, but thanks for playing. See XBD6 page 331. However, it is an XSI header, and we don't claim to support XSI, so theoretically we can define anything we want in . I believe, however, that it has been a better policy to force-migrate users of the functions specified in the C standard to the header specified in the C standard. -GAWollman From owner-freebsd-arch@FreeBSD.ORG Sun Oct 17 17:32:44 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB36A16A4CE for ; Sun, 17 Oct 2004 17:32:44 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3423343D41 for ; Sun, 17 Oct 2004 17:32:42 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i9HHWnmE034845; Sun, 17 Oct 2004 11:32:49 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <4172AC60.2020405@freebsd.org> Date: Sun, 17 Oct 2004 11:31:12 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryan Sommers References: <4171F702.9020405@gamersimpact.com> In-Reply-To: <4171F702.9020405@gamersimpact.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: arch@freebsd.org Subject: Re: Removal of /stand Directory X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Oct 2004 17:32:44 -0000 Ryan Sommers wrote: > After a thread on current@ and private discussion following, myself and > the other party were in agreement that /stand serves no purpose after > the initial install. Most of /stand is duplicated in /rescue with the > exception of a few members. This makes the approx. 3mb of space consumed > by /stand wasted space. > > The only post-install dependency on /stand I can find is the diskless rc > script. This script uses /stand/cpio and /stand/gzip for unpacking > template archives to populate memory disks. I have come up with two > solutions that would solve this problem. The first involves /bin/pax and > moving gzip to /bin/gzip. This would be enough to unpack archives for > diskless systems. The other is to use /rescue/tar and /rescue/gzip. > > Currently /rescue uses gtar, however, this will likely be switched to > bsdtar after 5.3-RELEASE (see PR bin/72549). This will add cpio and pax > support to /rescue/tar (in addition to saving approx. 40k). I don't > believe using /rescue is the correct solution for diskless systems. > > Which is why I propose moving gzip to /bin. This would increase /bin by > about 46k. However, upon removing /stand the net would be a savings in > the root partition. /bin/pax and gzip are capable of handling the > diskless template archives and will also be updated as part of world to > receive any bugfixes. > > If people agree with this, after providing patches for moving gzip to > /bin I plan on addressing sysinstall to have /stand removed as part of > the post-install cleanup/configuration. And then after I'd like to work > on bringing our support and instructions for diskless environments up to > date with 5.X. > > Anyone have any thoughts, objections, feelings on this? If anyone has > already started work on this but doesn't have the time let me know and > I'd be happy to pick up where they left off. Otherwise I'm willing to > put in the grunt work if anyone is willing to help commit it once > 5.3-release is out of the way. > I think that this is generally a good idea. On a larger scale I'd like to see the disc1 installer become a full live filesystem so that stand isn't needed at all. Any interest in helping with that? Scott From owner-freebsd-arch@FreeBSD.ORG Mon Oct 18 14:21:11 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19ED916A4CE for ; Mon, 18 Oct 2004 14:21:11 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5350543D46 for ; Mon, 18 Oct 2004 14:21:10 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i9IFJDeM011154 for ; Mon, 18 Oct 2004 10:19:13 -0500 Date: Mon, 18 Oct 2004 10:19:13 -0500 (EST) From: Sam X-X-Sender: sah@athena To: freebsd-arch@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Geom / mount / AoE disk failure X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2004 14:21:11 -0000 Hello all, I'm in final testing of the AoE driver for 5.3 and have a question about disk device failures for mounted filesystems. I have an ED blade on my desk that I can pull the power from. The driver has a timeout so that if the blade doesn't respond in N seconds, all outstanding IO is failed and the disk is either a) destroyed if not open or b) marked for destruction on final close. If I dd from the device, in this case /dev/aoed10, and pull the power mid transfer, dd fails and the device is removed on close as expected. If I mount a portion of the disk, /dev/aoed10s1a, and while dd'ing from a file on the mount pull the power, dd fails, but the mount point persists. This seems expected, but when I force the umount (umount -f), I never get a final close. I get this in the log: --- Oct 18 09:53:29 fivethree kernel: fsync: giving up on dirty: 0xc1805b58: tag devfs, type VCHR, usecount 2, writecount 0 , refcount 5, flags (VV_OBJBUF), lock type devfs: EXCL (count 1) by thread 0xc1341c80 (pid 40414) Oct 18 09:53:29 fivethree kernel: dev aoed10s1a Oct 18 09:53:37 fivethree kernel: fsync: giving up on dirty: 0xc1805b58: tag devfs, type VCHR, usecount 2, writecount 0 , refcount 5, flags (VV_OBJBUF), lock type devfs: EXCL (count 1) by thread 0xc1345190 (pid 40416) Oct 18 09:53:37 fivethree kernel: dev aoed10s1a Oct 18 09:53:37 fivethree kernel: fsync: giving up on dirty: 0xc1805b58: tag devfs, type VCHR, usecount 1, writecount 0 , refcount 5, flags (VV_OBJBUF), lock type devfs: EXCL (count 1) by thread 0xc1345190 (pid 40416) Oct 18 09:53:37 fivethree kernel: dev aoed10s1a Oct 18 09:53:58 fivethree kernel: fsync: giving up on dirty: 0xc1805b58: tag devfs, type VCHR, usecount 2, writecount 0 , refcount 5, flags (VV_OBJBUF), lock type devfs: EXCL (count 1) by thread 0xc142a190 (pid 40419) Oct 18 09:53:58 fivethree kernel: dev aoed10s1a Oct 18 09:53:58 fivethree kernel: fsync: giving up on dirty: 0xc1805b58: tag devfs, type VCHR, usecount 1, writecount 0 , refcount 5, flags (VV_OBJBUF), lock type devfs: EXCL (count 1) by thread 0xc142a190 (pid 40419) Oct 18 09:53:58 fivethree kernel: dev aoed10s1a Oct 18 09:53:59 fivethree kernel: fsync: giving up on dirty: 0xc1805b58: tag devfs, type VCHR, usecount 2, writecount 0 , refcount 5, flags (VV_OBJBUF), lock type devfs: EXCL (count 1) by thread 0xc112e960 (pid 40420) Oct 18 09:53:59 fivethree kernel: dev aoed10s1a Oct 18 09:53:59 fivethree kernel: fsync: giving up on dirty: 0xc1805b58: tag devfs, type VCHR, usecount 1, writecount 0 , refcount 5, flags (VV_OBJBUF), lock type devfs: EXCL (count 1) by thread 0xc112e960 (pid 40420) --- Please excuse the formatting, this mail client isn't the best. Is this the expected behaviour? Since I never get the final close, I can't reinitialize the device when I power it back up, unload the module, etc. Should I be doing something else to trigger that the device is gone besides just failing the bios (EIO)? Maybe there's something that GEOM is expecting that I'm not doing? Cheers, Sam From owner-freebsd-arch@FreeBSD.ORG Mon Oct 18 15:12:20 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24DAE16A4CE for ; Mon, 18 Oct 2004 15:12:20 +0000 (GMT) Received: from saturn.criticalmagic.com (saturn.criticalmagic.com [64.74.124.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1FEA43D55 for ; Mon, 18 Oct 2004 15:12:19 +0000 (GMT) (envelope-from rcoleman@criticalmagic.com) Received: from [10.40.30.144] (borg.ciphertrust.com [64.238.118.66]) by saturn.criticalmagic.com (Postfix) with ESMTP id 04D533BD5E; Mon, 18 Oct 2004 11:12:18 -0400 (EDT) Message-ID: <4173DD4F.1030501@criticalmagic.com> Date: Mon, 18 Oct 2004 11:12:15 -0400 From: Richard Coleman Organization: Critical Magic, Inc. User-Agent: Mozilla Thunderbird 0.7.3 (X11/20041008) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryan Sommers References: <4171F702.9020405@gamersimpact.com> In-Reply-To: <4171F702.9020405@gamersimpact.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: Removal of /stand Directory X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2004 15:12:20 -0000 Ryan Sommers wrote: > After a thread on current@ and private discussion following, myself and > the other party were in agreement that /stand serves no purpose after > the initial install. Most of /stand is duplicated in /rescue with the > exception of a few members. This makes the approx. 3mb of space consumed > by /stand wasted space. > > The only post-install dependency on /stand I can find is the diskless rc > script. This script uses /stand/cpio and /stand/gzip for unpacking > template archives to populate memory disks. I have come up with two > solutions that would solve this problem. The first involves /bin/pax and > moving gzip to /bin/gzip. This would be enough to unpack archives for > diskless systems. The other is to use /rescue/tar and /rescue/gzip. > > Currently /rescue uses gtar, however, this will likely be switched to > bsdtar after 5.3-RELEASE (see PR bin/72549). This will add cpio and pax > support to /rescue/tar (in addition to saving approx. 40k). I don't > believe using /rescue is the correct solution for diskless systems. > > Which is why I propose moving gzip to /bin. This would increase /bin by > about 46k. However, upon removing /stand the net would be a savings in > the root partition. /bin/pax and gzip are capable of handling the > diskless template archives and will also be updated as part of world to > receive any bugfixes. > > If people agree with this, after providing patches for moving gzip to > /bin I plan on addressing sysinstall to have /stand removed as part of > the post-install cleanup/configuration. And then after I'd like to work > on bringing our support and instructions for diskless environments up to > date with 5.X. > > Anyone have any thoughts, objections, feelings on this? If anyone has > already started work on this but doesn't have the time let me know and > I'd be happy to pick up where they left off. Otherwise I'm willing to > put in the grunt work if anyone is willing to help commit it once > 5.3-release is out of the way. Bsdtar has internal support for gzip/bzip2 compression. So, if the move was made to use bsdtar would this allow the diskless setup to no longer depend on gzip? Of course, the dependency on /lib/libz.so and /usr/lib/libz2.so would need to be dealt with. I'm not sure what that does to your diskspace calculations. Of course, I still find it odd that tar and cpio are in /usr/bin, but pax is in /bin. But that's a bikeshed for another day when we are really bored. Richard Coleman rcoleman@criticalmagic.com From owner-freebsd-arch@FreeBSD.ORG Mon Oct 18 17:30:58 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7843916A4CE for ; Mon, 18 Oct 2004 17:30:58 +0000 (GMT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36A8043D48 for ; Mon, 18 Oct 2004 17:30:58 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.13.1/8.13.1) with ESMTP id i9IHUiaA005645; Mon, 18 Oct 2004 10:30:44 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id i9IHUh7Y005644; Mon, 18 Oct 2004 10:30:43 -0700 (PDT) (envelope-from obrien) Date: Mon, 18 Oct 2004 10:30:43 -0700 From: "David O'Brien" To: Richard Coleman Message-ID: <20041018173043.GE5179@dragon.nuxi.com> Mail-Followup-To: David O'Brien , Richard Coleman , Ryan Sommers , arch@freebsd.org References: <4171F702.9020405@gamersimpact.com> <4173DD4F.1030501@criticalmagic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4173DD4F.1030501@criticalmagic.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 6.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 cc: Ryan Sommers cc: arch@freebsd.org Subject: Re: Removal of /stand Directory X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2004 17:30:58 -0000 On Mon, Oct 18, 2004 at 11:12:15AM -0400, Richard Coleman wrote: > Of course, I still find it odd that tar and cpio are in /usr/bin, but > pax is in /bin. But that's a bikeshed for another day when we are > really bored. pax(1) can read (ie, restore from tape) both tar and cpio archives. So why litter /bin up with 3 programs when 1 will do? -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Mon Oct 18 17:49:28 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A580C16A4CE for ; Mon, 18 Oct 2004 17:49:28 +0000 (GMT) Received: from mailserv1.neuroflux.com (mailserv1.neuroflux.com [204.228.228.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1ED5243D41 for ; Mon, 18 Oct 2004 17:49:28 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 35696 invoked by uid 89); 18 Oct 2004 17:57:10 -0000 Received: from unknown (HELO www2.neuroflux.com) (127.0.0.1) by localhost with SMTP; 18 Oct 2004 17:57:10 -0000 Received: from 208.4.77.15 (SquirrelMail authenticated user ryans@gamersimpact.com); by www2.neuroflux.com with HTTP; Mon, 18 Oct 2004 11:57:10 -0600 (MDT) Message-ID: <65010.208.4.77.15.1098122230.squirrel@208.4.77.15> In-Reply-To: <20041018173043.GE5179@dragon.nuxi.com> References: <4171F702.9020405@gamersimpact.com> <4173DD4F.1030501@criticalmagic.com> <20041018173043.GE5179@dragon.nuxi.com> Date: Mon, 18 Oct 2004 11:57:10 -0600 (MDT) From: "Ryan Sommers" To: obrien@freebsd.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20041018115710_45604" X-Priority: 3 (Normal) Importance: Normal X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: Ryan Sommers cc: Richard Coleman cc: arch@freebsd.org Subject: Re: Removal of /stand Directory X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2004 17:49:28 -0000 ------=_20041018115710_45604 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit David O'Brien said: > On Mon, Oct 18, 2004 at 11:12:15AM -0400, Richard Coleman wrote: >> Of course, I still find it odd that tar and cpio are in /usr/bin, but >> pax is in /bin. But that's a bikeshed for another day when we are >> really bored. > > pax(1) can read (ie, restore from tape) both tar and cpio archives. So > why litter /bin up with 3 programs when 1 will do? I tend to agree. Adding bsdtar to the root filesystem would mean not only bringing in bsdtar but also 2 more shared libraries /usr/lib/libarchive.so and /usr/lib/libbz2.so. We can just bring gzip into /bin and get all the functionality of cpio, bsdtar and pax without adding 2 extra libraries. This also will allow us to not only unarchive gzipped archives but also decompress single files, something I don't think bsdtar -z can do. Attached is a tarball of the modifications. To add it to your source tree: cd /usr/src (or your respective directory) ; tar zxvf /path/to/gzip-to-bin.tgz ; rm -rf gnu/usr.bin/gzip This is strictly a Makefile change to the Makefiles in gnu and subdirs and rescue/rescue/Makefile. Following is the patch for existing Makefiles (note, don't try to build off it because it doesn't take into account the directory move: Index: Makefile =================================================================== RCS file: /home/ncvs/src/gnu/Makefile,v retrieving revision 1.36 diff -u -r1.36 Makefile --- Makefile 5 Jun 2002 17:02:37 -0000 1.36 +++ Makefile 18 Oct 2004 14:23:19 -0000 @@ -1,6 +1,6 @@ # @(#)Makefile 5.33.1.1 (Berkeley) 5/6/91 # $FreeBSD: src/gnu/Makefile,v 1.36 2002/06/05 17:02:37 obrien Exp $ -SUBDIR= lib usr.bin +SUBDIR= lib usr.bin bin .include Index: usr.bin/Makefile =================================================================== RCS file: /home/ncvs/src/gnu/usr.bin/Makefile,v retrieving revision 1.82 diff -u -r1.82 Makefile --- usr.bin/Makefile 7 Jul 2004 17:24:30 -0000 1.82 +++ usr.bin/Makefile 18 Oct 2004 14:23:19 -0000 @@ -13,7 +13,6 @@ ${_gperf} \ grep \ ${_groff} \ - gzip \ man \ patch \ rcs \ Index: Makefile =================================================================== RCS file: /home/ncvs/src/rescue/rescue/Makefile,v retrieving revision 1.28 diff -u -r1.28 Makefile --- Makefile 16 Aug 2004 03:16:48 -0000 1.28 +++ Makefile 18 Oct 2004 14:31:56 -0000 @@ -92,6 +92,11 @@ CRUNCH_SUPPRESS_LINK_-tcsh= 1 .endif +CRUNCH_SRCDIRS+= gnu/bin +CRUNCH_PROGS_gnu/bin+= gzip +CRUNCH_ALIAS_gzip= gunzip gzcat zcat + + ################################################################### # Programs from standard /sbin # @@ -186,9 +191,6 @@ CRUNCH_SRCDIRS+= usr.bin CRUNCH_SRCDIRS+= gnu/usr.bin -CRUNCH_PROGS_gnu/usr.bin+= gzip -CRUNCH_ALIAS_gzip= gunzip gzcat zcat - CRUNCH_PROGS_usr.bin+= bzip2 CRUNCH_ALIAS_bzip2= bunzip2 bzcat CRUNCH_LIBS+= -lbz2 I tested this against a (build|install)world this morning. -- Ryan Sommers ryans@gamersimpact.com ------=_20041018115710_45604-- From owner-freebsd-arch@FreeBSD.ORG Mon Oct 18 19:18:32 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A67016A4CF; Mon, 18 Oct 2004 19:18:32 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id A556B43D39; Mon, 18 Oct 2004 19:18:31 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 39E495313; Mon, 18 Oct 2004 21:18:30 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 5EC26530A; Mon, 18 Oct 2004 21:18:24 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id 27D68B861; Mon, 18 Oct 2004 21:18:24 +0200 (CEST) To: David O'Brien References: <4171F702.9020405@gamersimpact.com> <4173DD4F.1030501@criticalmagic.com> <20041018173043.GE5179@dragon.nuxi.com> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Mon, 18 Oct 2004 21:18:24 +0200 In-Reply-To: <20041018173043.GE5179@dragon.nuxi.com> (David O'Brien's message of "Mon, 18 Oct 2004 10:30:43 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.64 cc: Ryan Sommers cc: Richard Coleman cc: arch@freebsd.org Subject: Re: Removal of /stand Directory X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2004 19:18:32 -0000 "David O'Brien" writes: > pax(1) can read (ie, restore from tape) both tar and cpio archives. So > why litter /bin up with 3 programs when 1 will do? Agreed, bsdtar can handle all those formats, so there's no real need to have pax(1) or cpio(1) at all except perhaps as hard links to bsdtat(1). DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Mon Oct 18 19:20:09 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6909816A4CE; Mon, 18 Oct 2004 19:20:09 +0000 (GMT) Received: from saturn.criticalmagic.com (saturn.criticalmagic.com [64.74.124.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3444D43D2F; Mon, 18 Oct 2004 19:20:09 +0000 (GMT) (envelope-from rcoleman@criticalmagic.com) Received: from [10.40.30.144] (borg.ciphertrust.com [64.238.118.66]) by saturn.criticalmagic.com (Postfix) with ESMTP id 2755D3BD10; Mon, 18 Oct 2004 15:20:08 -0400 (EDT) Message-ID: <41741764.4040304@criticalmagic.com> Date: Mon, 18 Oct 2004 15:20:04 -0400 From: Richard Coleman Organization: Critical Magic, Inc. User-Agent: Mozilla Thunderbird 0.7.3 (X11/20041008) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryan Sommers References: <4171F702.9020405@gamersimpact.com> <4173DD4F.1030501@criticalmagic.com> <20041018173043.GE5179@dragon.nuxi.com> <65010.208.4.77.15.1098122230.squirrel@208.4.77.15> In-Reply-To: <65010.208.4.77.15.1098122230.squirrel@208.4.77.15> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: Removal of /stand Directory X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2004 19:20:09 -0000 Ryan Sommers wrote: > David O'Brien said: > >> On Mon, Oct 18, 2004 at 11:12:15AM -0400, Richard Coleman wrote: >> >>> Of course, I still find it odd that tar and cpio are in /usr/bin, >>> but pax is in /bin. But that's a bikeshed for another day when >>> we are really bored. >> >> pax(1) can read (ie, restore from tape) both tar and cpio archives. >> So why litter /bin up with 3 programs when 1 will do? > > > I tend to agree. Adding bsdtar to the root filesystem would mean not > only bringing in bsdtar but also 2 more shared libraries > /usr/lib/libarchive.so and /usr/lib/libbz2.so. We can just bring gzip > into /bin and get all the functionality of cpio, bsdtar and pax > without adding 2 extra libraries. This also will allow us to not only > unarchive gzipped archives but also decompress single files, > something I don't think bsdtar -z can do. But I wouldn't be surprised if pax (and cpio) are eventually rewritten to use libarchive as well. So this issue my come up again. Tim has done such great work with libarchive, it really makes sense to do this. Of course, until someone actually does the work, it's just speculation. I'm just happy you are making the effort to do the cleanup. So take all this as just friendly discussion. It's all good. Richard Coleman rcoleman@criticalmagic.com From owner-freebsd-arch@FreeBSD.ORG Tue Oct 19 10:27:13 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69F5A16A4CE; Tue, 19 Oct 2004 10:27:13 +0000 (GMT) Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65C8B43D54; Tue, 19 Oct 2004 10:27:10 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd05.aul.t-online.de by mailout04.sul.t-online.com with smtp id 1CJrCs-000615-0C; Tue, 19 Oct 2004 12:27:06 +0200 Received: from Andro-Beta.Leidinger.net (GWWRAvZ6ZeZJucSierJR-Wve8zZfBNwwvHuaKdoR5wC-cQtG4QPLUL@[217.83.28.19]) by fmrl05.sul.t-online.com with esmtp id 1CJrCo-1at0RE0; Tue, 19 Oct 2004 12:27:02 +0200 Received: from Andro-Beta.Leidinger.net (localhost [127.0.0.1]) i9JAQxLd034512; Tue, 19 Oct 2004 12:26:59 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: (from www@localhost)i9JAQwLk034511; Tue, 19 Oct 2004 12:26:58 +0200 (CEST) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: Andro-Beta.Leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from wwwproxy-2.sns-felb.debis.de (wwwproxy-2.sns-felb.debis.de [53.122.192.14]) by netchild.homeip.net (IMP) with HTTP for ; Tue, 19 Oct 2004 12:26:55 +0200 Message-ID: <1098181615.4174ebefefd87@netchild.homeip.net> Date: Tue, 19 Oct 2004 12:26:55 +0200 From: Alexander Leidinger To: obrien@freebsd.org References: <200410180534.i9I5YsGn053852@repoman.freebsd.org> <1098101272.4173b21825a40@netchild.homeip.net> <20041018173955.GB5737@dragon.nuxi.com> <20041018182522.GA10529@dragon.nuxi.com> In-Reply-To: <20041018182522.GA10529@dragon.nuxi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 / FreeBSD-4.10 X-Originating-IP: 53.122.192.14 X-ID: GWWRAvZ6ZeZJucSierJR-Wve8zZfBNwwvHuaKdoR5wC-cQtG4QPLUL@t-dialin.net X-TOI-MSGID: 4551b876-8164-4acc-8d5d-b6de7218f393 cc: Dag-Erling Sm?rgrav cc: arch@freebsd.org Subject: Quiet mode for pkg_install (was: Re: cvs commit: src/usr.sbin/pkg_install/info info.h main.c src/usr.sbin/pkg_install/lib global.c lib.h src/usr.sbin/pkg_install/version main.c perform.c pkg_version.1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 10:27:13 -0000 Zitat von David O'Brien : [Moved to arch@] > One might want a list of packages for other things. I can't believe a > simple -q[uiet] switch is being bike shed. No, wait, this is FreeBSD I > *can* believe it. It's a nice feature, no objections, sorry if I sounded as if I object to it. But I think the implementation can be improved (from an usability point of view). When you use "-l", you already know if it is "<", "=" or ">", since you explicitely asked for it. So you don't need to have a "-q" switch here, it's enough to just omit the status indicator for "-l" by default. If you omit "-l" you don't need -q either, you can use ls to get a list of installed ports/packages when you don't want to see the status indicator. This covers all cases you seem to care about (judging from the commit log and your reply). For other cases (e.g. "-L") I don't see a need for a -q option. This doesn't mean much, I can't predict every use of pkg_version, but so far I'm not aware of someone who asked for such a feature. If you know someone who needs -q together with -L please tell me about it, I'm curious where it's needed. So it's not about bikesheding about "yes or no". It's about good usability. If you don't care about it, it's fine for me. I don't need this feature, so I spend my time on other (more important) things. Bye, Alexander. -- http://www.Leidinger.net/ Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org/ netchild @ FreeBSD.org : PGP ID = 72077137 Reisner's Rule of Conceptual Inertia: If you think big enough, you'll never have to do it. From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 14:58:08 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5709316A4CE; Wed, 20 Oct 2004 14:58:08 +0000 (GMT) Received: from web.portaone.com (support.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96DD143D1D; Wed, 20 Oct 2004 14:58:07 +0000 (GMT) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.73] (portacare.portaone.com [195.140.247.242]) (authenticated bits=0) by web.portaone.com (8.12.11/8.12.11) with ESMTP id i9KEw4Ns021581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Oct 2004 16:58:05 +0200 (CEST) (envelope-from sobomax@FreeBSD.org) Message-ID: <41767CF1.2020005@FreeBSD.org> Date: Wed, 20 Oct 2004 17:57:53 +0300 From: Maxim Sobolev User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "current@freebsd.org" Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit cc: arch@FreeBSD.org Subject: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 14:58:08 -0000 I think that this is good idea which can be adapted for our 6-CURRENT as well. Disk space is so damn cheap today.... -Maxim -------- Original Message -------- Subject: What do people think about not installing a stripped /kernel ? Date: Mon, 18 Oct 2004 15:12:00 -0700 (PDT) From: Matthew Dillon Newsgroups: dragonfly.kernel The only cost is disk space... e.g. 3MB stripped kernel verses 16MB debug kernel. But the debug info isn't actually loaded into memory so the kernel load time and memory overhead is the same as with the stripped version. The issue is bug reports and kernel core dumps. I can't count the number of times I have had to carefully instruct people to retrieve their kernel.debug's for bug reporting purposes. And even my own debugging would be more convenient if I didn't have to save off a separate copy of the debug version of the kernel. What I'm thinking of doing is having the installkernel target install the debug version rather then the stripped version unless told to install the stripped version with a new option, e.g. 'options INSTALL_STRIPPED'. We would ship full debug GENERIC kernels instead of stripped kernels. i.e. we aren't getting rid of the ability to install a stripped kernel, we just aren't making it the default any more. What do people think? -Matt From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 15:16:57 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5AB7016A4D0 for ; Wed, 20 Oct 2004 15:16:57 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id D425D43D45 for ; Wed, 20 Oct 2004 15:16:56 +0000 (GMT) (envelope-from mitigator@gmail.com) Received: by mproxy.gmail.com with SMTP id 79so426704rnk for ; Wed, 20 Oct 2004 08:16:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=We/NqMRjKY3S2ySMlSiwUEVHxz8GWmOxgsya9EhTNxYtX/FeWjHwhzRWe84nn2LAkLj7OsUscv973S30BUrTV+C13jyCyLJ/x0ixOkfVWIgUn9ojbPXAFENIMrRHqlirmYxrYyfu62jwsEJeEpZNVUS45nW1YgS+jVnnKUdec70 Received: by 10.38.75.62 with SMTP id x62mr1460620rna; Wed, 20 Oct 2004 08:16:56 -0700 (PDT) Received: by 10.38.163.71 with HTTP; Wed, 20 Oct 2004 08:16:56 -0700 (PDT) Message-ID: <6ff30abd04102008163115a32d@mail.gmail.com> Date: Wed, 20 Oct 2004 10:16:56 -0500 From: jamie rishaw at google mail To: Maxim Sobolev In-Reply-To: <41767CF1.2020005@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41767CF1.2020005@FreeBSD.org> cc: arch@freebsd.org cc: current@freebsd.org Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jamie rishaw at google mail List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 15:16:57 -0000 What are the performance implications of a debug kernel? Disk space really shouldnt even be an issue.. if it is, and its down to the difference of 20 megs, well, duno. 512 meg CF's going for sub-$50 .. the only reason i could see even a debate would be any significant performance hits.. From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 15:18:15 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D05D016A4CE; Wed, 20 Oct 2004 15:18:15 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CE5B43D5C; Wed, 20 Oct 2004 15:18:15 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i9KFJAei014639; Wed, 20 Oct 2004 08:19:10 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i9KFJAqK014638; Wed, 20 Oct 2004 08:19:10 -0700 Date: Wed, 20 Oct 2004 08:19:10 -0700 From: Brooks Davis To: jamie rishaw at google mail Message-ID: <20041020151910.GC11477@odin.ac.hmc.edu> References: <41767CF1.2020005@FreeBSD.org> <6ff30abd04102008163115a32d@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6ff30abd04102008163115a32d@mail.gmail.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: Maxim Sobolev cc: current@freebsd.org cc: arch@freebsd.org Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 15:18:16 -0000 On Wed, Oct 20, 2004 at 10:16:56AM -0500, jamie rishaw at google mail wrote: > What are the performance implications of a debug kernel? None what so ever. The debugging bits are not loaded in to memory. -- Brooks From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 15:32:58 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E799916A4CF; Wed, 20 Oct 2004 15:32:58 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF8EB43D1F; Wed, 20 Oct 2004 15:32:57 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (harmony.village.org [10.0.0.6]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id i9KFVrxv030685; Wed, 20 Oct 2004 09:31:53 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 20 Oct 2004 09:32:11 -0600 (MDT) Message-Id: <20041020.093211.78703993.imp@bsdimp.com> To: mitigator@gmail.com From: "M. Warner Losh" In-Reply-To: <6ff30abd04102008163115a32d@mail.gmail.com> References: <41767CF1.2020005@FreeBSD.org> <6ff30abd04102008163115a32d@mail.gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: sobomax@freebsd.org cc: current@freebsd.org cc: arch@freebsd.org Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 15:32:59 -0000 In message: <6ff30abd04102008163115a32d@mail.gmail.com> jamie rishaw at google mail writes: : What are the performance implications of a debug kernel? : : Disk space really shouldnt even be an issue.. if it is, and its down : to the difference of 20 megs, well, duno. 512 meg CF's going for : sub-$50 .. the only reason i could see even a debate would be any : significant performance hits.. So long as it can be turned off, I don't care too much. However, I'm going going to take exception that it isn't a disk space issue or that size doesn't matter. Size does matter. For a 64MB CF this would be a deal killer, and that's the size of the parts we're using now. With our X based systems, these cards are starting to fill up. In addition, we sometimes deploy new kernels to the field and 16MB takes a lot longer to upload than 3MB (think really bad connectivity to many of the remote locations our systems may be deployed in). I also have several machines where / is short on disk space, and I'd turn it off for them. It is simply too much extra to put on there. I could repartition these machines, but that's a huge pita and costs way too much in time and down time to do. The cost here isn't in disk space, but the hundreds or thousands of dollars of labor and/or opportunity costs. Warner From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 15:39:17 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71FB716A4D0 for ; Wed, 20 Oct 2004 15:39:17 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0490843D49 for ; Wed, 20 Oct 2004 15:39:17 +0000 (GMT) (envelope-from mitigator@gmail.com) Received: by mproxy.gmail.com with SMTP id 79so429598rnk for ; Wed, 20 Oct 2004 08:39:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=hdefbE/wb7hOBJFvp/NDPetBCCILq7jjCb5ifFBQcD3dGOJkHHshNyXtCzjA8S130zQ6179DKqe/G5yc7Cjsr5qyrnyVexU5VnG5PYTkZZaPOGRIUm/zxBbntCu/oqKyE5JaPdMlAA/qQ61Z3uagl8Vt4qfHHjQzvThUBcTLbTY Received: by 10.38.65.16 with SMTP id n16mr707430rna; Wed, 20 Oct 2004 08:39:16 -0700 (PDT) Received: by 10.38.163.71 with HTTP; Wed, 20 Oct 2004 08:39:16 -0700 (PDT) Message-ID: <6ff30abd04102008396bb61196@mail.gmail.com> Date: Wed, 20 Oct 2004 10:39:16 -0500 From: jamie rishaw at google mail To: "M. Warner Losh" In-Reply-To: <20041020.093211.78703993.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41767CF1.2020005@FreeBSD.org> <6ff30abd04102008163115a32d@mail.gmail.com> <20041020.093211.78703993.imp@bsdimp.com> cc: sobomax@freebsd.org cc: current@freebsd.org cc: arch@freebsd.org Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jamie rishaw at google mail List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 15:39:17 -0000 > However, I'm going going to take exception that it isn't a disk space > issue or that size doesn't matter. Size does matter. > > For a 64MB CF this would be a deal killer, Not if you can turn it off.. which was said in the OP > and that's the size of the > parts we're using now. With our X based systems, these cards are > starting to fill up. In addition, we sometimes deploy new kernels to > the field and 16MB takes a lot longer to upload than 3MB (think really > bad connectivity to many of the remote locations our systems may be > deployed in). [?relevance?] > I also have several machines where / is short on disk space, and I'd > turn it off for them. It is simply too much extra to put on there. I > could repartition these machines, but that's a huge pita and costs way > too much in time and down time to do. The cost here isn't in disk > space, but the hundreds or thousands of dollars of labor and/or > opportunity costs. Sure. If you dont read /usr/src/UPDATING . In which case, it's your own fault. :-) -- jamie rishaw at google mail aka mitigator /@/ gmail dot you-know-what .. What *wouldnt* Jesus Do? http://WhatWOULDNTJesusDo.com/?u=j2 From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 15:40:35 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9B4216A4CE; Wed, 20 Oct 2004 15:40:35 +0000 (GMT) Received: from smtp-vbr14.xs4all.nl (smtp-vbr14.xs4all.nl [194.109.24.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5274043D31; Wed, 20 Oct 2004 15:40:35 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) i9KFeR2X068604; Wed, 20 Oct 2004 17:40:29 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.1/8.12.9) with ESMTP id i9KFeQE6040589; Wed, 20 Oct 2004 17:40:26 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.1/8.13.1/Submit) id i9KFeQYU040588; Wed, 20 Oct 2004 17:40:26 +0200 (CEST) (envelope-from wb) Date: Wed, 20 Oct 2004 17:40:26 +0200 From: Wilko Bulte To: "M. Warner Losh" Message-ID: <20041020154026.GA40554@freebie.xs4all.nl> References: <41767CF1.2020005@FreeBSD.org> <6ff30abd04102008163115a32d@mail.gmail.com> <20041020.093211.78703993.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041020.093211.78703993.imp@bsdimp.com> User-Agent: Mutt/1.4.1i X-OS: FreeBSD 4.10-STABLE X-PGP: finger wilko@freebsd.org X-Virus-Scanned: by XS4ALL Virus Scanner cc: arch@freebsd.org cc: mitigator@gmail.com cc: current@freebsd.org Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 15:40:36 -0000 On Wed, Oct 20, 2004 at 09:32:11AM -0600, M. Warner Losh wrote.. > In message: <6ff30abd04102008163115a32d@mail.gmail.com> > jamie rishaw at google mail writes: > : What are the performance implications of a debug kernel? > : > : Disk space really shouldnt even be an issue.. if it is, and its down > : to the difference of 20 megs, well, duno. 512 meg CF's going for > : sub-$50 .. the only reason i could see even a debate would be any > : significant performance hits.. > > So long as it can be turned off, I don't care too much. > > However, I'm going going to take exception that it isn't a disk space Sure.. and we have plenty of Viagra spam to prove it ;-) > starting to fill up. In addition, we sometimes deploy new kernels to > the field and 16MB takes a lot longer to upload than 3MB (think really > bad connectivity to many of the remote locations our systems may be > deployed in). But I assume you would run a customised kernel on these machines anyway? -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 15:45:50 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9A0616A4CE; Wed, 20 Oct 2004 15:45:49 +0000 (GMT) Received: from aiolos.otenet.gr (aiolos.otenet.gr [195.170.0.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0884543D1D; Wed, 20 Oct 2004 15:45:49 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from orion.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226])i9KFjkle032689; Wed, 20 Oct 2004 18:45:46 +0300 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) i9KFjj3n046791; Wed, 20 Oct 2004 18:45:45 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost)i9KFjjaa046790; Wed, 20 Oct 2004 18:45:45 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Wed, 20 Oct 2004 18:45:45 +0300 From: Giorgos Keramidas To: Maxim Sobolev Message-ID: <20041020154545.GA15763@orion.daedalusnetworks.priv> References: <41767CF1.2020005@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41767CF1.2020005@FreeBSD.org> cc: freebsd-current@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 15:45:50 -0000 On 2004-10-20 17:57, Maxim Sobolev wrote: > : Subject: What do people think about not installing a stripped /kernel ? > : Date: Mon, 18 Oct 2004 15:12:00 -0700 (PDT) > : From: Matthew Dillon > : Newsgroups: dragonfly.kernel > : > : The only cost is disk space... e.g. 3MB stripped kernel verses 16MB > : debug kernel. But the debug info isn't actually loaded into memory so > : the kernel load time and memory overhead is the same as with the stripped > : version. > : > : The issue is bug reports and kernel core dumps. I can't count the number > : of times I have had to carefully instruct people to retrieve their > : kernel.debug's for bug reporting purposes. And even my own debugging > : would be more convenient if I didn't have to save off a separate copy of > : the debug version of the kernel. > : > : What I'm thinking of doing is having the installkernel target install the > : debug version rather then the stripped version unless told to install > : the stripped version with a new option, e.g. 'options INSTALL_STRIPPED'. > : We would ship full debug GENERIC kernels instead of stripped kernels. > : i.e. we aren't getting rid of the ability to install a stripped kernel, > : we just aren't making it the default any more. > : > : What do people think? > > I think that this is good idea which can be adapted for our 6-CURRENT as > well. Disk space is so damn cheap today.... Putting aside the colorful arguments about the exact name of the knob, I say this is a very good idea. Disk space is indeed cheap these days. For those cases where disk space usage matters a lot, a simple setting in `make.conf' might solve whatever seems a problem. In all the machines that I have installed 6.X the size of the root partition is more than 300 MB these days, which can hold at least 2-3 different kernels. The euros/GB price of disks in Patras, Greece, where I live range from 0.43 to 1.12 euros: DESCRIPTION | SIZE | PRICE | EURO/GB --------------------------------------+------+--------+-------- WESTERN DIGITAL 7200rpm, 8MB buffer | 200 | 85.90 | 0.43 SEAGATE 7200rpm, 8MB buffer | 160 | 80.00 | 0.50 SEAGATE 7200rpm, 8MB buffer | 200 | 99.90 | 0.50 WESTERN DIGITAL 7200rpm, 8MB buffer | 120 | 64.50 | 0.54 EXCELSTORE 7200rpm, 2MB buffer | 80 | 43.90 | 0.55 WESTERN DIGITAL 7200rpm, 8MB buffer | 250 | 140.90 | 0.56 WESTERN DIGITAL 7200rpm, 2MB buffer | 80 | 45.90 | 0.57 MAXTOR 7200rpm, 8MB buffer | 200 | 116.00 | 0.58 SEAGATE 7200rpm, 8MB buffer | 120 | 72.00 | 0.60 MAXTOR 7200rpm, 8MB buffer | 160 | 99.00 | 0.62 SAMSUNG 7200rpm, 2MB buffer | 80 | 50.50 | 0.63 SEAGATE 7200rpm, 2MB buffer | 80 | 50.90 | 0.64 WESTERN DIGITAL 7200rpm, 8MB buffer | 80 | 51.50 | 0.64 MAXTOR 7200rpm, 8MB buffer | 120 | 89.00 | 0.74 MAXTOR 7200rpm, 16MB buffer | 250 | 189.00 | 0.76 MAXTOR 7200rpm, 16MB buffer | 300 | 229.00 | 0.76 EXCELSTORE 7200rpm, 2MB buffer | 40 | 39.90 | 1.00 WESTERN DIGITAL 7200rpm, 2MB buffer | 40 | 40.50 | 1.01 SAMSUNG 7200rpm, 2MB buffer | 40 | 41.90 | 1.05 WESTERN DIGITAL 7200rpm, 8MB buffer | 40 | 43.50 | 1.09 SEAGATE 7200rpm, 2MB buffer | 40 | 44.90 | 1.12 # Data obtained from the online store of http://www.plaisio.gr # a couple of minutes ago. That's not just cheap. It's dirt cheap, if you ask me. Bearing this in mind, saving a little space in /boot/kernel is hardly worth the effort and the trouble one has to go through in order to locate or compile a debugging kernel when a bug creeps up. - Giorgos From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 16:27:29 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EE7D16A4CF; Wed, 20 Oct 2004 16:27:29 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2372343D48; Wed, 20 Oct 2004 16:27:29 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i9KGRrMv050355; Wed, 20 Oct 2004 10:27:54 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <41769194.4060809@freebsd.org> Date: Wed, 20 Oct 2004 10:25:56 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jamie rishaw at google mail References: <41767CF1.2020005@FreeBSD.org> <6ff30abd04102008163115a32d@mail.gmail.com> In-Reply-To: <6ff30abd04102008163115a32d@mail.gmail.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: Maxim Sobolev cc: current@freebsd.org cc: arch@freebsd.org Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 16:27:29 -0000 jamie rishaw at google mail wrote: > What are the performance implications of a debug kernel? > > Disk space really shouldnt even be an issue.. if it is, and its down > to the difference of 20 megs, well, duno. 512 meg CF's going for > sub-$50 .. the only reason i could see even a debate would be any > significant performance hits.. Disk space on the release CD images is at a premium, and putting debug kernels on there generally consumes 10-15MB that could be used by packages. Scott From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 16:40:04 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 638B416A4CE; Wed, 20 Oct 2004 16:40:04 +0000 (GMT) Received: from shrike.submonkey.net (cpc2-cdif3-6-0-cust204.cdif.cable.ntl.com [81.103.67.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id D977743D48; Wed, 20 Oct 2004 16:40:03 +0000 (GMT) (envelope-from setantae@submonkey.net) Received: from setantae by shrike.submonkey.net with local (Exim 4.43 (FreeBSD)) id 1CKJVK-0009cJ-Bm; Wed, 20 Oct 2004 17:40:02 +0100 Date: Wed, 20 Oct 2004 17:40:02 +0100 From: Ceri Davies To: Scott Long Message-ID: <20041020164002.GH57641@submonkey.net> Mail-Followup-To: Ceri Davies , Scott Long , jamie rishaw at google mail , Maxim Sobolev , current@freebsd.org, arch@freebsd.org References: <41767CF1.2020005@FreeBSD.org> <6ff30abd04102008163115a32d@mail.gmail.com> <41769194.4060809@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WVXhfWX7iGQecmy9" Content-Disposition: inline In-Reply-To: <41769194.4060809@freebsd.org> X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.6i Sender: Ceri Davies cc: Maxim Sobolev cc: jamie rishaw at google mail cc: current@freebsd.org cc: arch@freebsd.org Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 16:40:04 -0000 --WVXhfWX7iGQecmy9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 20, 2004 at 10:25:56AM -0600, Scott Long wrote: > jamie rishaw at google mail wrote: > >What are the performance implications of a debug kernel? > > > >Disk space really shouldnt even be an issue.. if it is, and its down > >to the difference of 20 megs, well, duno. 512 meg CF's going for > >sub-$50 .. the only reason i could see even a debate would be any > >significant performance hits.. >=20 > Disk space on the release CD images is at a premium, and putting debug > kernels on there generally consumes 10-15MB that could be used by > packages. Would you consider this something that we could run with in CURRENT/STABLE and just turn off for releases? Ceri --=20 --WVXhfWX7iGQecmy9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBdpThocfcwTS3JF8RAhszAKCt3IIBzvTgubjV2/OTw7WgPd93VwCfRviL BiwsfLEtnrfWjeC03RQRQPs= =BX1P -----END PGP SIGNATURE----- --WVXhfWX7iGQecmy9-- From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 16:46:49 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9563B16A4CE; Wed, 20 Oct 2004 16:46:49 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CB1843D2F; Wed, 20 Oct 2004 16:46:49 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i9KGlD0Q050415; Wed, 20 Oct 2004 10:47:13 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <4176961B.3050209@freebsd.org> Date: Wed, 20 Oct 2004 10:45:15 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ceri Davies References: <41767CF1.2020005@FreeBSD.org> <6ff30abd04102008163115a32d@mail.gmail.com> <41769194.4060809@freebsd.org> <20041020164002.GH57641@submonkey.net> In-Reply-To: <20041020164002.GH57641@submonkey.net> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: Maxim Sobolev cc: jamie rishaw at google mail cc: current@freebsd.org cc: arch@freebsd.org Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 16:46:49 -0000 Ceri Davies wrote: > On Wed, Oct 20, 2004 at 10:25:56AM -0600, Scott Long wrote: > >>jamie rishaw at google mail wrote: >> >>>What are the performance implications of a debug kernel? >>> >>>Disk space really shouldnt even be an issue.. if it is, and its down >>>to the difference of 20 megs, well, duno. 512 meg CF's going for >>>sub-$50 .. the only reason i could see even a debate would be any >>>significant performance hits.. >> >>Disk space on the release CD images is at a premium, and putting debug >>kernels on there generally consumes 10-15MB that could be used by >>packages. > > > Would you consider this something that we could run with in > CURRENT/STABLE and just turn off for releases? > > Ceri > -- That's already the case for HEAD. I have no opinion on 4-STABLE and 5-STABLE. The only problem might be that while disk space is cheap, the root partition is often fairly small and of course fixed in size and un-growable. 256MB might get really tight if you start installing multiple debug kernels. Also, 4.x uses 128MB for root, IIRC, which leaves even less wiggle room. It's fine to mandate that the root partitions shall be bigger in the future to accomodate this, but for those that are doing source upgrades from older systems, they might be in for a shock when 1/3 of their root partition gets consumed by a kernel. Scott From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 16:53:46 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0442F16A4CE; Wed, 20 Oct 2004 16:53:46 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5865243D2F; Wed, 20 Oct 2004 16:53:45 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (harmony.village.org [10.0.0.6]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id i9KGqeCk031836; Wed, 20 Oct 2004 10:52:40 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 20 Oct 2004 10:52:59 -0600 (MDT) Message-Id: <20041020.105259.18149825.imp@bsdimp.com> To: wb@freebie.xs4all.nl From: "M. Warner Losh" In-Reply-To: <20041020154026.GA40554@freebie.xs4all.nl> References: <6ff30abd04102008163115a32d@mail.gmail.com> <20041020.093211.78703993.imp@bsdimp.com> <20041020154026.GA40554@freebie.xs4all.nl> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: mitigator@gmail.com cc: current@freebsd.org Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 16:53:46 -0000 In message: <20041020154026.GA40554@freebie.xs4all.nl> Wilko Bulte writes: : On Wed, Oct 20, 2004 at 09:32:11AM -0600, M. Warner Losh wrote.. : > In message: <6ff30abd04102008163115a32d@mail.gmail.com> : > jamie rishaw at google mail writes: : > : What are the performance implications of a debug kernel? : > : : > : Disk space really shouldnt even be an issue.. if it is, and its down : > : to the difference of 20 megs, well, duno. 512 meg CF's going for : > : sub-$50 .. the only reason i could see even a debate would be any : > : significant performance hits.. : > : > So long as it can be turned off, I don't care too much. : > : > However, I'm going going to take exception that it isn't a disk space : : Sure.. and we have plenty of Viagra spam to prove it ;-) : : > starting to fill up. In addition, we sometimes deploy new kernels to : > the field and 16MB takes a lot longer to upload than 3MB (think really : > bad connectivity to many of the remote locations our systems may be : > deployed in). : : But I assume you would run a customised kernel on these machines anyway? Yes. Please see the first sentence of my reply: : > So long as it can be turned off, I don't care too much. Size does matter, so I have to be able to turn this feature off. Warner From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 16:56:51 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F45516A4CE; Wed, 20 Oct 2004 16:56:51 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2EAF43D3F; Wed, 20 Oct 2004 16:56:50 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (harmony.village.org [10.0.0.6]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id i9KGtP5H031882; Wed, 20 Oct 2004 10:55:25 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 20 Oct 2004 10:55:44 -0600 (MDT) Message-Id: <20041020.105544.00451032.imp@bsdimp.com> To: mitigator@gmail.com From: "M. Warner Losh" In-Reply-To: <6ff30abd04102008396bb61196@mail.gmail.com> References: <6ff30abd04102008163115a32d@mail.gmail.com> <20041020.093211.78703993.imp@bsdimp.com> <6ff30abd04102008396bb61196@mail.gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: sobomax@freebsd.org cc: current@freebsd.org cc: arch@freebsd.org Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 16:56:51 -0000 In message: <6ff30abd04102008396bb61196@mail.gmail.com> jamie rishaw at google mail writes: : > However, I'm going going to take exception that it isn't a disk space : > issue or that size doesn't matter. Size does matter. : > : > For a 64MB CF this would be a deal killer, : : Not if you can turn it off.. which was said in the OP Didn't I say exactly this? Is there some need to repeat what I said in the first line of my reply? : > and that's the size of the : > parts we're using now. With our X based systems, these cards are : > starting to fill up. In addition, we sometimes deploy new kernels to : > the field and 16MB takes a lot longer to upload than 3MB (think really : > bad connectivity to many of the remote locations our systems may be : > deployed in). : : [?relevance?] Concrete example. Not a theoretical one. This is why it matters. People around here tend to not go in for theoretical ones :-) : > I also have several machines where / is short on disk space, and I'd : > turn it off for them. It is simply too much extra to put on there. I : > could repartition these machines, but that's a huge pita and costs way : > too much in time and down time to do. The cost here isn't in disk : > space, but the hundreds or thousands of dollars of labor and/or : > opportunity costs. : : Sure. If you dont read /usr/src/UPDATING . >From UPDATING: This file is maintained and copyrighted by M. Warner Losh . See end of file for further details. :-) Warner Losh From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 16:59:51 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55A5F16A4D0; Wed, 20 Oct 2004 16:59:51 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA72D43D2F; Wed, 20 Oct 2004 16:59:50 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (harmony.village.org [10.0.0.6]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id i9KGwJTm031961; Wed, 20 Oct 2004 10:58:19 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 20 Oct 2004 10:58:39 -0600 (MDT) Message-Id: <20041020.105839.100358845.imp@bsdimp.com> To: keramida@freebsd.org From: "M. Warner Losh" In-Reply-To: <20041020154545.GA15763@orion.daedalusnetworks.priv> References: <41767CF1.2020005@FreeBSD.org> <20041020154545.GA15763@orion.daedalusnetworks.priv> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: sobomax@freebsd.org cc: freebsd-current@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 16:59:51 -0000 In message: <20041020154545.GA15763@orion.daedalusnetworks.priv> Giorgos Keramidas writes: : That's not just cheap. It's dirt cheap, if you ask me. Bearing : this in mind, saving a little space in /boot/kernel is hardly worth : the effort and the trouble one has to go through in order to locate : or compile a debugging kernel when a bug creeps up. But the time it takes me to resize / to accomidate the larger requirements of the kernel will easily swamp the cost of the disk. It usually takes me about 3 hours to do the conversion if all goes well, 10 or more if something bad happens during it. This can easily add up to hundreds or thousands of dollars depending on who has to sit around waiting. But that's why it has to be a knob to turn it off: Sometimes the dirt cheap analysis that you sight is wrong. Warner From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 17:10:01 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C6AEC16A4CE; Wed, 20 Oct 2004 17:10:01 +0000 (GMT) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id D791343D4C; Wed, 20 Oct 2004 17:10:00 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from orion.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226])i9KH9FME002504; Wed, 20 Oct 2004 20:09:33 +0300 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) i9KH97Cb001274; Wed, 20 Oct 2004 20:09:07 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost)i9KH97vX001273; Wed, 20 Oct 2004 20:09:07 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Wed, 20 Oct 2004 20:09:07 +0300 From: Giorgos Keramidas To: "M. Warner Losh" Message-ID: <20041020170907.GA1216@orion.daedalusnetworks.priv> References: <41767CF1.2020005@FreeBSD.org> <20041020154545.GA15763@orion.daedalusnetworks.priv> <20041020.105839.100358845.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041020.105839.100358845.imp@bsdimp.com> cc: sobomax@freebsd.org cc: freebsd-current@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 17:10:01 -0000 On 2004-10-20 10:58, "M. Warner Losh" wrote: > In message: <20041020154545.GA15763@orion.daedalusnetworks.priv> > Giorgos Keramidas writes: > : That's not just cheap. It's dirt cheap, if you ask me. Bearing > : this in mind, saving a little space in /boot/kernel is hardly worth > : the effort and the trouble one has to go through in order to locate > : or compile a debugging kernel when a bug creeps up. > > But the time it takes me to resize / to accomidate the larger > requirements of the kernel will easily swamp the cost of the disk. It > usually takes me about 3 hours to do the conversion if all goes well, > 10 or more if something bad happens during it. This can easily add up > to hundreds or thousands of dollars depending on who has to sit around > waiting. True. This is why making this tunable at installworld time is absolutely necessary. From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 17:14:10 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9C4816A4CE; Wed, 20 Oct 2004 17:14:10 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7773943D4C; Wed, 20 Oct 2004 17:14:10 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.206] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CKK2L-0002mr-00; Wed, 20 Oct 2004 19:14:09 +0200 Received: from [217.227.158.116] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CKK2K-00054p-00; Wed, 20 Oct 2004 19:14:09 +0200 From: Max Laier To: freebsd-arch@freebsd.org Date: Wed, 20 Oct 2004 19:13:35 +0200 User-Agent: KMail/1.7 References: <41767CF1.2020005@FreeBSD.org> <20041020.105839.100358845.imp@bsdimp.com> <20041020170907.GA1216@orion.daedalusnetworks.priv> In-Reply-To: <20041020170907.GA1216@orion.daedalusnetworks.priv> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1937739.bJVac5Oj7T"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200410201913.42879.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: freebsd-current@freebsd.org Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 17:14:11 -0000 --nextPart1937739.bJVac5Oj7T Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Why is this discussion ongoing? The consensus seems pretty clear: "Implemen= t=20 it, but have a make.conf option to turn it off." If there is concern with=20 this make if default to off and have an option to turn it on. I don't see the point in exchanging details on how cheap or expensive disk= =20 space or admin time is these days. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1937739.bJVac5Oj7T Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBdpzGXyyEoT62BG0RAqQBAJ48AwPCURpk44AhqxytnkPIOqwqeQCdG/GV ORRYjguDmE7Oh/Lmdw+5W4M= =Pffp -----END PGP SIGNATURE----- --nextPart1937739.bJVac5Oj7T-- From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 17:17:45 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE53E16A4CE; Wed, 20 Oct 2004 17:17:45 +0000 (GMT) Received: from smtp4.server.rpi.edu (smtp4.server.rpi.edu [128.113.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51FDB43D45; Wed, 20 Oct 2004 17:17:45 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp4.server.rpi.edu (8.13.0/8.13.0) with ESMTP id i9KHHhxQ029126; Wed, 20 Oct 2004 13:17:44 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <41767CF1.2020005@FreeBSD.org> References: <41767CF1.2020005@FreeBSD.org> Date: Wed, 20 Oct 2004 13:17:44 -0400 To: Maxim Sobolev , From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) cc: arch@freebsd.org Subject: Re: [Fwd: What do people think about not installing a stripped /kernel?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 17:17:46 -0000 At 5:57 PM +0300 10/20/04, Maxim Sobolev wrote: >I think that this is good idea which can be adapted for our >6-CURRENT as well. Disk space is so damn cheap today.... I think it makes sense to do this as the default behavior, and then support the stripped-down kernel as the optional behavior. There are always going to be some users who need the smallest kernel possible, but those people are already making a custom kernel so it is fine (IMO) if they also need to customize the kernel to obtain a stripped kernel. But the people who are happily running with a generic kernel will be better off if they have all that debug information readily available if any problem does come up. Right now we always waste one "debug cycle" when someone gets a core dump, only to realize that they can't do anything with it because their kernel has no symbol information. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 17:21:05 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3531116A4CE; Wed, 20 Oct 2004 17:21:05 +0000 (GMT) Received: from web.portaone.com (web.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B65E43D1F; Wed, 20 Oct 2004 17:21:04 +0000 (GMT) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.73] (portacare.portaone.com [195.140.247.242]) (authenticated bits=0) by web.portaone.com (8.12.11/8.12.11) with ESMTP id i9KHKxpc033455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Oct 2004 19:21:01 +0200 (CEST) (envelope-from sobomax@FreeBSD.org) Message-ID: <41769E70.4020808@FreeBSD.org> Date: Wed, 20 Oct 2004 20:20:48 +0300 From: Maxim Sobolev User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex de Kruijff References: <41767CF1.2020005@FreeBSD.org> <20041020165900.GB834@alex.lan> In-Reply-To: <20041020165900.GB834@alex.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: arch@FreeBSD.org cc: "current@freebsd.org" Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 17:21:05 -0000 Let me clarify it down: it is only applies to HEAD, that is, unstable branch, which can be inheretedly buggy. STABLE/RELEASE doesn't really need this feature. This dismisses the following objections: 1. HDD size constrains: nobody really want to run unpatched HEAD on CF or the like, since with HEAD you are expected to re-compile more than often. 2. / partition size: anybody running HEAD is expected to allow this accomodate debugging kernel. 3. Additional slowdown: since it is adds up to 10 seconds (I bet that even less on a modern system) who cares? This is HEAD, so that it is expected to be sub-optimal performance-wise. 4. CD size constrains: again - it's for head. We don't put HEAD on CDs, except snapshots, but they generally go without packages. -Maxim Alex de Kruijff wrote: >>-------- Original Message -------- >>Subject: What do people think about not installing a stripped /kernel ? >>Date: Mon, 18 Oct 2004 15:12:00 -0700 (PDT) >>From: Matthew Dillon >>Newsgroups: dragonfly.kernel >> >>The only cost is disk space... e.g. 3MB stripped kernel verses 16MB >>debug kernel. But the debug info isn't actually loaded into memory so >>the kernel load time and memory overhead is the same as with the stripped >>version. >> >>The issue is bug reports and kernel core dumps. I can't count the number >>of times I have had to carefully instruct people to retrieve their >>kernel.debug's for bug reporting purposes. And even my own debugging >>would be more convenient if I didn't have to save off a separate copy of >>the debug version of the kernel. >> >>What I'm thinking of doing is having the installkernel target install the >>debug version rather then the stripped version unless told to install >>the stripped version with a new option, e.g. 'options INSTALL_STRIPPED'. >>We would ship full debug GENERIC kernels instead of stripped kernels. >>i.e. we aren't getting rid of the ability to install a stripped kernel, >>we just aren't making it the default any more. >> >>What do people think? > > > There are a couple downside. > > 1. Performance issues. (i.e. Longer startup time) > 2. There's more kernel to go in to the memory. > 3. The root partition need to be bigger. > > FreeBSD 5.0 was slow when it came out of the box. So I think its a great idee for the prerelease but bad the releases them selfs. From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 17:21:57 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7565816A4D0; Wed, 20 Oct 2004 17:21:57 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCDE143D1F; Wed, 20 Oct 2004 17:21:56 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i9KIJqMO027740; Wed, 20 Oct 2004 13:19:53 -0500 Date: Wed, 20 Oct 2004 13:19:52 -0500 (EST) From: Sam X-X-Sender: sah@athena To: Max Laier In-Reply-To: <200410201913.42879.max@love2party.net> Message-ID: References: <41767CF1.2020005@FreeBSD.org> <20041020.105839.100358845.imp@bsdimp.com> <200410201913.42879.max@love2party.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-current@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 17:21:57 -0000 > I don't see the point in exchanging details on how cheap or expensive disk > space or admin time is these days. I was kind of hoping we could come to an agreement on how many bytes equals one hour of admin time so our shirts can figure out how many bytehours we'll need for FY05. I guess I'll just tell them to round up. Sam From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 17:29:02 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 094D416A4CE; Wed, 20 Oct 2004 17:29:02 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id B603843D31; Wed, 20 Oct 2004 17:29:01 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i9KHTt9Y031721; Wed, 20 Oct 2004 10:29:55 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i9KHTtRm031720; Wed, 20 Oct 2004 10:29:55 -0700 Date: Wed, 20 Oct 2004 10:29:55 -0700 From: Brooks Davis To: Maxim Sobolev Message-ID: <20041020172955.GG11477@odin.ac.hmc.edu> References: <41767CF1.2020005@FreeBSD.org> <20041020165900.GB834@alex.lan> <41769E70.4020808@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41769E70.4020808@FreeBSD.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: arch@freebsd.org cc: "current@freebsd.org" cc: Alex de Kruijff Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 17:29:02 -0000 On Wed, Oct 20, 2004 at 08:20:48PM +0300, Maxim Sobolev wrote: > Let me clarify it down: it is only applies to HEAD, that is, unstable > branch, which can be inheretedly buggy. STABLE/RELEASE doesn't really > need this feature. This dismisses the following objections: I think it's more important in HEAD, but personally I would like to ship this way. It has the potential to vastly improve the quality of bug reports. That's not my call though. > 1. HDD size constrains: nobody really want to run unpatched HEAD on CF > or the like, since with HEAD you are expected to re-compile more than often. > > 2. / partition size: anybody running HEAD is expected to allow this > accomodate debugging kernel. > > 3. Additional slowdown: since it is adds up to 10 seconds (I bet that > even less on a modern system) who cares? This is HEAD, so that it is > expected to be sub-optimal performance-wise. I seriously doubt it's measurable. If it is, the loader is broken. :-) We're talking about reading a section header and doing a seek for each ELF section we don't care about (all the ones that bloat the file relative to the stripped version.) -- Brooks From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 17:41:30 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D53A16A4CE; Wed, 20 Oct 2004 17:41:30 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA37543D2D; Wed, 20 Oct 2004 17:41:29 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i9KHfpCY050705; Wed, 20 Oct 2004 11:41:52 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <4176A2E9.2010801@freebsd.org> Date: Wed, 20 Oct 2004 11:39:53 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brooks Davis References: <41767CF1.2020005@FreeBSD.org> <20041020165900.GB834@alex.lan> <41769E70.4020808@FreeBSD.org> <20041020172955.GG11477@odin.ac.hmc.edu> In-Reply-To: <20041020172955.GG11477@odin.ac.hmc.edu> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: Maxim Sobolev cc: Alex de Kruijff cc: "current@freebsd.org" cc: arch@freebsd.org Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 17:41:30 -0000 Brooks Davis wrote: > On Wed, Oct 20, 2004 at 08:20:48PM +0300, Maxim Sobolev wrote: > >>Let me clarify it down: it is only applies to HEAD, that is, unstable >>branch, which can be inheretedly buggy. STABLE/RELEASE doesn't really >>need this feature. This dismisses the following objections: > > > I think it's more important in HEAD, but personally I would like to ship > this way. It has the potential to vastly improve the quality of bug > reports. That's not my call though. > > >>1. HDD size constrains: nobody really want to run unpatched HEAD on CF >>or the like, since with HEAD you are expected to re-compile more than often. >> >>2. / partition size: anybody running HEAD is expected to allow this >>accomodate debugging kernel. >> >>3. Additional slowdown: since it is adds up to 10 seconds (I bet that >>even less on a modern system) who cares? This is HEAD, so that it is >>expected to be sub-optimal performance-wise. > > > I seriously doubt it's measurable. If it is, the loader is broken. :-) > We're talking about reading a section header and doing a seek for each > ELF section we don't care about (all the ones that bloat the file > relative to the stripped version.) > > -- Brooks Actually, another possbility would be to have the kernel install target install the stripped kernel into /boot/kernel/kernel and the debug kernel into /var/kernel/kernel.debug or some similar location. Scott From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 19:46:19 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11E0616A4CF; Wed, 20 Oct 2004 19:46:19 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5356D43D46; Wed, 20 Oct 2004 19:46:18 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i9KJkHVA035066; Wed, 20 Oct 2004 22:46:17 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 78319-14; Wed, 20 Oct 2004 22:46:16 +0300 (EEST) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i9KJkAMU035057; Wed, 20 Oct 2004 22:46:13 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i9KJjlt8057155; Wed, 20 Oct 2004 22:45:47 +0300 (EEST) (envelope-from ru) Date: Wed, 20 Oct 2004 22:45:47 +0300 From: Ruslan Ermilov To: Max Laier Message-ID: <20041020194547.GD2195@ip.net.ua> References: <41767CF1.2020005@FreeBSD.org> <20041020.105839.100358845.imp@bsdimp.com> <20041020170907.GA1216@orion.daedalusnetworks.priv> <200410201913.42879.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DrWhICOqskFTAXiy" Content-Disposition: inline In-Reply-To: <200410201913.42879.max@love2party.net> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: freebsd-current@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 19:46:19 -0000 --DrWhICOqskFTAXiy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 20, 2004 at 07:13:35PM +0200, Max Laier wrote: > Why is this discussion ongoing? The consensus seems pretty clear: "Implem= ent=20 > it, but have a make.conf option to turn it off." If there is concern with= =20 > this make if default to off and have an option to turn it on. >=20 Implementing this is very easy, since it's already implemented, just not by default. What everyone seem to have forgotten is that we also have modules, and in the "config -g" case, we also build debug versions of the modules. And if we're also going to install modules with debug symbols, I think this puts the requirement for the root file system way beyond the rational limits. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --DrWhICOqskFTAXiy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBdsBrqRfpzJluFF4RAsQXAJ4vqENfrkv3w/U5Q/9yXpFqD1JOYwCbByWV t183DjnuzwJwVO8XuyOhCSM= =ycNH -----END PGP SIGNATURE----- --DrWhICOqskFTAXiy-- From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 19:48:53 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA78F16A4CF; Wed, 20 Oct 2004 19:48:53 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5416143D41; Wed, 20 Oct 2004 19:48:53 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i9KJnI7V051194; Wed, 20 Oct 2004 13:49:19 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <4176C0C8.4060408@freebsd.org> Date: Wed, 20 Oct 2004 13:47:20 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ruslan Ermilov References: <41767CF1.2020005@FreeBSD.org> <20041020.105839.100358845.imp@bsdimp.com> <20041020170907.GA1216@orion.daedalusnetworks.priv> <200410201913.42879.max@love2party.net> <20041020194547.GD2195@ip.net.ua> In-Reply-To: <20041020194547.GD2195@ip.net.ua> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: Max Laier cc: freebsd-current@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 19:48:53 -0000 Ruslan Ermilov wrote: > On Wed, Oct 20, 2004 at 07:13:35PM +0200, Max Laier wrote: > >>Why is this discussion ongoing? The consensus seems pretty clear: "Implement >>it, but have a make.conf option to turn it off." If there is concern with >>this make if default to off and have an option to turn it on. >> > > Implementing this is very easy, since it's already implemented, > just not by default. > > What everyone seem to have forgotten is that we also have modules, > and in the "config -g" case, we also build debug versions of the > modules. And if we're also going to install modules with debug > symbols, I think this puts the requirement for the root file > system way beyond the rational limits. > > > Cheers, I tend to agree. What do you think of my proposal to have installkernel (optionally or whatever) put unstriped binaries somewhere outside of the root partition? Scott From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 20:01:17 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8A1616A4CF for ; Wed, 20 Oct 2004 20:01:17 +0000 (GMT) Received: from mailserv1.neuroflux.com (mailserv1.neuroflux.com [204.228.228.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C3C043D45 for ; Wed, 20 Oct 2004 20:01:17 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 49559 invoked by uid 89); 20 Oct 2004 20:09:05 -0000 Received: from unknown (HELO www2.neuroflux.com) (127.0.0.1) by localhost with SMTP; 20 Oct 2004 20:09:05 -0000 Received: from 208.4.77.15 (SquirrelMail authenticated user ryans@gamersimpact.com); by www2.neuroflux.com with HTTP; Wed, 20 Oct 2004 14:09:05 -0600 (MDT) Message-ID: <58341.208.4.77.15.1098302945.squirrel@208.4.77.15> In-Reply-To: <4176C0C8.4060408@freebsd.org> References: <41767CF1.2020005@FreeBSD.org> <20041020.105839.100358845.imp@bsdimp.com> <20041020170907.GA1216@orion.daedalusnetworks.priv> <200410201913.42879.max@love2party.net> <20041020194547.GD2195@ip.net.ua> <4176C0C8.4060408@freebsd.org> Date: Wed, 20 Oct 2004 14:09:05 -0600 (MDT) From: "Ryan Sommers" To: "Scott Long" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal cc: freebsd-arch@freebsd.org Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 20:01:18 -0000 Scott Long said: > I tend to agree. What do you think of my proposal to have installkernel > (optionally or whatever) put unstriped binaries somewhere outside of the > root partition? I'm not too sure how much I like using /var for large things like this either. Certain programs like mysql and mailers tend to use /var by default and by default we have tiny /var partitions if you're trying to store mail or databases. Adding lots of debugging binaries to /var will severely limit that. I think our default for /var is the same as / infact, not certain on this though. Only place I can think outside of root that is sufficeintly large would be /usr. /usr/local/kernel.debug? -- Ryan Sommers ryans@gamersimpact.com From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 20:55:57 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F30D116A4CE; Wed, 20 Oct 2004 20:55:56 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E56E243D3F; Wed, 20 Oct 2004 20:55:55 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i9KKtspP038180; Wed, 20 Oct 2004 23:55:54 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 84156-19; Wed, 20 Oct 2004 23:55:53 +0300 (EEST) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i9KKtkor038176; Wed, 20 Oct 2004 23:55:49 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i9KKtNpj069614; Wed, 20 Oct 2004 23:55:23 +0300 (EEST) (envelope-from ru) Date: Wed, 20 Oct 2004 23:55:23 +0300 From: Ruslan Ermilov To: Scott Long Message-ID: <20041020205523.GA54060@ip.net.ua> References: <41767CF1.2020005@FreeBSD.org> <20041020.105839.100358845.imp@bsdimp.com> <20041020170907.GA1216@orion.daedalusnetworks.priv> <200410201913.42879.max@love2party.net> <20041020194547.GD2195@ip.net.ua> <4176C0C8.4060408@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline In-Reply-To: <4176C0C8.4060408@freebsd.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: Max Laier cc: freebsd-current@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 20:55:57 -0000 --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 20, 2004 at 01:47:20PM -0600, Scott Long wrote: > Ruslan Ermilov wrote: > >On Wed, Oct 20, 2004 at 07:13:35PM +0200, Max Laier wrote: > > > >>Why is this discussion ongoing? The consensus seems pretty clear:=20 > >>"Implement it, but have a make.conf option to turn it off." If there is= =20 > >>concern with this make if default to off and have an option to turn it = on. > >> > > > >Implementing this is very easy, since it's already implemented, > >just not by default. > > > >What everyone seem to have forgotten is that we also have modules, > >and in the "config -g" case, we also build debug versions of the > >modules. And if we're also going to install modules with debug > >symbols, I think this puts the requirement for the root file > >system way beyond the rational limits. > > > > > >Cheers, >=20 > I tend to agree. What do you think of my proposal to have installkernel > (optionally or whatever) put unstriped binaries somewhere outside of the > root partition? >=20 Do you mean installing what we already have as a result of building a debug kernel? In that case, this is already easily done by: make buildkernel CONFIGARGS=3D-g make installkernel mkdir -p /usr/somewhere make installkernel.debug KODIR=3D/usr/somewhere As a result of running this, I have: ru# ls -1 /usr/somewhere/ |grep '\.ko\.debug' |wc -l 386 ru# ls -1 /usr/somewhere/ | grep -v '\.ko\.debug'=20 kernel.debug linker.hints Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --6TrnltStXW4iwmi0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBdtC7qRfpzJluFF4RAv1UAJ0QEC+kvbkoU6QPvccOHhum+H7CbACfVFOg KjDoZ/pZb7XT9TNj4VaUfOU= =jN9N -----END PGP SIGNATURE----- --6TrnltStXW4iwmi0-- From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 21:01:19 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D6F1F16A4CE; Wed, 20 Oct 2004 21:01:19 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF41843D1D; Wed, 20 Oct 2004 21:01:19 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 9751A7A439; Wed, 20 Oct 2004 14:01:19 -0700 (PDT) Message-ID: <4176D21F.3060108@elischer.org> Date: Wed, 20 Oct 2004 14:01:19 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Wilko Bulte References: <41767CF1.2020005@FreeBSD.org> <6ff30abd04102008163115a32d@mail.gmail.com> <20041020.093211.78703993.imp@bsdimp.com> <20041020154026.GA40554@freebie.xs4all.nl> In-Reply-To: <20041020154026.GA40554@freebie.xs4all.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: mitigator@gmail.com cc: current@freebsd.org Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 21:01:20 -0000 Wilko Bulte wrote: >On Wed, Oct 20, 2004 at 09:32:11AM -0600, M. Warner Losh wrote.. > > >>In message: <6ff30abd04102008163115a32d@mail.gmail.com> >> jamie rishaw at google mail writes: >>: What are the performance implications of a debug kernel? >>: >>: Disk space really shouldnt even be an issue.. if it is, and its down >>: to the difference of 20 megs, well, duno. 512 meg CF's going for >>: sub-$50 .. the only reason i could see even a debate would be any >>: significant performance hits.. >> >>So long as it can be turned off, I don't care too much. >> >>However, I'm going going to take exception that it isn't a disk space >> >> > >Sure.. and we have plenty of Viagra spam to prove it ;-) > > > >>starting to fill up. In addition, we sometimes deploy new kernels to >>the field and 16MB takes a lot longer to upload than 3MB (think really >>bad connectivity to many of the remote locations our systems may be >>deployed in). >> >> > >But I assume you would run a customised kernel on these machines anyway? > couldn't the instalation procedures install as stripped one if there wasn't room in /? it might save someone's hide.. > > > From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 21:11:26 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2B5C16A4CE; Wed, 20 Oct 2004 21:11:26 +0000 (GMT) Received: from tensor.xs4all.nl (tensor.xs4all.nl [194.109.160.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3711843D3F; Wed, 20 Oct 2004 21:11:26 +0000 (GMT) (envelope-from dimitry@andric.com) Received: from kilgore.dim (kilgore.dim [192.168.0.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.xs4all.nl (Postfix) with ESMTP id 458B122851; Wed, 20 Oct 2004 23:11:24 +0200 (CEST) Date: Wed, 20 Oct 2004 23:11:04 +0200 From: Dimitry Andric X-Mailer: The Bat! (v3.0.2.1) Professional X-Priority: 3 (Normal) Message-ID: <843590857.20041020231104@andric.com> To: Scott Long In-Reply-To: <4176C0C8.4060408@freebsd.org> References: <41767CF1.2020005@FreeBSD.org> <20041020.105839.100358845.imp@bsdimp.com> <20041020170907.GA1216@orion.daedalusnetworks.priv> <200410201913.42879.max@love2party.net> <20041020194547.GD2195@ip.net.ua> <4176C0C8.4060408@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="----------208F5A2E30BEE7" cc: Max Laier cc: freebsd-current@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 21:11:26 -0000 ------------208F5A2E30BEE7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On 2004-10-20 at 21:47:20 Scott Long wrote: > I tend to agree. What do you think of my proposal to have installkernel > (optionally or whatever) put unstriped binaries somewhere outside of the > root partition? Yes, that is a very nice solution, although you also might say that having "two versions" of the same kernel file could be confusing (and/or wasteful). Also, please note that you might want debug versions of all kernel modules in the same place, since those can cause crashes too, alas. May I suggest /var/crash as a possible location? :) Since you'll be looking in there anyway if you need to debug a crash dump. (On the other hand, I've been installing debug kernels for the past year or so, always using make installkernel.debug, and then renaming all /boot/kernel/*.debug files to their basenames, but this is rather cumbersome. However, you always have all debugging info in one place.) ------------208F5A2E30BEE7 Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: GnuPG v1.2.5 (MingW32) iD8DBQFBdtRosF6jCi4glqMRAn+8AJ9GyND7F1v+lzBbMn8SnvJlWufvzQCfQf1T oKUoMTJ9ENMq040l4PpJt8E= =3n+d -----END PGP MESSAGE----- ------------208F5A2E30BEE7-- From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 21:29:52 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E78B616A4CE; Wed, 20 Oct 2004 21:29:52 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CEDC43D46; Wed, 20 Oct 2004 21:29:52 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i9KLTmvA045311; Wed, 20 Oct 2004 14:29:48 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i9KLTmTK045310; Wed, 20 Oct 2004 14:29:48 -0700 (PDT) (envelope-from dillon) Date: Wed, 20 Oct 2004 14:29:48 -0700 (PDT) From: Matthew Dillon Message-Id: <200410202129.i9KLTmTK045310@apollo.backplane.com> To: Julian Elischer References: <41767CF1.2020005@FreeBSD.org> <6ff30abd04102008163115a32d@mail.gmail.com> <20041020.093211.78703993.imp@bsdimp.com> <4176D21F.3060108@elischer.org> cc: Wilko Bulte cc: mitigator@gmail.com cc: current@freebsd.org cc: arch@freebsd.org Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 21:29:53 -0000 The key point here, folks, is the KISS principle. The idea is to make life easier for (1) inexperienced BSD users especially those who are doing new installs from scratch and (2) the developers that have to field bug reports from the former, and (3) To do it without adding more confusion or complication to the installation operation or the recovery/savecore operation or the directory layout. God knows you have enough of that already. savecore already copies /kernel to /var/crash, I'm just making it copy a kernel with debug symbols for convenience. People already gdb running kernels, I'm just making it easier to do so without having to save a separate copy of the kernel.debug somewhere else where it winds up getting out of sync with what is actually running. We already have to field lots of bug reports from users who know enough to get a core, but don't have a useful kernel to debug the core with. This saves a step. In fact, we enable core dumps in our installs now and once we fix up /var/crash's size (for new installs), even total newbies will be able to provide useful cores to us. That is what is being addressed here. The idea is decidedly NOT to hack things to pieces with alternative debug files that will confuse more people then it helps, even if you do make 'savecore' do the right thing. And the idea is most decidedly NOT to make things easier for the *experienced* developers who cannot otherwise be bothered to add a simple option to their kernel config to revert to a stripped install if space is an issue, or add a single strip command to their full custom flash card installer, or things of that ilk. Those are really silly arguments IMHO. In anycase, the only real issue vis-a-vie FreeBSD is the space consideration on your CDs, and that only effects the decision whether to include a debug kernel on the CD or a stripped kernel on the CD and doesn't really prevent implementation of the idea generally. As Julian said (and I brought this up on our lists too), it's easy enough for the installer to strip the kernel it installs. I would strongly recommend making the room, because a release CD hits the target audience for this square on the peg. We've been going with packageless and sourceless release CDs and only one or two people grumbled about having to download things over a modem, and even those had downloaded the ISO over their modem so it wouldn't even have helped to include them on the CD. pkg_add -r is your friend, and the internet is now far more wide-spread then it was a decade ago. Maybe the time is ripe for the change in your HEAD. -Matt From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 21:30:39 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 856D116A4EB; Wed, 20 Oct 2004 21:30:39 +0000 (GMT) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0641F43D55; Wed, 20 Oct 2004 21:30:28 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.13.0/8.13.0) with ESMTP id i9KLUPUa032487; Wed, 20 Oct 2004 17:30:26 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <4176C0C8.4060408@freebsd.org> References: <41767CF1.2020005@FreeBSD.org> <20041020.105839.100358845.imp@bsdimp.com> <20041020170907.GA1216@orion.daedalusnetworks.priv> <200410201913.42879.max@love2party.net> <20041020194547.GD2195@ip.net.ua> <4176C0C8.4060408@freebsd.org> Date: Wed, 20 Oct 2004 17:30:25 -0400 To: Scott Long , Ruslan Ermilov From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) cc: freebsd-current@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 21:30:39 -0000 At 1:47 PM -0600 10/20/04, Scott Long wrote: >Ruslan Ermilov wrote: >>On Wed, Oct 20, 2004 at 07:13:35PM +0200, Max Laier wrote: >> >>>Why is this discussion ongoing? The consensus seems pretty >>>clear: "Implement it, but have a make.conf option to turn >>>it off." If there is concern with this, make it default to >>>off and have an option to turn it on. >> >>Implementing this is very easy, since it's already implemented, >>just not by default. >> >>What everyone seem to have forgotten is that we also have modules, >>and in the "config -g" case, we also build debug versions of the >>modules. And if we're also going to install modules with debug >>symbols, I think this puts the requirement for the root file >>system way beyond the rational limits. > >I tend to agree. What do you think of my proposal to have >installkernel (optionally or whatever) put unstriped binaries >somewhere outside of the root partition? A long time ago I had an update which allowed the person to set where the debug version of kernels and modules would go, based on some environment variable in make.conf. I am pretty sure I even posted it. But it was for 4-STABLE, and the feedback was that it should first go into 5-current. This made a lot of sense, of course, but *I* only needed it on my 4.x-stable system... There were also major changes in the build process between 4-stable and 5-current, so I never reworked that change. It was much easier to just create a larger root partition on my 5.x test system... Hmm. I might even have that disk still spinning around somewhere. Yes, I seem to have it. Frightening! What I seem to have is a patch to 4.x (as of Nov 20 2001), which adds support for a KERNSAVDBGDIR= environment variable. It modifies sys/conf/kmod.mk and sys/conf/Makefile.i386 . I am not sure how useful it would be, seeing that it's for the wrong branch and it is from so long ago. But if people are interested, I could look into that. In any case, we could also change this so that the kernel is not stripped by default, but still leave modules stripped by default. What I think is important is that the default, generic install will set up users with a kernel that has SOME symbols in it. As I say, right now we're in the situation where we install one thing (stripped kernel & modules), but as soon as anyone reports a problem we tell them to build a non-stripped kernel or we can not help them. If the "rational" root partition is too small for a non-stripped kernel, then users are screwed when we given them that advice. So we need to change our definition of a rational root partition, or we simply admit that we (as developers) are not rational. Changing the *default* kernel that we install does not effect the actual size of a kernel which is USEFUL for debugging. The only thing we are changing is whether users START OUT with a useful debugging kernel. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 21:31:46 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D21716A4CE; Wed, 20 Oct 2004 21:31:46 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1887843D1D; Wed, 20 Oct 2004 21:31:46 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 01F8E7A427; Wed, 20 Oct 2004 14:31:46 -0700 (PDT) Message-ID: <4176D941.4070601@elischer.org> Date: Wed, 20 Oct 2004 14:31:45 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Scott Long References: <41767CF1.2020005@FreeBSD.org> <20041020165900.GB834@alex.lan> <41769E70.4020808@FreeBSD.org> <20041020172955.GG11477@odin.ac.hmc.edu> <4176A2E9.2010801@freebsd.org> In-Reply-To: <4176A2E9.2010801@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: "current@freebsd.org" Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 21:31:46 -0000 Scott Long wrote: > > Actually, another possbility would be to have the kernel install target > install the stripped kernel into /boot/kernel/kernel and the debug > kernel into /var/kernel/kernel.debug or some similar location. in production sites here My installation scripts put kernel.debug in /var/crash, which is nearly always linked to /usr/crash. From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 21:37:21 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC19316A4CE; Wed, 20 Oct 2004 21:37:21 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 619AC43D53; Wed, 20 Oct 2004 21:37:21 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i9KLbKg9007501; Wed, 20 Oct 2004 14:37:20 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i9KLbK41007500; Wed, 20 Oct 2004 14:37:20 -0700 Date: Wed, 20 Oct 2004 14:37:20 -0700 From: Brooks Davis To: Scott Long Message-ID: <20041020213720.GB6762@odin.ac.hmc.edu> References: <41767CF1.2020005@FreeBSD.org> <20041020165900.GB834@alex.lan> <41769E70.4020808@FreeBSD.org> <20041020172955.GG11477@odin.ac.hmc.edu> <4176A2E9.2010801@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pvezYHf7grwyp3Bc" Content-Disposition: inline In-Reply-To: <4176A2E9.2010801@freebsd.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: Maxim Sobolev cc: Alex de Kruijff cc: "current@freebsd.org" cc: arch@freebsd.org Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 21:37:21 -0000 --pvezYHf7grwyp3Bc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 20, 2004 at 11:39:53AM -0600, Scott Long wrote: > Brooks Davis wrote: > >On Wed, Oct 20, 2004 at 08:20:48PM +0300, Maxim Sobolev wrote: > > > >>Let me clarify it down: it is only applies to HEAD, that is, unstable= =20 > >>branch, which can be inheretedly buggy. STABLE/RELEASE doesn't really= =20 > >>need this feature. This dismisses the following objections: > > > > > >I think it's more important in HEAD, but personally I would like to ship > >this way. It has the potential to vastly improve the quality of bug > >reports. That's not my call though. > > > > > >>1. HDD size constrains: nobody really want to run unpatched HEAD on CF= =20 > >>or the like, since with HEAD you are expected to re-compile more than= =20 > >>often. > >> > >>2. / partition size: anybody running HEAD is expected to allow this=20 > >>accomodate debugging kernel. > >> > >>3. Additional slowdown: since it is adds up to 10 seconds (I bet that= =20 > >>even less on a modern system) who cares? This is HEAD, so that it is=20 > >>expected to be sub-optimal performance-wise. > > > > > >I seriously doubt it's measurable. If it is, the loader is broken. :-) > >We're talking about reading a section header and doing a seek for each > >ELF section we don't care about (all the ones that bloat the file > >relative to the stripped version.) >=20 > Actually, another possbility would be to have the kernel install target > install the stripped kernel into /boot/kernel/kernel and the debug > kernel into /var/kernel/kernel.debug or some similar location. Some place in var seems like a good place to me. We may want to bump our default /var size a bit based on this but that's a minor detail. The nice thing about /var/crash would be that everything you need to debug a crash dump would be under a single hierarchy. -- 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 --pvezYHf7grwyp3Bc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBdtqPXY6L6fI4GtQRAtbbAKCIf9yn8tXrqDQujLm8WzHQY8mcoACdG7JE m86QUpxv4YqHEYWOC3s3uBc= =bJib -----END PGP SIGNATURE----- --pvezYHf7grwyp3Bc-- From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 22:14:33 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51E6916A4CE; Wed, 20 Oct 2004 22:14:33 +0000 (GMT) Received: from web.portaone.com (support.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id C869543D2F; Wed, 20 Oct 2004 22:14:31 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.1.100] (xDSL-2-2.united.net.ua [193.111.9.226]) (authenticated bits=0) by web.portaone.com (8.12.11/8.12.11) with ESMTP id i9KMELgW007000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Oct 2004 00:14:24 +0200 (CEST) (envelope-from sobomax@portaone.com) Message-ID: <4176E329.9090500@portaone.com> Date: Thu, 21 Oct 2004 01:14:01 +0300 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <41767CF1.2020005@FreeBSD.org> <20041020.105839.100358845.imp@bsdimp.com> <20041020170907.GA1216@orion.daedalusnetworks.priv> <200410201913.42879.max@love2party.net> <20041020194547.GD2195@ip.net.ua> <4176C0C8.4060408@freebsd.org> In-Reply-To: <4176C0C8.4060408@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Max Laier cc: freebsd-current@FreeBSD.ORG cc: Ruslan Ermilov cc: freebsd-arch@FreeBSD.ORG Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 22:14:33 -0000 Scott Long wrote: > Ruslan Ermilov wrote: > >> On Wed, Oct 20, 2004 at 07:13:35PM +0200, Max Laier wrote: >> >>> Why is this discussion ongoing? The consensus seems pretty clear: >>> "Implement it, but have a make.conf option to turn it off." If there >>> is concern with this make if default to off and have an option to >>> turn it on. >>> >> >> Implementing this is very easy, since it's already implemented, >> just not by default. >> >> What everyone seem to have forgotten is that we also have modules, >> and in the "config -g" case, we also build debug versions of the >> modules. And if we're also going to install modules with debug >> symbols, I think this puts the requirement for the root file >> system way beyond the rational limits. >> >> >> Cheers, > > > I tend to agree. What do you think of my proposal to have installkernel > (optionally or whatever) put unstriped binaries somewhere outside of the > root partition? OK, I've just checked objcopy manpage and found that there is actually a better way which combines best properties of both approach. In modern GNU toolchain it is possible to split executable and debugging info into two separate files, but put a reference into executable, so that you don't have to worry about how to load debugging symbols: --only-keep-debug Strip a file, removing any sections that would be stripped by --strip-debug and leaving the debugging sections. The intention is that this option will be used in conjunction with --add-gnu-debuglink to create a two part executable. One a stripped binary which will occupy less space in RAM and in a dis- tribution and the second a debugging information file which is only needed if debugging abilities are required. The suggested proce- dure to create these files is as follows: 1. "foo" then... 1. create a file containing the debugging info. 1. stripped executable. 1. to add a link to the debugging info into the stripped exe- cutable. I checked, this works like a charm with our current toolchain/gdb. This allows us to do the following clever trick WRT kernel debug: 1. Compile kernel/modules with debugging symbols; 2. Split out executable and debugging pieces for each module; 3. Associate each executable file with appropriate debug file; 4. Install executable into /boot/kernel as usually; 5. Install real debugging into /var/something, put symlink to it into /boot/kernel. By the way, this approach can be extended to be an option of buildworld as well! It can be good way to trade developers' time for some hdd space, since with this option "on" you will always be able to debug misbehaving application/library without the need to recompile/reinstall everything! Opinions? -Maxim From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 22:31:14 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5FBC16A4CE; Wed, 20 Oct 2004 22:31:14 +0000 (GMT) Received: from web.portaone.com (mail.russia.cz [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E22E43D46; Wed, 20 Oct 2004 22:31:14 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.1.100] (xDSL-2-2.united.net.ua [193.111.9.226]) (authenticated bits=0) by web.portaone.com (8.12.11/8.12.11) with ESMTP id i9KMV376008044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Oct 2004 00:31:06 +0200 (CEST) (envelope-from sobomax@portaone.com) Message-ID: <4176E71D.9090500@portaone.com> Date: Thu, 21 Oct 2004 01:30:53 +0300 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <41767CF1.2020005@FreeBSD.org> <20041020.105839.100358845.imp@bsdimp.com> <20041020170907.GA1216@orion.daedalusnetworks.priv> <200410201913.42879.max@love2party.net> <20041020194547.GD2195@ip.net.ua> <4176C0C8.4060408@freebsd.org> <4176E329.9090500@portaone.com> In-Reply-To: <4176E329.9090500@portaone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Max Laier cc: freebsd-current@FreeBSD.ORG cc: Ruslan Ermilov cc: freebsd-arch@FreeBSD.ORG Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 22:31:15 -0000 Maxim Sobolev wrote: > OK, I've just checked objcopy manpage and found that there is actually a > better way which combines best properties of both approach. In modern > GNU toolchain it is possible to split executable and debugging info into > two separate files, but put a reference into executable, so that you > don't have to worry about how to load debugging symbols: > > --only-keep-debug > Strip a file, removing any sections that would be stripped by > --strip-debug and leaving the debugging sections. > > The intention is that this option will be used in conjunction with > --add-gnu-debuglink to create a two part executable. One a > stripped binary which will occupy less space in RAM and in a dis- > tribution and the second a debugging information file which is only > needed if debugging abilities are required. The suggested proce- > dure to create these files is as follows: > > 1. > "foo" then... > > 1. > create a file containing the debugging info. > > 1. > stripped executable. > > 1. > to add a link to the debugging info into the stripped exe- > cutable. > > I checked, this works like a charm with our current toolchain/gdb. This > allows us to do the following clever trick WRT kernel debug: > > 1. Compile kernel/modules with debugging symbols; > 2. Split out executable and debugging pieces for each module; > 3. Associate each executable file with appropriate debug file; > 4. Install executable into /boot/kernel as usually; > 5. Install real debugging into /var/something, put symlink to it into > /boot/kernel. > > By the way, this approach can be extended to be an option of buildworld > as well! It can be good way to trade developers' time for some hdd > space, since with this option "on" you will always be able to debug > misbehaving application/library without the need to recompile/reinstall > everything! BTW, it also allows us to do create separate "debug" distribution for release CDs. So that one can do binary install and then add debugging symbols if necessary. -Maxim From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 22:36:16 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CEE5716A4D1; Wed, 20 Oct 2004 22:36:16 +0000 (GMT) Received: from smtp4.server.rpi.edu (smtp4.server.rpi.edu [128.113.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E53E43D49; Wed, 20 Oct 2004 22:36:16 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp4.server.rpi.edu (8.13.0/8.13.0) with ESMTP id i9KMaEXq028849; Wed, 20 Oct 2004 18:36:15 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <4176E329.9090500@portaone.com> References: <41767CF1.2020005@FreeBSD.org> <20041020.105839.100358845.imp@bsdimp.com> <20041020170907.GA1216@orion.daedalusnetworks.priv> <200410201913.42879.max@love2party.net> <20041020194547.GD2195@ip.net.ua> <4176C0C8.4060408@freebsd.org> <4176E329.9090500@portaone.com> Date: Wed, 20 Oct 2004 18:36:13 -0400 To: Maxim Sobolev , Scott Long From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) cc: freebsd-current@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 22:36:17 -0000 At 1:14 AM +0300 10/21/04, Maxim Sobolev wrote: > >OK, I've just checked objcopy manpage and found that there is >actually a better way which combines best properties of both >approach. In modern GNU toolchain it is possible to split >executable and debugging info into two separate files, but put >a reference into executable, so that you don't have to worry >about how to load debugging symbols: This sounds like a very attractive possibility. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 22:41:06 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CF1D16A4CE; Wed, 20 Oct 2004 22:41:06 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B912943D53; Wed, 20 Oct 2004 22:41:05 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i9KMf45G042336; Thu, 21 Oct 2004 01:41:04 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 90087-15; Thu, 21 Oct 2004 01:41:03 +0300 (EEST) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i9KMetDF042326; Thu, 21 Oct 2004 01:40:58 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i9KMeXnH027198; Thu, 21 Oct 2004 01:40:33 +0300 (EEST) (envelope-from ru) Date: Thu, 21 Oct 2004 01:40:33 +0300 From: Ruslan Ermilov To: Maxim Sobolev Message-ID: <20041020224032.GA26958@ip.net.ua> References: <41767CF1.2020005@FreeBSD.org> <20041020.105839.100358845.imp@bsdimp.com> <20041020170907.GA1216@orion.daedalusnetworks.priv> <200410201913.42879.max@love2party.net> <20041020194547.GD2195@ip.net.ua> <4176C0C8.4060408@freebsd.org> <4176E329.9090500@portaone.com> <4176E71D.9090500@portaone.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline In-Reply-To: <4176E71D.9090500@portaone.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: Max Laier cc: freebsd-current@FreeBSD.ORG cc: Scott Long cc: freebsd-arch@FreeBSD.ORG Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 22:41:06 -0000 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 21, 2004 at 01:30:53AM +0300, Maxim Sobolev wrote: > Maxim Sobolev wrote: >=20 > >OK, I've just checked objcopy manpage and found that there is actually a= =20 > >better way which combines best properties of both approach. In modern=20 > >GNU toolchain it is possible to split executable and debugging info into= =20 > >two separate files, but put a reference into executable, so that you=20 > >don't have to worry about how to load debugging symbols: > > [...] > >I checked, this works like a charm with our current toolchain/gdb. This= =20 > >allows us to do the following clever trick WRT kernel debug: > > > >1. Compile kernel/modules with debugging symbols; > >2. Split out executable and debugging pieces for each module; > >3. Associate each executable file with appropriate debug file; > >4. Install executable into /boot/kernel as usually; > >5. Install real debugging into /var/something, put symlink to it into=20 > >/boot/kernel. > > > >By the way, this approach can be extended to be an option of buildworld= =20 > >as well! It can be good way to trade developers' time for some hdd=20 > >space, since with this option "on" you will always be able to debug=20 > >misbehaving application/library without the need to recompile/reinstall= =20 > >everything! >=20 > BTW, it also allows us to do create separate "debug" distribution for=20 > release CDs. So that one can do binary install and then add debugging=20 > symbols if necessary. >=20 Now go and hack kmod.mk and kern.post.mk, and I will go to bed. ;) Psycho! :-) Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --4Ckj6UjgE2iN1+kY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBdulgqRfpzJluFF4RAhMRAJ9yWYa4HV7WMIEC5gx/S+6GNv/t+gCeLRA1 X+3x1D5l4gsUU89MPrBoK7M= =nql+ -----END PGP SIGNATURE----- --4Ckj6UjgE2iN1+kY-- From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 23:13:43 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80BEC16A4CE; Wed, 20 Oct 2004 23:13:43 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5588143D1D; Wed, 20 Oct 2004 23:13:43 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i9KNDjrk024523; Wed, 20 Oct 2004 16:13:45 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i9KNDjKN024522; Wed, 20 Oct 2004 16:13:45 -0700 Date: Wed, 20 Oct 2004 16:13:45 -0700 From: Brooks Davis To: Maxim Sobolev Message-ID: <20041020231345.GA23289@odin.ac.hmc.edu> References: <41767CF1.2020005@FreeBSD.org> <20041020.105839.100358845.imp@bsdimp.com> <20041020170907.GA1216@orion.daedalusnetworks.priv> <200410201913.42879.max@love2party.net> <20041020194547.GD2195@ip.net.ua> <4176C0C8.4060408@freebsd.org> <4176E329.9090500@portaone.com> <4176E71D.9090500@portaone.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V" Content-Disposition: inline In-Reply-To: <4176E71D.9090500@portaone.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: Max Laier cc: freebsd-current@freebsd.org cc: Scott Long cc: freebsd-arch@freebsd.org Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 23:13:43 -0000 --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 21, 2004 at 01:30:53AM +0300, Maxim Sobolev wrote: > Maxim Sobolev wrote: >=20 > >OK, I've just checked objcopy manpage and found that there is actually a= =20 > >better way which combines best properties of both approach. In modern=20 > >GNU toolchain it is possible to split executable and debugging info into= =20 > >two separate files, but put a reference into executable, so that you=20 > >don't have to worry about how to load debugging symbols: > > > >--only-keep-debug > > Strip a file, removing any sections that would be stripped by > > --strip-debug and leaving the debugging sections. > > > > The intention is that this option will be used in conjunction with > > --add-gnu-debuglink to create a two part executable. One a > > stripped binary which will occupy less space in RAM and in a dis- > > tribution and the second a debugging information file which is only > > needed if debugging abilities are required. The suggested proce- > > dure to create these files is as follows: > > > > 1. > > "foo" then... > > > > 1. > > create a file containing the debugging info. > > > > 1. > > stripped executable. > > > > 1. > > to add a link to the debugging info into the stripped exe- > > cutable. > > > >I checked, this works like a charm with our current toolchain/gdb. This= =20 > >allows us to do the following clever trick WRT kernel debug: > > > >1. Compile kernel/modules with debugging symbols; > >2. Split out executable and debugging pieces for each module; > >3. Associate each executable file with appropriate debug file; > >4. Install executable into /boot/kernel as usually; > >5. Install real debugging into /var/something, put symlink to it into=20 > >/boot/kernel. > > > >By the way, this approach can be extended to be an option of buildworld= =20 > >as well! It can be good way to trade developers' time for some hdd=20 > >space, since with this option "on" you will always be able to debug=20 > >misbehaving application/library without the need to recompile/reinstall= =20 > >everything! >=20 > BTW, it also allows us to do create separate "debug" distribution for=20 > release CDs. So that one can do binary install and then add debugging=20 > symbols if necessary. I like this idea. A nice feature of this is that you could stick the debug distribution somewhere other then on disk1 so that space could be saved for packages. I'm not sure that would be a good idea, but it would give us more trade space then the current all or nothing setup. -- 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 --xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBdvEoXY6L6fI4GtQRAnh6AJ0ViQhwQNEZHZovafRigJTg5srkfwCfemTI d1/xVAJiD2xjdAntBNLOViM= =F77C -----END PGP SIGNATURE----- --xHFwDpU9dbj6ez1V-- From owner-freebsd-arch@FreeBSD.ORG Thu Oct 21 09:51:14 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0847516A4D0 for ; Thu, 21 Oct 2004 09:51:14 +0000 (GMT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id BC33643D41 for ; Thu, 21 Oct 2004 09:51:12 +0000 (GMT) (envelope-from michaelnottebrock@gmx.net) Received: (qmail 11308 invoked by uid 65534); 21 Oct 2004 09:51:11 -0000 Received: from pD95D8E30.dip.t-dialin.net (EHLO lofi.dyndns.org) (217.93.142.48) by mail.gmx.net (mp007) with SMTP; 21 Oct 2004 11:51:11 +0200 X-Authenticated: #443188 Received: from kiste.my.domain (lofi@kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.12.10/8.12.10) with ESMTP id i9L9okG7002511 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 21 Oct 2004 11:50:48 +0200 (CEST) (envelope-from michaelnottebrock@gmx.net) From: Michael Nottebrock To: freebsd-current@freebsd.org Date: Thu, 21 Oct 2004 11:50:39 +0200 User-Agent: KMail/1.7 References: <41767CF1.2020005@FreeBSD.org> <4176D21F.3060108@elischer.org> <200410202129.i9KLTmTK045310@apollo.backplane.com> In-Reply-To: <200410202129.i9KLTmTK045310@apollo.backplane.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart11811301.99B3qKuaGm"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200410211150.44533.michaelnottebrock@gmx.net> X-Virus-Scanned: by amavisd-new cc: current@freebsd.org cc: mitigator@gmail.com cc: arch@freebsd.org cc: Julian Elischer cc: Wilko Bulte Subject: Re: [Fwd: What do people think about not installing a stripped /kernel ?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 09:51:14 -0000 --nextPart11811301.99B3qKuaGm Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday, 20. October 2004 23:29, Matthew Dillon wrote: > In fact, we enable core dumps in our installs now and once we fix up > /var/crash's size (for new installs), even total newbies will be able to > provide useful cores to us. It's probably a good idea for dragonfly to try and get backtraces from kern= el=20 panics from as many joe-e.-adoppters as possible - new project, many=20 experiments, not much of real world deployment yet, etc, etc.=20 However, do we really need this on FreeBSD? Is the project in that bad a sh= ape=20 and/or do developers have so few time to spare these days for reproducing=20 crashes now? How many mails per day about kernel panics where people have n= o=20 clue about how to get a stack trace are coming in on the -current mailing=20 list daily? I don't see that many. Better invest the time and some addition= al=20 disk-space into (running) more regression testing tools. JMTC. =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --nextPart11811301.99B3qKuaGm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.9.11 (FreeBSD) iD8DBQBBd4Z0Xhc68WspdLARAgGVAKCdNytjvJ4ZDSCBK88DKePKhcBlNwCgjqLD ZmEbBsqq2tZUXJ0xaAzQvZI= =fhTy -----END PGP SIGNATURE----- --nextPart11811301.99B3qKuaGm-- From owner-freebsd-arch@FreeBSD.ORG Thu Oct 21 14:33:22 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 446FF16A4CE for ; Thu, 21 Oct 2004 14:33:22 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 610CF43D31 for ; Thu, 21 Oct 2004 14:33:21 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 77418 invoked from network); 21 Oct 2004 14:31:58 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Oct 2004 14:31:58 -0000 Message-ID: <4177C8AD.6060706@freebsd.org> Date: Thu, 21 Oct 2004 16:33:17 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-arch@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 14:33:22 -0000 I want to bring this up for discussion prior to start working on it. I intend to remove T/TCP (transactional TCP) support from our TCP implementation for the following reasons: o T/TCP is very intrusive to the TCP code and has special cases and dependencies in many places. This makes it a lot harder to maintain the TCP code and is prone to break when other changes are made. In fact I don't know whether still works on 6-current. o T/TCP only available on FreeBSD. No other Operating System or TCP/IP stack implements it to my knowledge. Certainly no OS that is common. o T/TCP is more or less broken by design. It's security model is very weak and it strongly recommended to disable it if your host is exposed to the Internet. o T/TCP is disabled by default on FreeBSD. o T/TCP requires different API calls than TCP to use it (UDP like). o T/TCP is not supported by any common network application. o T/TCP is unmaintained and other major OS have refused to consider including it based on it's weak security model (DDoS heaven). However something like T/TCP is certainly useful and I know of one special purpose application using it (Web Proxy Server/Client for high-delay Satellite connections). Thus after the removal of T/TCP for the reasons above I want to provide a work-alike replacement for T/TCP's functionality: o Using a cookie mechanism instead of the clumsy TAO connection counting like SYN cookies in syncache. o The client has to enable the option in the TCP SYN request to the server. If the server accepts it, then it returns a unique cookie generated from the IP address of the client and some random seed. On subsequent connections the client will include the cookie in the TCP SYN request and it will send the first chunk of payload in the SYN packet. If the cookie matches on the server side, the TCP connection will be direcly propagated into ESTABLISHED state and process plus present the payload to accept socket. The SYN/ACK will be returned together with the answer payload from the socket (or it will SYN/ACK directly as we do now, doesn't matter that much). With this we get the same short-cutting of the 3WSH but with way less intrusive code and much more secure than T/TCP. o Using the same standard TCP API but with an deferred connect() until the first write() is made. o To be enabled with a simple socket option on the client and server side. o All infrastructure is in place to easily implement this (syncache and tcphostcache). This different implementation will be disabled by default and clearly marked EXPERIMENTAL in a protocol sense. It will allow the only known user of T/TCP to keep the same functionality with a very small change to his application. It allows interesting new uses primarily in Intranet environment where many short connections are openend in rapid succession (LDAP servers, SQL servers, etc.). The modifications to those programs to use the new option is minimal and requires only the setting of the socket option, one setsockopt() call. A nice description of T/TCP is here: http://linuxgazette.net/issue47/stacey.html FUD Notice: If you haven't read and/or unstood the link above or TCP/IP Illustrated Volume 3 then please refrain from participating in this discussion! -- Andre From owner-freebsd-arch@FreeBSD.ORG Thu Oct 21 14:42:08 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6CA0116A4CE; Thu, 21 Oct 2004 14:42:08 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99BA243D49; Thu, 21 Oct 2004 14:42:07 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id i9LEg5th028436; Thu, 21 Oct 2004 16:42:05 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Andre Oppermann From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 21 Oct 2004 16:33:17 +0200." <4177C8AD.6060706@freebsd.org> Date: Thu, 21 Oct 2004 16:42:05 +0200 Message-ID: <28435.1098369725@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 14:42:08 -0000 In message <4177C8AD.6060706@freebsd.org>, Andre Oppermann writes: >I want to bring this up for discussion prior to start working on it. > >I intend to remove T/TCP (transactional TCP) support from our TCP >implementation for the following reasons: Yeah, go for it! >However something like T/TCP is certainly useful and I know of one special >purpose application using it (Web Proxy Server/Client for high-delay Satellite >connections). Wouldn't that be inferior to what accept-filters gives us ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Thu Oct 21 14:47:19 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E6AE16A4CE for ; Thu, 21 Oct 2004 14:47:19 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6187A43D41 for ; Thu, 21 Oct 2004 14:47:18 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 77641 invoked from network); 21 Oct 2004 14:45:55 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Oct 2004 14:45:55 -0000 Message-ID: <4177CBFC.AEA69F47@freebsd.org> Date: Thu, 21 Oct 2004 16:47:24 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp References: <28435.1098369725@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 14:47:19 -0000 Poul-Henning Kamp wrote: > > In message <4177C8AD.6060706@freebsd.org>, Andre Oppermann writes: > >I want to bring this up for discussion prior to start working on it. > > > >I intend to remove T/TCP (transactional TCP) support from our TCP > >implementation for the following reasons: > > Yeah, go for it! > > >However something like T/TCP is certainly useful and I know of one special > >purpose application using it (Web Proxy Server/Client for high-delay Satellite > >connections). > > Wouldn't that be inferior to what accept-filters gives us ? No, not at all. In fact they are complementary and work beautifully together. T/TCP and the replacement are about cutting the extra round-trip times for the three-way handshake of TCP. accept_filter is sort of a buffer that defers readablility to userland until a full request has been received (a HTTP/1.1 request for example). -- Andre From owner-freebsd-arch@FreeBSD.ORG Thu Oct 21 14:59:26 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DC3916A4CE; Thu, 21 Oct 2004 14:59:26 +0000 (GMT) Received: from starburst.demon.co.uk (starburst.demon.co.uk [80.176.229.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4616943D55; Thu, 21 Oct 2004 14:59:25 +0000 (GMT) (envelope-from richard@starburst.demon.co.uk) Received: (from richard@localhost) by starburst.demon.co.uk (8.11.6/8.11.6) id i9LExNX13313; Thu, 21 Oct 2004 15:59:23 +0100 From: Richard Wendland Message-Id: <200410211459.i9LExNX13313@starburst.demon.co.uk> To: andre@freebsd.org (Andre Oppermann) Date: Thu, 21 Oct 2004 15:59:22 +0100 (BST) In-Reply-To: <4177C8AD.6060706@freebsd.org> from "Andre Oppermann" at Oct 21, 2004 04:33:17 X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: richard@codeburst.co.uk List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 14:59:26 -0000 > I intend to remove T/TCP (transactional TCP) support from our TCP > implementation for the following reasons: Good reasons & decision Andre. Another reason is that T/TCP (RFC1644) is listed as "deprecated" in the "Roadmap for TCP Specification Documents" I-D, almost certainly to become a RFC soon: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-roadmap-00.txt Richard -- Richard Wendland richard@codeburst.co.uk From owner-freebsd-arch@FreeBSD.ORG Thu Oct 21 15:24:11 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FBB516A4CF for ; Thu, 21 Oct 2004 15:24:11 +0000 (GMT) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.FreeBSD.org (Postfix) with SMTP id C367443D5D for ; Thu, 21 Oct 2004 15:24:10 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 67547 invoked from network); 21 Oct 2004 15:24:09 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay01.pair.com with SMTP; 21 Oct 2004 15:24:09 -0000 X-pair-Authenticated: 209.68.2.70 Date: Thu, 21 Oct 2004 10:24:08 -0500 (CDT) From: Mike Silbersack To: Andre Oppermann In-Reply-To: <4177C8AD.6060706@freebsd.org> Message-ID: <20041021101010.V7681@odysseus.silby.com> References: <4177C8AD.6060706@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 15:24:11 -0000 On Thu, 21 Oct 2004, Andre Oppermann wrote: > I want to bring this up for discussion prior to start working on it. > > I intend to remove T/TCP (transactional TCP) support from our TCP > implementation for the following reasons: That sounds good. > o The client has to enable the option in the TCP SYN request to the server. > If the server accepts it, then it returns a unique cookie generated from > the IP address of the client and some random seed. On subsequent > connections > the client will include the cookie in the TCP SYN request and it will > send the first chunk of payload in the SYN packet. If the cookie matches I think that it would have to be slightly more complex than that for it to be secure. Instead of using syncookie/RFC1948-like generation, just randomly generate the cookie and store it in the tcp host cache. Then steal the concept of NQNFS leases, giving the cookie a limited lifetime, after which it must be reissued. I think you'll need to track two cookies on the server side, to gracefully handle the cookie transition period... Well, I'm sure there are many ways to do it, but I agree that it's certainly doable; we have plenty of time to talk about the exact implementation. My reason for avoiding the use of syncookies/RFC1948 in the implementation is that relying on those pieces of code makes a FreeBSD implementation easy, but would make an implementation in other OSes potentially difficult. > FUD Notice: > > If you haven't read and/or unstood the link above or TCP/IP Illustrated > Volume 3 then please refrain from participating in this discussion! Hey, I just looked in section 24.7 in Vol. 1, and it says nothing but good things about T/TCP - you must be the one misunderstanding things here! :) Mike "Silby" Silbersack From owner-freebsd-arch@FreeBSD.ORG Thu Oct 21 15:35:21 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12B5F16A4DD for ; Thu, 21 Oct 2004 15:35:21 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E47643D31 for ; Thu, 21 Oct 2004 15:35:20 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 78076 invoked from network); 21 Oct 2004 15:33:57 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Oct 2004 15:33:57 -0000 Message-ID: <4177D73E.C0531896@freebsd.org> Date: Thu, 21 Oct 2004 17:35:26 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Silbersack References: <4177C8AD.6060706@freebsd.org> <20041021101010.V7681@odysseus.silby.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 15:35:21 -0000 Mike Silbersack wrote: > > On Thu, 21 Oct 2004, Andre Oppermann wrote: > > o The client has to enable the option in the TCP SYN request to the server. > > If the server accepts it, then it returns a unique cookie generated from > > the IP address of the client and some random seed. On subsequent > > connections > > the client will include the cookie in the TCP SYN request and it will > > send the first chunk of payload in the SYN packet. If the cookie matches > > I think that it would have to be slightly more complex than that for it to > be secure. Instead of using syncookie/RFC1948-like generation, just > randomly generate the cookie and store it in the tcp host cache. Then > steal the concept of NQNFS leases, giving the cookie a limited lifetime, > after which it must be reissued. I think you'll need to track two cookies > on the server side, to gracefully handle the cookie transition period... It wasn't meant to use the exact syncookies code, but the general mechanism like your description of it. We can't use syncookies and that code as is anyway because it puts far more information into the cookie. > Well, I'm sure there are many ways to do it, but I agree that it's > certainly doable; we have plenty of time to talk about the exact > implementation. My reason for avoiding the use of syncookies/RFC1948 in > the implementation is that relying on those pieces of code makes a FreeBSD > implementation easy, but would make an implementation in other OSes > potentially difficult. -- Andre From owner-freebsd-arch@FreeBSD.ORG Thu Oct 21 15:39:44 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9314516A4CE; Thu, 21 Oct 2004 15:39:44 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0273243D1F; Thu, 21 Oct 2004 15:39:44 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 4C00265213; Thu, 21 Oct 2004 16:39:42 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 68561-01-14; Thu, 21 Oct 2004 16:39:41 +0100 (BST) Received: from empiric.dek.spc.org (adsl-67-121-95-134.dsl.snfc21.pacbell.net [67.121.95.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 61E43651F4; Thu, 21 Oct 2004 16:39:41 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 7EA0965F6; Thu, 21 Oct 2004 08:39:33 -0700 (PDT) Date: Thu, 21 Oct 2004 08:39:33 -0700 From: Bruce M Simpson To: Andre Oppermann Message-ID: <20041021153933.GK13756@empiric.icir.org> Mail-Followup-To: Andre Oppermann , freebsd-arch@freebsd.org, freebsd-net@freebsd.org References: <4177C8AD.6060706@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4177C8AD.6060706@freebsd.org> cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 15:39:44 -0000 On Thu, Oct 21, 2004 at 04:33:17PM +0200, Andre Oppermann wrote: > I intend to remove T/TCP (transactional TCP) support from our TCP > implementation for the following reasons: Go ahead and kill the old thing, it's time. I agree. > Thus after the removal of T/TCP for the reasons above I want to provide > a work-alike replacement for T/TCP's functionality: I disagree. I think the time spent here would be better spent on working on an import of SCTP into the kernel, perhaps the KAME code base would be a good starting point. Regards, BMS From owner-freebsd-arch@FreeBSD.ORG Thu Oct 21 16:22:48 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BFAC116A4CE for ; Thu, 21 Oct 2004 16:22:48 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 336C543D39 for ; Thu, 21 Oct 2004 16:22:48 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 78473 invoked from network); 21 Oct 2004 16:21:24 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Oct 2004 16:21:24 -0000 Message-ID: <4177E25E.804639E@freebsd.org> Date: Thu, 21 Oct 2004 18:22:54 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce M Simpson References: <4177C8AD.6060706@freebsd.org> <20041021153933.GK13756@empiric.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 16:22:48 -0000 Bruce M Simpson wrote: > > On Thu, Oct 21, 2004 at 04:33:17PM +0200, Andre Oppermann wrote: > > Thus after the removal of T/TCP for the reasons above I want to provide > > a work-alike replacement for T/TCP's functionality: > > I disagree. I think the time spent here would be better spent on working > on an import of SCTP into the kernel, perhaps the KAME code base would > be a good starting point. Is the SCTP in KAME complete and stable? Are there any other (open source) implementations of it? It's my time and I'll do the T/TCP replacement in any case because I think it is useful. :) -- Andre From owner-freebsd-arch@FreeBSD.ORG Thu Oct 21 16:27:59 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5DCDB16A4CE; Thu, 21 Oct 2004 16:27:59 +0000 (GMT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFB7443D67; Thu, 21 Oct 2004 16:27:58 +0000 (GMT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id i9LGRvqw026450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Thu, 21 Oct 2004 12:27:57 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id i9LGRvsj026447; Thu, 21 Oct 2004 12:27:57 -0400 (EDT) (envelope-from wollman) Date: Thu, 21 Oct 2004 12:27:57 -0400 (EDT) From: Garrett Wollman Message-Id: <200410211627.i9LGRvsj026447@khavrinen.lcs.mit.edu> To: Mike Silbersack In-Reply-To: <20041021101010.V7681@odysseus.silby.com> References: <4177C8AD.6060706@freebsd.org> <20041021101010.V7681@odysseus.silby.com> X-Spam-Score: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.37 cc: freebsd-net@FreeBSD.ORG cc: freebsd-arch@FreeBSD.ORG Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 16:27:59 -0000 < said: > I think that it would have to be slightly more complex than that for it to > be secure. Instead of using syncookie/RFC1948-like generation, > [...] HIP! HIP! HIP!!! -GAWollman From owner-freebsd-arch@FreeBSD.ORG Thu Oct 21 17:31:47 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 265DE16A4CF; Thu, 21 Oct 2004 17:31:47 +0000 (GMT) Received: from wyvern.icir.org (wyvern.icir.org [192.150.187.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id B254D43D49; Thu, 21 Oct 2004 17:31:46 +0000 (GMT) (envelope-from mallman@icir.org) Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id i9LHVkag092966; Thu, 21 Oct 2004 10:31:46 -0700 (PDT) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 1AE6477A9D0; Thu, 21 Oct 2004 13:31:45 -0400 (EDT) To: Andre Oppermann From: Mark Allman In-Reply-To: <4177C8AD.6060706@freebsd.org> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Lights MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 21 Oct 2004 13:31:45 -0400 Sender: mallman@icir.org Message-Id: <20041021173145.1AE6477A9D0@guns.icir.org> cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: mallman@icir.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 17:31:47 -0000 --=-=-= Content-Type: text/plain > I intend to remove T/TCP (transactional TCP) support from our TCP > implementation for the following reasons: Yeah, I think that makes a bunch of sense. > Thus after the removal of T/TCP for the reasons above I want to provide > a work-alike replacement for T/TCP's functionality: I haven't fully digested this yet. But, I'll voice my distaste for implementing things that just seem to "Make Sense". That's a model that has been used and is used by other operating systems and those of us who watch packets can attest that things that "Make Sense" often don't and likely would have benefitted by a bit more thought and a bit more vetting. I would be happier if something like this were vetted out a bit more (written up, digested by folks, etc.) before it went into anything but someone's experimental kernel. Just my two cents. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFBd/KBWyrrWs4yIs4RAg2gAJ9xlUCP//uGpoOA7LI2d7DINHVz3gCfR1bP jaMNH+4vOnCC06DHV7tU930= =UPzK -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-arch@FreeBSD.ORG Thu Oct 21 17:57:04 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D1A716A4CE for ; Thu, 21 Oct 2004 17:57:04 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94D7743D54 for ; Thu, 21 Oct 2004 17:57:03 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 79111 invoked from network); 21 Oct 2004 17:55:39 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Oct 2004 17:55:39 -0000 Message-ID: <4177F875.2822A51E@freebsd.org> Date: Thu, 21 Oct 2004 19:57:09 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mallman@icir.org References: <20041021173145.1AE6477A9D0@guns.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 17:57:04 -0000 Mark Allman wrote: > > Thus after the removal of T/TCP for the reasons above I want to provide > > a work-alike replacement for T/TCP's functionality: > > I haven't fully digested this yet. But, I'll voice my distaste for > implementing things that just seem to "Make Sense". That's a model that > has been used and is used by other operating systems and those of us who > watch packets can attest that things that "Make Sense" often don't and > likely would have benefitted by a bit more thought and a bit more > vetting. I would be happier if something like this were vetted out a > bit more (written up, digested by folks, etc.) before it went into > anything but someone's experimental kernel. Just my two cents. Sure. To make you sleep better it will be disabled by default (like T/TCP) and possibly even not compliled in by default (#ifdef'd). If enabled and compiled in it does not automatically enable itself for all and everything. The application has to enable it on the socket as well. A writeup will follow once I get there. I made this request before I start working on it to prevent to waste my time on it if people wanted to religiously stick to T/TCP. -- Andre From owner-freebsd-arch@FreeBSD.ORG Thu Oct 21 18:31:42 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A7B716A4CE; Thu, 21 Oct 2004 18:31:42 +0000 (GMT) Received: from skippyii.compar.com (test.compar.com [216.208.38.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE09143D2F; Thu, 21 Oct 2004 18:31:41 +0000 (GMT) (envelope-from matt@gsicomp.on.ca) Received: from hermes (CPE00062566c7bb-CM000039c69a66.cpe.net.cable.rogers.com [69.193.82.185])i9LIc4cW051189; Thu, 21 Oct 2004 14:38:05 -0400 (EDT) (envelope-from matt@gsicomp.on.ca) Message-ID: <00e901c4b79b$d13e6e40$1200a8c0@gsicomp.on.ca> From: "Matt Emmerton" To: "Andre Oppermann" , "Bruce M Simpson" References: <4177C8AD.6060706@freebsd.org><20041021153933.GK13756@empiric.icir.org> <4177E25E.804639E@freebsd.org> Date: Thu, 21 Oct 2004 14:28:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 18:31:42 -0000 > Bruce M Simpson wrote: > > > > On Thu, Oct 21, 2004 at 04:33:17PM +0200, Andre Oppermann wrote: > > > Thus after the removal of T/TCP for the reasons above I want to provide > > > a work-alike replacement for T/TCP's functionality: > > > > I disagree. I think the time spent here would be better spent on working > > on an import of SCTP into the kernel, perhaps the KAME code base would > > be a good starting point. > > Is the SCTP in KAME complete and stable? Are there any other (open source) > implementations of it? The SCTP home page (www.sctp.org) has a list of implementations. Note that I had to use Google's cache of the site -- I believe there was a Slashdot article on SCTP this morning which may have taken down the site. AIX, Solaris, HP and Cisco all support SCTP in their latest OS versions. There are aslo a few different (non-free) implementations for Windows, and at least one open-source implementation for Linux (http://www.openss7.org) -- Matt Emmerton From owner-freebsd-arch@FreeBSD.ORG Thu Oct 21 18:31:48 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BD8A16A4D0; Thu, 21 Oct 2004 18:31:48 +0000 (GMT) Received: from mail.trippynames.com (mail.trippynames.com [38.113.223.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2DE443D53; Thu, 21 Oct 2004 18:31:47 +0000 (GMT) (envelope-from sean@chittenden.org) Received: from localhost (localhost [127.0.0.1]) by mail.trippynames.com (Postfix) with ESMTP id 537B0A2800; Thu, 21 Oct 2004 11:31:47 -0700 (PDT) Received: from mail.trippynames.com ([127.0.0.1]) by localhost (rand.nxad.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 83601-09; Thu, 21 Oct 2004 11:31:45 -0700 (PDT) Received: from [192.168.1.102] (wbar4.sjo1-4.28.216.220.sjo1.dsl-verizon.net [4.28.216.220]) by mail.trippynames.com (Postfix) with ESMTP id 40E3EA3142; Thu, 21 Oct 2004 11:31:45 -0700 (PDT) In-Reply-To: <4177C8AD.6060706@freebsd.org> References: <4177C8AD.6060706@freebsd.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <71C3A1EA-238F-11D9-9171-000A95C705DC@chittenden.org> Content-Transfer-Encoding: 7bit From: Sean Chittenden Date: Thu, 21 Oct 2004 11:31:38 -0700 To: Andre Oppermann X-Mailer: Apple Mail (2.619) cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 18:31:49 -0000 > I intend to remove T/TCP (transactional TCP) support from our TCP > implementation for the following reasons: The special cases are evil. > However something like T/TCP is certainly useful and I know of one > special > purpose application using it (Web Proxy Server/Client for high-delay > Satellite > connections). Actually, there are two/three programs that I know of that use it. memcached(1), which found a fantastic decrease in its benchmarks. Here's an excerpt from the following link: http://lists.danga.com/pipermail/memcached/2003-August/000111.html > I benchmarked 3 different methods of doing network I/O: > > 1) the default way, with the Nagel algorithm. > 2) using TCP_CORK (Linux, same as TCP_PUSH on BSD) > 3) using TCP_NODELAY > > I measured both real time and number of packets on the wire. > The test was doing 2,500 deletes, sets, and gets, then a 2,500 > get_multi. > > Seconds Packets > DEFAULT 102.48 22638 > TCP_CORK 3.88 15105 > TCP_CORK 3.87 15108 > TCP_CORK 3.86 15105 > TCP_NODELAY 3.99 20169 > TCP_NODELAY 4.04 20170 > TCP_NODELAY 4.00 20170 and an internal reverse proxy server/modified apache that I've hacked together (reduces latency in a tiered request hierarchy a great deal, on order of the benchmarks from above). That said, I can't stress enough the usefulness of TCP_NOPUSH/ttcp(4). However it gets implemented, I don't really care. If ttcp(4) is ready to bite the dust, so be it, but extensions/options like this are fantastically useful to those who know about its existence/usefulness. Good luck with the replacement. :) In 2001, there was a push to make Linux's TCP_CORK option behave the same as FreeBSD's TCP_NOPUSH. Is maintaining that compatibility still a goal, or are we going to kick this change off to the Linux folk to have them play catchup (to what sounds like a more secure option than Linux's TCP_CORK)? http://seclists.org/linux-kernel/2001/Feb/0993.html -sc -- Sean Chittenden From owner-freebsd-arch@FreeBSD.ORG Thu Oct 21 18:32:40 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 849FA16A4CE; Thu, 21 Oct 2004 18:32:40 +0000 (GMT) Received: from wyvern.icir.org (wyvern.icir.org [192.150.187.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69B3743D4C; Thu, 21 Oct 2004 18:32:40 +0000 (GMT) (envelope-from mallman@icir.org) Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id i9LIWdag093598; Thu, 21 Oct 2004 11:32:39 -0700 (PDT) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 00E8977A9D0; Thu, 21 Oct 2004 14:32:38 -0400 (EDT) To: Andre Oppermann From: Mark Allman In-Reply-To: <4177F875.2822A51E@freebsd.org> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Lights MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 21 Oct 2004 14:32:37 -0400 Sender: mallman@icir.org Message-Id: <20041021183238.00E8977A9D0@guns.icir.org> cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: mallman@icir.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 18:32:40 -0000 --=-=-= Content-Type: text/plain > Sure. To make you sleep better it will be disabled by default (like > T/TCP) and possibly even not compliled in by default (#ifdef'd). Part of your argument against T/TCP. :-) > A writeup will follow once I get there. I made this request before I > start working on it to prevent to waste my time on it if people wanted > to religiously stick to T/TCP. I think moving on from T/TCP is fine, don't get me wrong. And, I am all for seeing new schemes that buy us some of the things T/TCP was designed for. I am just not enthusiastic about dumping things into the kernel without some review and thought (by more than one person; and, that is not a knock on you --- if I had a nickel for every half-baked thing I'd implemented somewhere .... basically, it's good to get different perspectives). Doing this in a systematic way may have benefits beyond FreeBSD, as well, of course. allman --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFBeADFWyrrWs4yIs4RAuRpAJ97dKby5KS6sJKaDupU8s4OU7/1rQCfURgQ qF+ji12qxOfWn09/Xu92sxg= =MK6u -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-arch@FreeBSD.ORG Thu Oct 21 18:51:39 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1104716A4CE; Thu, 21 Oct 2004 18:51:39 +0000 (GMT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF6AF43D41; Thu, 21 Oct 2004 18:51:38 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.13.1/8.13.1) with ESMTP id i9LIpcVc037579; Thu, 21 Oct 2004 11:51:38 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id i9LIpcpO037578; Thu, 21 Oct 2004 11:51:38 -0700 (PDT) (envelope-from obrien) Date: Thu, 21 Oct 2004 11:51:37 -0700 From: "David O'Brien" To: Andre Oppermann Message-ID: <20041021185137.GA37500@dragon.nuxi.com> References: <4177C8AD.6060706@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4177C8AD.6060706@freebsd.org> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 6.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 cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-arch@freebsd.org, freebsd-net@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 18:51:39 -0000 On Thu, Oct 21, 2004 at 04:33:17PM +0200, Andre Oppermann wrote: > I intend to remove T/TCP (transactional TCP) support from our TCP > implementation for the following reasons: .. Fine. > Thus after the removal of T/TCP for the reasons above I want to provide > a work-alike replacement for T/TCP's functionality: .. > This different implementation will be disabled by default and clearly > marked EXPERIMENTAL in a protocol sense. It will allow the only known > user of T/TCP to keep the same functionality with a very small change > to his application. It allows interesting new uses primarily in > Intranet environment where many short connections are openend in rapid > succession (LDAP servers, SQL servers, etc.). The modifications to > those programs to use the new option is minimal and requires only the > setting of the socket option, one setsockopt() call. I'm not so happy with a FreeBSD-only "proprietary" thing. Is there any proposed RFC work that provides the qualities you want? The advantage with T/TCP is that there was a published standard. -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Thu Oct 21 18:56:50 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3609616A4D7 for ; Thu, 21 Oct 2004 18:56:50 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA9D643D5A for ; Thu, 21 Oct 2004 18:56:46 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 79653 invoked from network); 21 Oct 2004 18:55:20 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Oct 2004 18:55:20 -0000 Message-ID: <41780672.6AAC705F@freebsd.org> Date: Thu, 21 Oct 2004 20:56:50 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Chittenden References: <4177C8AD.6060706@freebsd.org> <71C3A1EA-238F-11D9-9171-000A95C705DC@chittenden.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 18:56:50 -0000 Sean Chittenden wrote: > > > I intend to remove T/TCP (transactional TCP) support from our TCP > > implementation for the following reasons: > > The special cases are evil. Indeed. > > However something like T/TCP is certainly useful and I know of one > > special > > purpose application using it (Web Proxy Server/Client for high-delay > > Satellite > > connections). > > Actually, there are two/three programs that I know of that use it. > memcached(1), which found a fantastic decrease in its benchmarks. > Here's an excerpt from the following link: > > http://lists.danga.com/pipermail/memcached/2003-August/000111.html I think you got something wrong here. T/TCP is never ever mentioned in this. Memcached is not using T/TCP as far as I can see. > and an internal reverse proxy server/modified apache that I've hacked > together (reduces latency in a tiered request hierarchy a great deal, > on order of the benchmarks from above). What syscall do you use to get to the other side in your reverse proxy? > That said, I can't stress enough the usefulness of TCP_NOPUSH/ttcp(4). Ah, I'm not going to remove TCP_NOPUSH. It can live independ of T/TCP. While this option has been introduced together with T/TCP enabling it does not make you use T/TCP. > However it gets implemented, I don't really care. If ttcp(4) is ready > to bite the dust, so be it, but extensions/options like this are > fantastically useful to those who know about its existence/usefulness. > Good luck with the replacement. :) Thanks. > In 2001, there was a push to make Linux's TCP_CORK option behave the > same as FreeBSD's TCP_NOPUSH. Is maintaining that compatibility still > a goal, or are we going to kick this change off to the Linux folk to > have them play catchup (to what sounds like a more secure option than > Linux's TCP_CORK)? > > http://seclists.org/linux-kernel/2001/Feb/0993.html I'm not sure if I can follow you here. TCP_CORK deals with the different behaviour of connections with Nagle vs. TCP_NODELAY. TCP_CORK allows to avoid the delays of Nagle by corking (sort of blocking) the sending of packets until you are done with write()ing to the socket. Then the connection is uncorked and all data will be sent in one go even if it doesn't fill an entire packet. Sort of an fsync() for sockets. There are no security implications with TCP_CORK as far as I am aware. -- Andre From owner-freebsd-arch@FreeBSD.ORG Thu Oct 21 18:58:59 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47AD716A4CE; Thu, 21 Oct 2004 18:58:59 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F26343D39; Thu, 21 Oct 2004 18:58:59 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 126667A424; Thu, 21 Oct 2004 11:58:59 -0700 (PDT) Message-ID: <417806F2.50607@elischer.org> Date: Thu, 21 Oct 2004 11:58:58 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Andre Oppermann References: <20041021173145.1AE6477A9D0@guns.icir.org> <4177F875.2822A51E@freebsd.org> In-Reply-To: <4177F875.2822A51E@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org cc: mallman@icir.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 18:58:59 -0000 Andre Oppermann wrote: >Mark Allman wrote: > > >>>Thus after the removal of T/TCP for the reasons above I want to provide >>>a work-alike replacement for T/TCP's functionality: >>> >>> >>I haven't fully digested this yet. But, I'll voice my distaste for >>implementing things that just seem to "Make Sense". That's a model that >>has been used and is used by other operating systems and those of us who >>watch packets can attest that things that "Make Sense" often don't and >>likely would have benefitted by a bit more thought and a bit more >>vetting. I would be happier if something like this were vetted out a >>bit more (written up, digested by folks, etc.) before it went into >>anything but someone's experimental kernel. Just my two cents. >> >> > >Sure. To make you sleep better it will be disabled by default (like >T/TCP) and possibly even not compliled in by default (#ifdef'd). If >enabled and compiled in it does not automatically enable itself for all >and everything. The application has to enable it on the socket as well. > >A writeup will follow once I get there. I made this request before I >start working on it to prevent to waste my time on it if people wanted >to religiously stick to T/TCP. > > couldn't you do it with a spoofing interface? i.e. tcp sessions going through get turned into something that loks like ttcp on the wire and converted back at teh other end? From owner-freebsd-arch@FreeBSD.ORG Thu Oct 21 19:01:59 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1091B16A4CE; Thu, 21 Oct 2004 19:01:59 +0000 (GMT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAA6443D53; Thu, 21 Oct 2004 19:01:58 +0000 (GMT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id i9LJ1vqw028422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Thu, 21 Oct 2004 15:01:57 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id i9LJ1u28028419; Thu, 21 Oct 2004 15:01:56 -0400 (EDT) (envelope-from wollman) Date: Thu, 21 Oct 2004 15:01:56 -0400 (EDT) From: Garrett Wollman Message-Id: <200410211901.i9LJ1u28028419@khavrinen.lcs.mit.edu> To: freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG In-Reply-To: <20041021185137.GA37500@dragon.nuxi.com> References: <4177C8AD.6060706@freebsd.org> <20041021185137.GA37500@dragon.nuxi.com> X-Spam-Score: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.37 Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 19:01:59 -0000 < said: > I'm not so happy with a FreeBSD-only "proprietary" thing. Is there any > proposed RFC work that provides the qualities you want? The advantage > with T/TCP is that there was a published standard. T/TCP was a published *non*standard, loudly blazoned "EXPERIMENTAL". I don't see how Andre's proposed replacement can be any worse. -GAWollman From owner-freebsd-arch@FreeBSD.ORG Thu Oct 21 19:03:12 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A96DF16A4CF for ; Thu, 21 Oct 2004 19:03:12 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D441F43D68 for ; Thu, 21 Oct 2004 19:03:11 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 79741 invoked from network); 21 Oct 2004 19:01:47 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Oct 2004 19:01:47 -0000 Message-ID: <417807F5.AE550647@freebsd.org> Date: Thu, 21 Oct 2004 21:03:17 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-arch@freebsd.org, freebsd-net@freebsd.org References: <4177C8AD.6060706@freebsd.org> <20041021185137.GA37500@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 19:03:12 -0000 David O'Brien wrote: > > On Thu, Oct 21, 2004 at 04:33:17PM +0200, Andre Oppermann wrote: > > Thus after the removal of T/TCP for the reasons above I want to provide > > a work-alike replacement for T/TCP's functionality: > .. > > This different implementation will be disabled by default and clearly > > marked EXPERIMENTAL in a protocol sense. It will allow the only known > > user of T/TCP to keep the same functionality with a very small change > > to his application. It allows interesting new uses primarily in > > Intranet environment where many short connections are openend in rapid > > succession (LDAP servers, SQL servers, etc.). The modifications to > > those programs to use the new option is minimal and requires only the > > setting of the socket option, one setsockopt() call. > > I'm not so happy with a FreeBSD-only "proprietary" thing. Is there any > proposed RFC work that provides the qualities you want? The advantage > with T/TCP is that there was a published standard. Not for TCP. There are plenty of proposed or approved replacements for TCP though. Implementing or importing them is a lot harder and applications wanting to use it have to be extensively modified. The nice thing of my proposed replacement is its simplicity. Submitting an RFC draft for that is not hard and I'm going to do it based on the feedback I've got so far. I think we can enough drive behind this to make it an actual published RFC standard. Don't worry. I don't want to remove one intrusive piece of code just to replace it with another one. -- Andre From owner-freebsd-arch@FreeBSD.ORG Thu Oct 21 19:04:56 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFBAB16A4CE for ; Thu, 21 Oct 2004 19:04:56 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C7C443D6B for ; Thu, 21 Oct 2004 19:04:56 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 79777 invoked from network); 21 Oct 2004 19:03:31 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Oct 2004 19:03:31 -0000 Message-ID: <4178085D.898E981D@freebsd.org> Date: Thu, 21 Oct 2004 21:05:01 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer References: <20041021173145.1AE6477A9D0@guns.icir.org> <4177F875.2822A51E@freebsd.org> <417806F2.50607@elischer.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org cc: mallman@icir.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 19:04:57 -0000 Julian Elischer wrote: > > Andre Oppermann wrote: > > >Mark Allman wrote: > > > > > >>>Thus after the removal of T/TCP for the reasons above I want to provide > >>>a work-alike replacement for T/TCP's functionality: > >>> > >>> > >>I haven't fully digested this yet. But, I'll voice my distaste for > >>implementing things that just seem to "Make Sense". That's a model that > >>has been used and is used by other operating systems and those of us who > >>watch packets can attest that things that "Make Sense" often don't and > >>likely would have benefitted by a bit more thought and a bit more > >>vetting. I would be happier if something like this were vetted out a > >>bit more (written up, digested by folks, etc.) before it went into > >>anything but someone's experimental kernel. Just my two cents. > >> > >> > > > >Sure. To make you sleep better it will be disabled by default (like > >T/TCP) and possibly even not compliled in by default (#ifdef'd). If > >enabled and compiled in it does not automatically enable itself for all > >and everything. The application has to enable it on the socket as well. > > > >A writeup will follow once I get there. I made this request before I > >start working on it to prevent to waste my time on it if people wanted > >to religiously stick to T/TCP. > > > > > > couldn't you do it with a spoofing interface? > i.e. tcp sessions going through get turned into something that loks like > ttcp > on the wire and converted back at teh other end? You failed the FUD test at the bottom of my email. -- Andre From owner-freebsd-arch@FreeBSD.ORG Thu Oct 21 19:24:54 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 59DED16A4CE; Thu, 21 Oct 2004 19:24:54 +0000 (GMT) Received: from mail.trippynames.com (mail.trippynames.com [38.113.223.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 418FA43D46; Thu, 21 Oct 2004 19:24:54 +0000 (GMT) (envelope-from sean@chittenden.org) Received: from localhost (localhost [127.0.0.1]) by mail.trippynames.com (Postfix) with ESMTP id 8AE9EA4129; Thu, 21 Oct 2004 12:24:53 -0700 (PDT) Received: from mail.trippynames.com ([127.0.0.1]) by localhost (rand.nxad.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 90346-02; Thu, 21 Oct 2004 12:24:52 -0700 (PDT) Received: from [192.168.1.102] (wbar4.sjo1-4.28.216.220.sjo1.dsl-verizon.net [4.28.216.220]) by mail.trippynames.com (Postfix) with ESMTP id 08FD6A4121; Thu, 21 Oct 2004 12:24:51 -0700 (PDT) In-Reply-To: <41780672.6AAC705F@freebsd.org> References: <4177C8AD.6060706@freebsd.org> <71C3A1EA-238F-11D9-9171-000A95C705DC@chittenden.org> <41780672.6AAC705F@freebsd.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Sean Chittenden Date: Thu, 21 Oct 2004 12:24:50 -0700 To: Andre Oppermann X-Mailer: Apple Mail (2.619) cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 19:24:54 -0000 >>> However something like T/TCP is certainly useful and I know of one >>> special >>> purpose application using it (Web Proxy Server/Client for high-delay >>> Satellite >>> connections). >> >> Actually, there are two/three programs that I know of that use it. >> memcached(1), which found a fantastic decrease in its benchmarks. >> Here's an excerpt from the following link: >> >> http://lists.danga.com/pipermail/memcached/2003-August/000111.html > > I think you got something wrong here. T/TCP is never ever mentioned > in this. Memcached is not using T/TCP as far as I can see. It's not, but I thought setsockopt(2) w/ TCP_NOPUSH enabled the use of T/TCP in that there was no 3WHS performed on a TCP_NOPUSH'ed connection. >> and an internal reverse proxy server/modified apache that I've hacked >> together (reduces latency in a tiered request hierarchy a great deal, >> on order of the benchmarks from above). > > What syscall do you use to get to the other side in your reverse proxy? On the client, sendto()/read(). On the server, setsockopt() + write(). >> In 2001, there was a push to make Linux's TCP_CORK option behave the >> same as FreeBSD's TCP_NOPUSH. Is maintaining that compatibility still >> a goal, or are we going to kick this change off to the Linux folk to >> have them play catchup (to what sounds like a more secure option than >> Linux's TCP_CORK)? >> >> http://seclists.org/linux-kernel/2001/Feb/0993.html > > I'm not sure if I can follow you here. TCP_CORK deals with the > different > behaviour of connections with Nagle vs. TCP_NODELAY. TCP_CORK allows > to > avoid the delays of Nagle by corking (sort of blocking) the sending of > packets until you are done with write()ing to the socket. Then the > connection is uncorked and all data will be sent in one go even if it > doesn't fill an entire packet. Sort of an fsync() for sockets. There > are no security implications with TCP_CORK as far as I am aware. Isn't that what NOPUSH does? Or is it that CORK uses a fully established TCP connection, but blocks sending data until the connection has been uncorked/flushed? I thought that TCP_CORK had the same security implications that NOPUSH does (ie, the lack of a hand shake). I was under the impression that by default NOPUSH would prevent a connect() until there was a full packet to be sent or the socket had been closed/flushed. The first/only packet from the client to the server would contain a SIN+PUSH+FIN + the data for the request, then the server would come back with a SIN+PUSH+FIN+ACK. Essentially UDP, but with checksums and packet retransmission built in. -sc -- Sean Chittenden From owner-freebsd-arch@FreeBSD.ORG Thu Oct 21 19:34:23 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5E9316A4CE; Thu, 21 Oct 2004 19:34:23 +0000 (GMT) Received: from www.citello.it (host170-131.pool80117.interbusiness.it [80.117.131.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1793443D2D; Thu, 21 Oct 2004 19:34:21 +0000 (GMT) (envelope-from molter@tin.it) Received: from gattaccio.codalunga (ANice-205-1-12-243.w81-248.abo.wanadoo.fr [81.248.122.243]) by www.citello.it (Postfix) with ESMTP id 6CD091559; Thu, 21 Oct 2004 21:34:27 +0200 (CEST) Received: by gattaccio.codalunga (Postfix, from userid 1001) id 140EDC117; Thu, 21 Oct 2004 21:32:49 +0200 (CEST) Date: Thu, 21 Oct 2004 21:32:48 +0200 From: Marco Molteni To: Andre Oppermann Message-Id: <20041021213248.223cab2c.molter@tin.it> In-Reply-To: <4177E25E.804639E@freebsd.org> References: <4177C8AD.6060706@freebsd.org> <20041021153933.GK13756@empiric.icir.org> <4177E25E.804639E@freebsd.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: bms@spc.org cc: freebsd-arch@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 19:34:24 -0000 On Thu, 21 Oct 2004 Andre Oppermann wrote: > Bruce M Simpson wrote: > > > > On Thu, Oct 21, 2004 at 04:33:17PM +0200, Andre Oppermann wrote: > > > Thus after the removal of T/TCP for the reasons above I want to > > > provide a work-alike replacement for T/TCP's functionality: > > > > I disagree. I think the time spent here would be better spent on > > working on an import of SCTP into the kernel, perhaps the KAME code > > base would be a good starting point. > > Is the SCTP in KAME complete and stable? Are there any other (open > source) implementations of it? SCTP in KAME is complete, stable and fully supported. It is mainly developed by the SCTP RFC author, Randall Stewart. A T/TCP alternative as you are describing sounds very similar to PR-SCTP (Partial Reliability SCTP). (Don't let the name fool you, please read the internet draft). There is at least another kernel-level open source implementation, for Linux, plus other user-level implementations. marco -- panic("The moon has moved again."); From owner-freebsd-arch@FreeBSD.ORG Thu Oct 21 19:42:12 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB4F916A4CE; Thu, 21 Oct 2004 19:42:12 +0000 (GMT) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FD9443D31; Thu, 21 Oct 2004 19:42:11 +0000 (GMT) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id i9LJflis052201; Thu, 21 Oct 2004 23:41:47 +0400 (MSD) (envelope-from is@rambler-co.ru) Date: Thu, 21 Oct 2004 23:41:47 +0400 (MSD) From: Igor Sysoev X-X-Sender: is@is.park.rambler.ru To: Sean Chittenden In-Reply-To: Message-ID: <20041021233447.L91215@is.park.rambler.ru> References: <4177C8AD.6060706@freebsd.org> <71C3A1EA-238F-11D9-9171-000A95C705DC@chittenden.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Andre Oppermann cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 19:42:13 -0000 On Thu, 21 Oct 2004, Sean Chittenden wrote: > >> In 2001, there was a push to make Linux's TCP_CORK option behave the > >> same as FreeBSD's TCP_NOPUSH. Is maintaining that compatibility still > >> a goal, or are we going to kick this change off to the Linux folk to > >> have them play catchup (to what sounds like a more secure option than > >> Linux's TCP_CORK)? > >> > >> http://seclists.org/linux-kernel/2001/Feb/0993.html > > > > I'm not sure if I can follow you here. TCP_CORK deals with the > > different > > behaviour of connections with Nagle vs. TCP_NODELAY. TCP_CORK allows > > to > > avoid the delays of Nagle by corking (sort of blocking) the sending of > > packets until you are done with write()ing to the socket. Then the > > connection is uncorked and all data will be sent in one go even if it > > doesn't fill an entire packet. Sort of an fsync() for sockets. There > > are no security implications with TCP_CORK as far as I am aware. > > Isn't that what NOPUSH does? Or is it that CORK uses a fully > established TCP connection, but blocks sending data until the > connection has been uncorked/flushed? I thought that TCP_CORK had the > same security implications that NOPUSH does (ie, the lack of a hand > shake). I think that TCP_CORK was implemented only for Linux's sendfile() to postpone the sending of the HTTP header: http://freebsd.rambler.ru/linux/kernel_1999/msg13796.html http://freebsd.rambler.ru/linux/kernel_2001/msg61910.html Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-arch@FreeBSD.ORG Fri Oct 22 01:47:01 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A308816A4CE; Fri, 22 Oct 2004 01:47:01 +0000 (GMT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 745D043D2D; Fri, 22 Oct 2004 01:47:01 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from h00609772adf0.ne.client2.attbi.com ([66.30.114.143]) by comcast.net (rwcrmhc12) with ESMTP id <20041022014700014004od4ue>; Fri, 22 Oct 2004 01:47:00 +0000 Received: from h00609772adf0.ne.client2.attbi.com (localhost [127.0.0.1]) i9M1l8Qx045714; Thu, 21 Oct 2004 21:47:12 -0400 (EDT) (envelope-from rodrigc@h00609772adf0.ne.client2.attbi.com) Received: (from rodrigc@localhost)i9M1l7Tu045713; Thu, 21 Oct 2004 21:47:07 -0400 (EDT) (envelope-from rodrigc) Date: Thu, 21 Oct 2004 21:47:07 -0400 From: Craig Rodrigues To: Marco Molteni Message-ID: <20041022014707.GA45582@crodrigues.org> References: <4177C8AD.6060706@freebsd.org> <20041021153933.GK13756@empiric.icir.org> <4177E25E.804639E@freebsd.org> <20041021213248.223cab2c.molter@tin.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041021213248.223cab2c.molter@tin.it> User-Agent: Mutt/1.4.1i cc: bms@spc.org cc: freebsd-net@freebsd.org cc: Andre Oppermann cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 01:47:01 -0000 On Thu, Oct 21, 2004 at 09:32:48PM +0200, Marco Molteni wrote: > SCTP in KAME is complete, stable and fully supported. > It is mainly developed by the SCTP RFC author, Randall Stewart. Randall has been maintaining his SCTP stack on FreeBSD 4.x, OpenBSD, and NetBSD. It has recently been ported to Darwin. > > A T/TCP alternative as you are describing sounds very > similar to PR-SCTP (Partial Reliability SCTP). (Don't let the > name fool you, please read the internet draft). Interesting stuff: http://www.portaroo.net/ietf/idref/draft-ietf-tsvwg-prsctp/ > > There is at least another kernel-level open source implementation, > for Linux, plus other user-level implementations. There is one kernel implementation of SCTP in the Linux 2.6 series of kernels ( http://lksctp.sourceforge.net ), and another kernel level implementation available separately ( http://www.openss7.org/sctp.html ). SCTP is an IETF standard, and a lot of people are getting interested in it. It would be nice to have it in FreeBSD, especially since it is showing up in the Linux distributions. The only issue with Randall's implementation is that it is only for 4.x.....I looked a while back at porting it to 5.x/CURRENT.... there is some work that needs to be done, i.e. using the new zone(9) API for allocating memory, and probably also getting the locking right. I don't know how much overlap there is with what Andre is going to implement, but I thought I would throw the information out there for those who may be interested. :) -- Craig Rodrigues http://crodrigues.org rodrigc@crodrigues.org From owner-freebsd-arch@FreeBSD.ORG Fri Oct 22 02:02:31 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12F7816A4CE; Fri, 22 Oct 2004 02:02:30 +0000 (GMT) Received: from quine.pinyon.org (quine.pinyon.org [65.101.5.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F76843D5A; Fri, 22 Oct 2004 02:02:29 +0000 (GMT) (envelope-from rcarter@pinyon.org) Received: by quine.pinyon.org (Postfix, from userid 1005) id 15AE961C8; Thu, 21 Oct 2004 19:02:29 -0700 (MST) Received: from feyerabend.hq.pinyon.org (feyerabend.hq.Pinyon.ORG [10.0.9.6]) by quine.pinyon.org (Postfix) with ESMTP id B233161C0; Thu, 21 Oct 2004 19:02:26 -0700 (MST) Received: from feyerabend.hq.pinyon.org (localhost [127.0.0.1]) by feyerabend.hq.pinyon.org (Postfix) with ESMTP id A8D34103A028; Thu, 21 Oct 2004 19:02:26 -0700 (MST) X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Craig Rodrigues In-Reply-To: Message from Craig Rodrigues <20041022014707.GA45582@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Oct 2004 19:02:26 -0700 From: "Russell L. Carter" Message-Id: <20041022020226.A8D34103A028@feyerabend.hq.pinyon.org> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on quine.pinyon.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Level: cc: Marco Molteni cc: freebsd-net@freebsd.org cc: Andre Oppermann cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 02:02:31 -0000 Greetings, It is not easy to get kame up and running, and I know this because I have. It is beyond all ordinary production installations. And as Craig notes it's not possible[1] in the 5* line yet. Maybe Randall would like to chip in on whether BSD SCTP is ready for prime time in FreeBSD. But do not underestimate the gains this protocol provides for fault tolerant server applications. Russell [1] It's been two months since I tried. : : On Thu, Oct 21, 2004 at 09:32:48PM +0200, Marco Molteni wrote: : > SCTP in KAME is complete, stable and fully supported. : > It is mainly developed by the SCTP RFC author, Randall Stewart. : : Randall has been maintaining his SCTP stack on FreeBSD 4.x, : OpenBSD, and NetBSD. It has recently been ported to Darwin. : : : > : > A T/TCP alternative as you are describing sounds very : > similar to PR-SCTP (Partial Reliability SCTP). (Don't let the : > name fool you, please read the internet draft). : : Interesting stuff: : http://www.portaroo.net/ietf/idref/draft-ietf-tsvwg-prsctp/ : : > : > There is at least another kernel-level open source implementation, : > for Linux, plus other user-level implementations. : : There is one kernel implementation of SCTP in : the Linux 2.6 series of kernels ( http://lksctp.sourceforge.net ), : and another kernel level implementation available separately : ( http://www.openss7.org/sctp.html ). : : SCTP is an IETF standard, and a lot of people are getting interested : in it. It would be nice to have it in FreeBSD, especially since : it is showing up in the Linux distributions. : : The only issue with Randall's implementation is that : it is only for 4.x.....I looked a while back at porting it to 5.x/CURRENT.... : there is some work that needs to be done, i.e. using : the new zone(9) API for allocating memory, and probably also : getting the locking right. : : I don't know how much overlap there is with what Andre is going to : implement, but I thought I would throw the information out there : for those who may be interested. :) : : -- : Craig Rodrigues : http://crodrigues.org : rodrigc@crodrigues.org : _______________________________________________ : freebsd-net@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-net : To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Fri Oct 22 03:25:03 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69F7916A4CE for ; Fri, 22 Oct 2004 03:25:03 +0000 (GMT) Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0854643D46 for ; Fri, 22 Oct 2004 03:25:03 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [192.168.1.102] (adsl-68-123-122-146.dsl.snfc21.pacbell.net [68.123.122.146])i9M3OwxQ296002; Thu, 21 Oct 2004 23:24:58 -0400 Message-ID: <41787D89.3060906@elischer.org> Date: Thu, 21 Oct 2004 20:24:57 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8a3) Gecko/20041017 X-Accept-Language: en, hu MIME-Version: 1.0 To: Craig Rodrigues References: <4177C8AD.6060706@freebsd.org> <20041021153933.GK13756@empiric.icir.org> <4177E25E.804639E@freebsd.org> <20041021213248.223cab2c.molter@tin.it> <20041022014707.GA45582@crodrigues.org> In-Reply-To: <20041022014707.GA45582@crodrigues.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Marco Molteni cc: bms@spc.org cc: freebsd-arch@freebsd.org cc: Andre Oppermann cc: freebsd-net@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 03:25:03 -0000 Craig Rodrigues wrote: > On Thu, Oct 21, 2004 at 09:32:48PM +0200, Marco Molteni wrote: >>A T/TCP alternative as you are describing sounds very >>similar to PR-SCTP (Partial Reliability SCTP). (Don't let the >>name fool you, please read the internet draft). > > > Interesting stuff: > http://www.portaroo.net/ietf/idref/draft-ietf-tsvwg-prsctp/ that's potaroo > > From owner-freebsd-arch@FreeBSD.ORG Fri Oct 22 07:48:01 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7830D16A4CE; Fri, 22 Oct 2004 07:48:01 +0000 (GMT) Received: from v6.hitachi.co.jp (galilei.v6.hitachi.co.jp [133.145.167.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C2D743D46; Fri, 22 Oct 2004 07:48:00 +0000 (GMT) (envelope-from suz@crl.hitachi.co.jp) Received: from flora210w.uki-uki.net (localhost [IPv6:::1]) by v6.hitachi.co.jp (8.12.11/8.12.11) with ESMTP id i9M6gRRt061248; Fri, 22 Oct 2004 15:42:29 +0900 (JST) (envelope-from suz@crl.hitachi.co.jp) Date: Fri, 22 Oct 2004 15:42:18 +0900 Message-ID: From: SUZUKI Shinsuke To: molter@tin.it X-cite: xcite 1.33 In-Reply-To: <20041021213248.223cab2c.molter@tin.it> References: <4177C8AD.6060706@freebsd.org> <20041021153933.GK13756@empiric.icir.org> <4177E25E.804639E@freebsd.org> <20041021213248.223cab2c.molter@tin.it> User-Agent: Wanderlust/2.11.32 (Wonderwall) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Network Systems Research Dept., Central Research Laboratory, Hitachi, Ltd, Japan MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII cc: freebsd-net@freebsd.org cc: andre@freebsd.org cc: freebsd-arch@freebsd.org Subject: SCTP in KAME / Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 07:48:01 -0000 >>>>> On Thu, 21 Oct 2004 21:32:48 +0200 >>>>> molter@tin.it(Marco Molteni) said: > SCTP in KAME is complete, stable and fully supported. > It is mainly developed by the SCTP RFC author, Randall Stewart. KAME Project haven't received SCTP-related bug report so much, and I think it's due to a lack of testers, SCTP-API standard, and SCTP-ready applications. #Sometimes KAME SNAP compilation fails in SCTP and non-SCTP #application fails in compilation due to a change by SCTP. So it's #difficult to conclude that SCTP is already stable... So I'm not still sure if SCTP in KAME is complete and stable enough to merge into -current. (If someone can contribute to this kind of evaluation, it's quite appreciated, of course!) Thanks, ---- SUZUKI, Shinsuke @ KAME Project From owner-freebsd-arch@FreeBSD.ORG Fri Oct 22 11:58:26 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E4BB16A4D0; Fri, 22 Oct 2004 11:58:26 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 861E743D41; Fri, 22 Oct 2004 11:58:25 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 384EB5311; Fri, 22 Oct 2004 13:58:24 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id EEB745310; Fri, 22 Oct 2004 13:58:16 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id 77F7AB861; Fri, 22 Oct 2004 13:58:16 +0200 (CEST) To: Andre Oppermann References: <4177C8AD.6060706@freebsd.org> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Fri, 22 Oct 2004 13:58:16 +0200 In-Reply-To: <4177C8AD.6060706@freebsd.org> (Andre Oppermann's message of "Thu, 21 Oct 2004 16:33:17 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.64 cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 11:58:26 -0000 Andre Oppermann writes: > o T/TCP only available on FreeBSD. No other Operating System or TCP/IP > stack implements it to my knowledge. Certainly no OS that is common. AFAIK, both Linux and Windows support it, at least on the server side (i.e. they can receive T/TCP connections even if they can't initiate them). > o T/TCP requires different API calls than TCP to use it (UDP like). Only on the client side, I believe. > o T/TCP is not supported by any common network application. Prior to libfetch, fetch(1) used it by default. > Thus after the removal of T/TCP for the reasons above I want to provide > a work-alike replacement for T/TCP's functionality: Unlike your proposal, T/TCP is described in Internet RFCs (1379 and 1644) and well-known by the Internet community. > If you haven't read and/or unstood the link above or TCP/IP Illustrated > Volume 3 then please refrain from participating in this discussion! Nice. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Fri Oct 22 12:47:38 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 767CF16A4CE; Fri, 22 Oct 2004 12:47:38 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 394DF43D1F; Fri, 22 Oct 2004 12:47:38 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 2F6385311; Fri, 22 Oct 2004 14:47:37 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 8EC5C5310; Fri, 22 Oct 2004 14:47:30 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id 3E816B861; Fri, 22 Oct 2004 14:47:30 +0200 (CEST) To: Andre Oppermann References: <4177C8AD.6060706@freebsd.org> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Fri, 22 Oct 2004 14:47:30 +0200 In-Reply-To: (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav's?= message of "Fri, 22 Oct 2004 13:58:16 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.64 cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 12:47:38 -0000 des@des.no (Dag-Erling Sm=F8rgrav) writes: > [...] I should add: I'm not against removing T/TCP support (especially if it helps simplify our network stack), but I don't see the point in replacing it with some homebrew protocol that noone else supports. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Fri Oct 22 15:14:09 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D09916A4CE for ; Fri, 22 Oct 2004 15:14:09 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A40E943D5F for ; Fri, 22 Oct 2004 15:14:08 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 87291 invoked from network); 22 Oct 2004 15:12:34 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 22 Oct 2004 15:12:34 -0000 Message-ID: <417923BF.661D2A6D@freebsd.org> Date: Fri, 22 Oct 2004 17:14:07 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Chittenden References: <4177C8AD.6060706@freebsd.org> <71C3A1EA-238F-11D9-9171-000A95C705DC@chittenden.org> <41780672.6AAC705F@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 15:14:09 -0000 Sean Chittenden wrote: > > >>> However something like T/TCP is certainly useful and I know of one > >>> special > >>> purpose application using it (Web Proxy Server/Client for high-delay > >>> Satellite > >>> connections). > >> > >> Actually, there are two/three programs that I know of that use it. > >> memcached(1), which found a fantastic decrease in its benchmarks. > >> Here's an excerpt from the following link: > >> > >> http://lists.danga.com/pipermail/memcached/2003-August/000111.html > > > > I think you got something wrong here. T/TCP is never ever mentioned > > in this. Memcached is not using T/TCP as far as I can see. > > It's not, but I thought setsockopt(2) w/ TCP_NOPUSH enabled the use of > T/TCP in that there was no 3WHS performed on a TCP_NOPUSH'ed > connection. No, it is not. T/TCP will only be used if you use sendto(), have T/TCP globally enabled on the machine and the server supports it too. TCP_NOPUSH was introduced together with or some time after T/TCP to change the behaviour how tcp_output() pushes non-full packets on the wire. It pretty closely related to the same purpose as TCP_CORK. > >> and an internal reverse proxy server/modified apache that I've hacked > >> together (reduces latency in a tiered request hierarchy a great deal, > >> on order of the benchmarks from above). > > > > What syscall do you use to get to the other side in your reverse proxy? > > On the client, sendto()/read(). On the server, setsockopt() + write(). Ok, then you are indeed using T/TCP (provided you have enabled it on both machines). The setsockopt() optimizes packet sending on the server but otherwise doesn't have anything to do with T/TCP. > > I'm not sure if I can follow you here. TCP_CORK deals with the > > different > > behaviour of connections with Nagle vs. TCP_NODELAY. TCP_CORK allows > > to > > avoid the delays of Nagle by corking (sort of blocking) the sending of > > packets until you are done with write()ing to the socket. Then the > > connection is uncorked and all data will be sent in one go even if it > > doesn't fill an entire packet. Sort of an fsync() for sockets. There > > are no security implications with TCP_CORK as far as I am aware. > > Isn't that what NOPUSH does? Or is it that CORK uses a fully > established TCP connection, but blocks sending data until the > connection has been uncorked/flushed? I thought that TCP_CORK had the > same security implications that NOPUSH does (ie, the lack of a hand > shake). None of it. Neither NOPUSH nor CORK have any security implications. Those are only with the specification of T/TCP. Blocking the data is independend of 3WSH. Normally you have Nagle enabled (default) and when you don't fill an entire packet worth of data it will wait up to 200ms to send the packet in anticipation of more data from the socket. This screws the responsiveness of your connection. The first solution is to turn off Nagle (with TCP_NODELAY) but now you get a packet for every single write() you do. Fine for telnet and ssh but not the right thing for a database server. There you don't want the delay but at the same time you want several successive write()s that will go in one packet on the wire. Here NOPUSH and CORK come into play. > I was under the impression that by default NOPUSH would prevent a > connect() until there was a full packet to be sent or the socket had > been closed/flushed. The first/only packet from the client to the > server would contain a SIN+PUSH+FIN + the data for the request, then > the server would come back with a SIN+PUSH+FIN+ACK. Essentially UDP, > but with checksums and packet retransmission built in. More or less correct. However the SYN+FIN+Data is caused by T/TCP and not NOPUSH. NOPUSH is used as an optimization as I have described above usually on the server side. -- Andre From owner-freebsd-arch@FreeBSD.ORG Fri Oct 22 15:15:01 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B036616A4D0 for ; Fri, 22 Oct 2004 15:15:01 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B48EE43D45 for ; Fri, 22 Oct 2004 15:15:00 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 87301 invoked from network); 22 Oct 2004 15:13:27 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 22 Oct 2004 15:13:27 -0000 Message-ID: <417923F3.898EDBC8@freebsd.org> Date: Fri, 22 Oct 2004 17:14:59 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Marco Molteni References: <4177C8AD.6060706@freebsd.org> <20041021153933.GK13756@empiric.icir.org> <20041021213248.223cab2c.molter@tin.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: bms@spc.org cc: freebsd-arch@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 15:15:01 -0000 Marco Molteni wrote: > > On Thu, 21 Oct 2004 Andre Oppermann wrote: > > > Bruce M Simpson wrote: > > > > > > On Thu, Oct 21, 2004 at 04:33:17PM +0200, Andre Oppermann wrote: > > > > Thus after the removal of T/TCP for the reasons above I want to > > > > provide a work-alike replacement for T/TCP's functionality: > > > > > > I disagree. I think the time spent here would be better spent on > > > working on an import of SCTP into the kernel, perhaps the KAME code > > > base would be a good starting point. > > > > Is the SCTP in KAME complete and stable? Are there any other (open > > source) implementations of it? > > SCTP in KAME is complete, stable and fully supported. > It is mainly developed by the SCTP RFC author, Randall Stewart. > > A T/TCP alternative as you are describing sounds very > similar to PR-SCTP (Partial Reliability SCTP). (Don't let the > name fool you, please read the internet draft). Yes, but it depends on SCTP and we don't have SCTP in the kernel any time soon. -- Andre From owner-freebsd-arch@FreeBSD.ORG Fri Oct 22 15:23:06 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93DEF16A4D3 for ; Fri, 22 Oct 2004 15:23:06 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6FD843D46 for ; Fri, 22 Oct 2004 15:23:05 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 87400 invoked from network); 22 Oct 2004 15:21:31 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 22 Oct 2004 15:21:31 -0000 Message-ID: <417925D8.C426261E@freebsd.org> Date: Fri, 22 Oct 2004 17:23:04 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= References: <4177C8AD.6060706@freebsd.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 15:23:06 -0000 Dag-Erling Smørgrav wrote: > > Andre Oppermann writes: > > o T/TCP only available on FreeBSD. No other Operating System or TCP/IP > > stack implements it to my knowledge. Certainly no OS that is common. > > AFAIK, both Linux and Windows support it, at least on the server side > (i.e. they can receive T/TCP connections even if they can't initiate > them). Any fully TCP compliant stack should be able to accept T/TCP connection attempts. However if it didn't implement T/TCP itself it would simply do the standard 3WSH. So yes, you can use T/TCP from the client side towards any TCP server but you don't get any benefit from it. Neither Windows or Linux implement it. Windows during the NT4 days had a bug in the TCP stack that allowed something like T/TCP but it wasn't T/TCP and didn't work with T/TCP compliant clients. > > o T/TCP requires different API calls than TCP to use it (UDP like). > > Only on the client side, I believe. Yes, on the client side. sendto() instead of connect()+write(). > > o T/TCP is not supported by any common network application. > > Prior to libfetch, fetch(1) used it by default. Only if T/TCP was enabled on the machine (net.inet.tcp.rfc1644). > > Thus after the removal of T/TCP for the reasons above I want to provide > > a work-alike replacement for T/TCP's functionality: > > Unlike your proposal, T/TCP is described in Internet RFCs (1379 and > 1644) and well-known by the Internet community. Well known for its gaping security holes and left unimplemented on any other OS except FreeBSD. -- Andre From owner-freebsd-arch@FreeBSD.ORG Fri Oct 22 15:45:19 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id D8F7516A4CE; Fri, 22 Oct 2004 15:45:18 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id i9MFjIFg094553; Fri, 22 Oct 2004 11:45:18 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id i9MFjHYG094552; Fri, 22 Oct 2004 11:45:17 -0400 (EDT) (envelope-from green) Date: Fri, 22 Oct 2004 11:45:17 -0400 From: Brian Fundakowski Feldman To: Andre Oppermann Message-ID: <20041022154517.GN1072@green.homeunix.org> References: <4177C8AD.6060706@freebsd.org> <71C3A1EA-238F-11D9-9171-000A95C705DC@chittenden.org> <41780672.6AAC705F@freebsd.org> <417923BF.661D2A6D@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <417923BF.661D2A6D@freebsd.org> User-Agent: Mutt/1.5.6i cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 15:45:19 -0000 On Fri, Oct 22, 2004 at 05:14:07PM +0200, Andre Oppermann wrote: > Sean Chittenden wrote: > > > > >>> However something like T/TCP is certainly useful and I know of one > > >>> special > > >>> purpose application using it (Web Proxy Server/Client for high-delay > > >>> Satellite > > >>> connections). > > >> > > >> Actually, there are two/three programs that I know of that use it. > > >> memcached(1), which found a fantastic decrease in its benchmarks. > > >> Here's an excerpt from the following link: > > >> > > >> http://lists.danga.com/pipermail/memcached/2003-August/000111.html > > > > > > I think you got something wrong here. T/TCP is never ever mentioned > > > in this. Memcached is not using T/TCP as far as I can see. > > > > It's not, but I thought setsockopt(2) w/ TCP_NOPUSH enabled the use of > > T/TCP in that there was no 3WHS performed on a TCP_NOPUSH'ed > > connection. > > No, it is not. T/TCP will only be used if you use sendto(), have T/TCP > globally enabled on the machine and the server supports it too. > > TCP_NOPUSH was introduced together with or some time after T/TCP to > change the behaviour how tcp_output() pushes non-full packets on the > wire. It pretty closely related to the same purpose as TCP_CORK. > > > >> and an internal reverse proxy server/modified apache that I've hacked > > >> together (reduces latency in a tiered request hierarchy a great deal, > > >> on order of the benchmarks from above). > > > > > > What syscall do you use to get to the other side in your reverse proxy? > > > > On the client, sendto()/read(). On the server, setsockopt() + write(). > > Ok, then you are indeed using T/TCP (provided you have enabled it on > both machines). The setsockopt() optimizes packet sending on the server > but otherwise doesn't have anything to do with T/TCP. > > > > I'm not sure if I can follow you here. TCP_CORK deals with the > > > different > > > behaviour of connections with Nagle vs. TCP_NODELAY. TCP_CORK allows > > > to > > > avoid the delays of Nagle by corking (sort of blocking) the sending of > > > packets until you are done with write()ing to the socket. Then the > > > connection is uncorked and all data will be sent in one go even if it > > > doesn't fill an entire packet. Sort of an fsync() for sockets. There > > > are no security implications with TCP_CORK as far as I am aware. > > > > Isn't that what NOPUSH does? Or is it that CORK uses a fully > > established TCP connection, but blocks sending data until the > > connection has been uncorked/flushed? I thought that TCP_CORK had the > > same security implications that NOPUSH does (ie, the lack of a hand > > shake). > > None of it. Neither NOPUSH nor CORK have any security implications. > Those are only with the specification of T/TCP. Blocking the data > is independend of 3WSH. Normally you have Nagle enabled (default) > and when you don't fill an entire packet worth of data it will wait > up to 200ms to send the packet in anticipation of more data from the > socket. This screws the responsiveness of your connection. The first > solution is to turn off Nagle (with TCP_NODELAY) but now you get a > packet for every single write() you do. Fine for telnet and ssh but > not the right thing for a database server. There you don't want the > delay but at the same time you want several successive write()s that > will go in one packet on the wire. Here NOPUSH and CORK come into > play. Why is just tuning the delay a bad solution? -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-arch@FreeBSD.ORG Fri Oct 22 15:55:47 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAA5C16A4CE for ; Fri, 22 Oct 2004 15:55:47 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F23743D1F for ; Fri, 22 Oct 2004 15:55:47 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 87684 invoked from network); 22 Oct 2004 15:54:12 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 22 Oct 2004 15:54:12 -0000 Message-ID: <41792D81.C030A26F@freebsd.org> Date: Fri, 22 Oct 2004 17:55:45 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian Fundakowski Feldman References: <4177C8AD.6060706@freebsd.org> <71C3A1EA-238F-11D9-9171-000A95C705DC@chittenden.org> <41780672.6AAC705F@freebsd.org> <417923BF.661D2A6D@freebsd.org> <20041022154517.GN1072@green.homeunix.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 15:55:47 -0000 Brian Fundakowski Feldman wrote: > > On Fri, Oct 22, 2004 at 05:14:07PM +0200, Andre Oppermann wrote: > > None of it. Neither NOPUSH nor CORK have any security implications. > > Those are only with the specification of T/TCP. Blocking the data > > is independend of 3WSH. Normally you have Nagle enabled (default) > > and when you don't fill an entire packet worth of data it will wait > > up to 200ms to send the packet in anticipation of more data from the > > socket. This screws the responsiveness of your connection. The first > > solution is to turn off Nagle (with TCP_NODELAY) but now you get a > > packet for every single write() you do. Fine for telnet and ssh but > > not the right thing for a database server. There you don't want the > > delay but at the same time you want several successive write()s that > > will go in one packet on the wire. Here NOPUSH and CORK come into > > play. > > Why is just tuning the delay a bad solution? If you tune it too low it ain't useful anymore (doesn't gather distant writes together) and too many timers too often. -- Andre From owner-freebsd-arch@FreeBSD.ORG Fri Oct 22 18:24:32 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F2E7316A4CE; Fri, 22 Oct 2004 18:24:31 +0000 (GMT) Received: from wyvern.icir.org (wyvern.icir.org [192.150.187.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 887B443D2F; Fri, 22 Oct 2004 18:24:31 +0000 (GMT) (envelope-from mallman@icir.org) Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id i9MIOUag009286; Fri, 22 Oct 2004 11:24:31 -0700 (PDT) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (guns.icir.org [68.76.113.50]) by guns.icir.org (Postfix) with ESMTP id A613777AF4A; Fri, 22 Oct 2004 14:24:30 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 31A2B1EF3BF; Fri, 22 Oct 2004 14:24:30 -0400 (EDT) To: Marco Molteni From: Mark Allman In-Reply-To: <20041021213248.223cab2c.molter@tin.it> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Glycerine MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 22 Oct 2004 14:24:30 -0400 Sender: mallman@icir.org Message-Id: <20041022182430.31A2B1EF3BF@lawyers.icir.org> cc: freebsd-net@freebsd.org cc: Andre Oppermann cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: mallman@icir.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 18:24:32 -0000 --=-=-= Content-Type: text/plain > A T/TCP alternative as you are describing sounds very > similar to PR-SCTP (Partial Reliability SCTP). (Don't let the > name fool you, please read the internet draft). Can you sketch this in a bit more detail? I do not follow. PR-SCTP is about being allowed to "abandon" data --- i.e., send it and then decide that you don't really care if it gets across the network (say, because it got lost and has taken too long to retransmit and so the data is out of date). Without a Big Hack, I cannot envision TCP doing something like this. What am I missing? Thanks, allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) iD8DBQFBeVBeWyrrWs4yIs4RApwcAJ9VDoEaO7SpKK/ty0NUlZi+qM3vawCeNhJB lbLVyoW0++t6W8U7lRavcH4= =yp18 -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-arch@FreeBSD.ORG Fri Oct 22 21:42:51 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1F9416A4CE for ; Fri, 22 Oct 2004 21:42:51 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 271AD43D2F for ; Fri, 22 Oct 2004 21:42:51 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id i9MLgmpT059921 for ; Fri, 22 Oct 2004 23:42:49 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org From: Poul-Henning Kamp Date: Fri, 22 Oct 2004 23:42:48 +0200 Message-ID: <59920.1098481368@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: REVIEW: handling kldload/kldunload of GEOM classes properly. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 21:42:51 -0000 There are a number of system calls which starts events running in GEOM and which for consistency should not return to userland until those events have completed and GEOM has settled down. The typical example would be a shell-script doing: kldload md mdconfig bla bla Examples of such syscalls are: open(2) & close(2): can cause spoils and retastes mount(2)/umount(2): acts as open/close. (any other syscall doing a VOP_OPEN/VOP_CLOSE on a diskdevice.) ioctl(2): directed configuration can do almost anything. kldload(2)/kldunload(2): can load/unload GEOm classes. The last one is the most tricky one: The crude solution is to always wait for geom to settle before returning to userland from kldload(2), but there is no point in waiting for GEOM if you loaded a USB serial driver and doing so would increase the risk of cascade failures. A further complication is that we should not wait for geom to settle until after we have dropped Giant again because the geom events might need to grab giant to do their job. The cleanest way to solve this once and for all is to add a thread private flag bit, set it on curthread whenever a GEOM event is posted, and check that geom has cleaned all events before that thread is allowed to return to userland. (I properly can be persuaded that the sleep should be interruptible). That strategy implements the semantics which POLA would suggest "Return when you have done all you know you need to do". It does not address the issue where a scsi driver needs "camcontrol rescan" to actually look for its disks or where the disk arrives later when it is plugged in, but it does not return to userland while we know we are only half finished. Doing it with a thread private flag costs us one bit check in the syscall return-path, and normally that would have ruled it right out for me. After looking at all the gunk we have there, and spotting at least two opportunities for microoptimizations which will offset this extra test, I decided that the cost was less than epsilon. Patch attached, comments requested. A number of g_waitidle() calls can subsequently be removed, but didn't want to clutter the patch with that. Poul-Henning Index: sys/proc.h =================================================================== RCS file: /home/ncvs/src/sys/sys/proc.h,v retrieving revision 1.410 diff -u -r1.410 proc.h --- sys/proc.h 16 Oct 2004 06:38:21 -0000 1.410 +++ sys/proc.h 22 Oct 2004 21:19:26 -0000 @@ -375,6 +375,7 @@ #define TDP_SCHED2 0x00002000 /* Reserved for scheduler private use */ #define TDP_SCHED3 0x00004000 /* Reserved for scheduler private use */ #define TDP_SCHED4 0x00008000 /* Reserved for scheduler private use */ +#define TDP_GEOM 0x00010000 /* Settle GEOM before finishing syscall */ /* * Reasons that the current thread can not be run yet. Index: sys/systm.h =================================================================== RCS file: /home/ncvs/src/sys/sys/systm.h,v retrieving revision 1.215 diff -u -r1.215 systm.h --- sys/systm.h 30 Sep 2004 07:04:03 -0000 1.215 +++ sys/systm.h 22 Oct 2004 21:22:12 -0000 @@ -127,6 +127,7 @@ void hashdestroy(void *, struct malloc_type *, u_long); void *hashinit(int count, struct malloc_type *type, u_long *hashmask); void *phashinit(int count, struct malloc_type *type, u_long *nentries); +void g_waitidle(void); #ifdef RESTARTABLE_PANICS void panic(const char *, ...) __printflike(1, 2); Index: geom/geom.h =================================================================== RCS file: /home/ncvs/src/sys/geom/geom.h,v retrieving revision 1.85 diff -u -r1.85 geom.h --- geom/geom.h 27 Aug 2004 14:43:11 -0000 1.85 +++ geom/geom.h 22 Oct 2004 21:22:42 -0000 @@ -213,7 +213,6 @@ int g_waitfor_event(g_event_t *func, void *arg, int flag, ...); void g_cancel_event(void *ref); void g_orphan_provider(struct g_provider *pp, int error); -void g_waitidle(void); /* geom_subr.c */ int g_access(struct g_consumer *cp, int nread, int nwrite, int nexcl); Index: geom/geom_event.c =================================================================== RCS file: /home/ncvs/src/sys/geom/geom_event.c,v retrieving revision 1.50 diff -u -r1.50 geom_event.c --- geom/geom_event.c 8 Jul 2004 16:17:14 -0000 1.50 +++ geom/geom_event.c 22 Oct 2004 21:19:45 -0000 @@ -47,12 +47,14 @@ #include #include #include -#include +#include #include #include #include #include +#include + TAILQ_HEAD(event_tailq_head, g_event); static struct event_tailq_head g_events = TAILQ_HEAD_INITIALIZER(g_events); @@ -279,6 +281,7 @@ wakeup(&g_wait_event); if (epp != NULL) *epp = ep; + curthread->td_pflags |= TDP_GEOM; return (0); } Index: kern/subr_trap.c =================================================================== RCS file: /home/ncvs/src/sys/kern/subr_trap.c,v retrieving revision 1.275 diff -u -r1.275 subr_trap.c --- kern/subr_trap.c 5 Oct 2004 18:51:11 -0000 1.275 +++ kern/subr_trap.c 22 Oct 2004 21:39:40 -0000 @@ -95,6 +95,15 @@ #endif /* + * If this thread tickled GEOM, we need to wait for the giggling to + * stop before we return to userland + */ + if (td->td_pflags & TDP_GEOM) { + td->td_pflags &= ~TDP_GEOM; + g_waitidle(); + } + + /* * Let the scheduler adjust our priority etc. */ sched_userret(td); From owner-freebsd-arch@FreeBSD.ORG Sat Oct 23 00:59:39 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2106C16A4CE; Sat, 23 Oct 2004 00:59:39 +0000 (GMT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86D1943D4C; Sat, 23 Oct 2004 00:59:38 +0000 (GMT) (envelope-from peter.lei@ieee.org) Received: from [10.10.0.75] (c-24-13-174-21.client.comcast.net[24.13.174.21]) by comcast.net (sccrmhc13) with ESMTP id <20041023005905016001r5jje> (Authid: peterlei); Sat, 23 Oct 2004 00:59:29 +0000 Message-ID: <4179ACB8.4020108@ieee.org> Date: Fri, 22 Oct 2004 19:58:32 -0500 From: Peter Lei User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SUZUKI Shinsuke References: <4177C8AD.6060706@freebsd.org> <20041021153933.GK13756@empiric.icir.org> <4177E25E.804639E@freebsd.org> <20041021213248.223cab2c.molter@tin.it> In-Reply-To: X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010006070805020405040504" cc: molter@tin.it cc: freebsd-net@freebsd.org cc: Randall Stewart cc: andre@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: SCTP in KAME / Re: Removing T/TCP and replacing it withsomething simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2004 00:59:39 -0000 This is a cryptographically signed message in MIME format. --------------ms010006070805020405040504 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I think this is because any bugs that are found are usually communicated directly to us. I think Randy has a better handle on how many people are using this stack. I'm quite sure it is stable enough to go in to -current. While the SCTP API hasn't gone through last call, it's fairly stable and we have both "converted" many applications from TCP to SCTP using the sockets API, as well as had portability between the KAME SCTP stack and the linux stack for some test applications used at the last interop event (except for the standard sockets issues that one runs into even for TCP like no sin_length field in the sockaddr struct). The same stack has also been ported to Mac OSX as a native kernel build as well as an loadable/unloadble NKE w/a minor kernel change. I'm not aware of any KAME SNAP compilation failures w/and w/o SCTP. The major changes to our SCTP code when it gets committed into KAME has been that of code format/style. What is the existing criteria for a measure of "stability"? regards, --peter SUZUKI Shinsuke wrote: >>>>>>On Thu, 21 Oct 2004 21:32:48 +0200 >>>>>>molter@tin.it(Marco Molteni) said: > > >>SCTP in KAME is complete, stable and fully supported. >>It is mainly developed by the SCTP RFC author, Randall Stewart. > > > KAME Project haven't received SCTP-related bug report so much, and I > think it's due to a lack of testers, SCTP-API standard, and SCTP-ready > applications. > #Sometimes KAME SNAP compilation fails in SCTP and non-SCTP > #application fails in compilation due to a change by SCTP. So it's > #difficult to conclude that SCTP is already stable... > > So I'm not still sure if SCTP in KAME is complete and stable enough to > merge into -current. (If someone can contribute to this kind of > evaluation, it's quite appreciated, of course!) > > Thanks, > ---- > SUZUKI, Shinsuke @ KAME Project > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > --------------ms010006070805020405040504 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII7TCC AtEwggI6oAMCAQICAwvwrTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwMzE3MjE1NjMzWhcNMDUwMzE3MjE1NjMz WjBEMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSEwHwYJKoZIhvcNAQkBFhJw ZXRlci5sZWlAaWVlZS5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDX4PR3 QP+rgEBZtv1Q4YhKjRXUZQSk+9xNzesbK7pyirmUxKnm209ZGibDUAb/yC0ghvl3GbvNv/72 cyfC7JVjiABrDxY19L9mRGLKzjlK/bgBPY8SIu4blM/RtyabN4CdYk24LoGPHuLLkJIvvvQR LG0IJIfP8zvoHy0UGzyXOM/S4msxF1zDpBu7lYMe4Dpu5O9uaE2j1G/jswVmO2KMyQmffOGx 0Mw18tiGNMWkjMAwSJnXO2VSHzvh+I3OM71ReFo9ET2TtiXzqdDM5z0/LTsIyy1vP4Ib3Co9 xZNTe6JqVk2BsH7EZKPxi+oD7f/HctNWTZk0sesgba7D97jLAgMBAAGjLzAtMB0GA1UdEQQW MBSBEnBldGVyLmxlaUBpZWVlLm9yZzAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB AB86WuVOs/pHjC4SPdbKb+obiQZVqR813FD3JcW+stkaZQHTPHoln/SYRd3TZcZIXageyme6 f5Gl3lOsamSUrtkov5u6B0vvtuDuMQH7deh1ARTQfC+R3hv29vVQ+uSPlLo/AGWaPcW030NW Bp96xBIESmHBMWGuYWkxMDHII/R+MIIC0TCCAjqgAwIBAgIDC/CtMA0GCSqGSIb3DQEBBAUA MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNDAz MTcyMTU2MzNaFw0wNTAzMTcyMTU2MzNaMEQxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBN ZW1iZXIxITAfBgkqhkiG9w0BCQEWEnBldGVyLmxlaUBpZWVlLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBANfg9HdA/6uAQFm2/VDhiEqNFdRlBKT73E3N6xsrunKKuZTE qebbT1kaJsNQBv/ILSCG+XcZu82//vZzJ8LslWOIAGsPFjX0v2ZEYsrOOUr9uAE9jxIi7huU z9G3Jps3gJ1iTbgugY8e4suQki++9BEsbQgkh8/zO+gfLRQbPJc4z9LiazEXXMOkG7uVgx7g Om7k725oTaPUb+OzBWY7YozJCZ984bHQzDXy2IY0xaSMwDBImdc7ZVIfO+H4jc4zvVF4Wj0R PZO2JfOp0MznPT8tOwjLLW8/ghvcKj3Fk1N7ompWTYGwfsRko/GL6gPt/8dy01ZNmTSx6yBt rsP3uMsCAwEAAaMvMC0wHQYDVR0RBBYwFIEScGV0ZXIubGVpQGllZWUub3JnMAwGA1UdEwEB /wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAHzpa5U6z+keMLhI91spv6huJBlWpHzXcUPclxb6y 2RplAdM8eiWf9JhF3dNlxkhdqB7KZ7p/kaXeU6xqZJSu2Si/m7oHS++24O4xAft16HUBFNB8 L5HeG/b29VD65I+Uuj8AZZo9xbTfQ1YGn3rEEgRKYcExYa5haTEwMcgj9H4wggM/MIICqKAD AgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZy ZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoG A1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHy v1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsY Pge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0T AQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20v VGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQe MBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD 6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZ GwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC 3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0ECAwvwrTAJBgUrDgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDEwMjMwMDU4MzJaMCMGCSqGSIb3DQEJ BDEWBBRrk39gpoOpWqYdY1tVvISJ5jw1uzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg SXNzdWluZyBDQQIDC/CtMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwvwrTANBgkqhkiG9w0BAQEFAASCAQA3fGlS sskhvbOgczo64RIPkpGP/te8inW9boQ3wlQf6O7hRV/6ooAfpRxdfBEo4TR4/SnMuY9ExN3N 3MpC6TBk0PPs+KEhVY81I8AYRgxcRbswHvZKrgnTWwuw2jArld+sY/mwdiWQUcfn5ALkR5Wl i/TqEN5J0bvK4tlBUxhWjf3OD+oG90qlJ73VCdPI4r3AbAQC82ECQCy48LsdRs+SZVpwbn0k JeGivu8inV76Rvbq6yAHOFm+ADzEpogpDV1QFKlWmafRhdIpKxrqn1mRAREdwKGo4D2RizyI zpNpY6glpC86jck8MGp2b021TV9Je/VT4UyaPmWaTf/sM0pRAAAAAAAA --------------ms010006070805020405040504-- From owner-freebsd-arch@FreeBSD.ORG Sat Oct 23 13:07:34 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D6B5B16A4CE; Sat, 23 Oct 2004 13:07:34 +0000 (GMT) Received: from stewart.chicago.il.us (dpc674425142.direcpc.com [67.44.25.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CA1543D5D; Sat, 23 Oct 2004 13:07:32 +0000 (GMT) (envelope-from randall@stewart.chicago.il.us) Received: from stewart.chicago.il.us (localhost [127.0.0.1]) i9ND71tr031391; Sat, 23 Oct 2004 09:07:04 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <417A572A.9080306@stewart.chicago.il.us> Date: Sat, 23 Oct 2004 09:05:46 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Lei References: <4177C8AD.6060706@freebsd.org> <20041021153933.GK13756@empiric.icir.org> <4177E25E.804639E@freebsd.org> <20041021213248.223cab2c.molter@tin.it> <4179ACB8.4020108@ieee.org> In-Reply-To: <4179ACB8.4020108@ieee.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: molter@tin.it cc: freebsd-net@freebsd.org cc: SUZUKI Shinsuke cc: andre@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: SCTP in KAME / Re: Removing T/TCP and replacing it withsomething simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2004 13:07:35 -0000 Peter: Yes, I do get all the bugs reported to me (usually) directly.. And I try to turn them around within a week (if possible)... I have a couple on my plate right now from Chiba Hirotsugu ... in fact the last batch of bugs was also from Chiba... I know of at least 4 sites actively using the code and reporting bugs and issues Marko, Chiba, The U-D guys (there are about 4 different projects at U-D and a LOT of folks in the PEL lab so I won't try to name them all), Alessio (performance tests I think), Jian Wang (doing some cwnd type testing)... and there are others that have reported bugs... in fact some have even pulled it into their products (QNX I think).. they of course are behind us (just like KAME is too).. I have put on my web site patch-24 (which I have, as yet, not sent to KAME and probably will-not). Patch 25 will come out as soon as I finish fixing Chiba-san's issues... resolving all known bugs :-D I have not heard of any compile issues with SCTP and KAME.. if there are it is probably due to changes in KAME that need changes in the SCTP side too... We always cvs update and compile to validate BEFORE we send in the patch to Itojun. There have been SOME issues with the formatting.. in some cases code as accidentally disappeared.. but this will happen on a project like ours as we send patches in and try to integrate it :-D Anyway.. I do think it is stable enough for inclusion in stable BSD... if you have another 4.x round.. BUT we have not went in and fully got things working on 5.x... I know one of our team members (Kozuka-san) has made an effort to make it compile.. but it as yet does not function :-0 I also, before patch 25, would like to finish a third round of performance optimization. I finally have a second machine with a Gig-E interface and 2.XMhz .. so I think I can try to squeak it up a bit more... ah.. plans for next week if I can find the cycles :-o Anyway.. after patch-25 I intend on taking my new machine to the 5.3 strain and trying to figure out what I need to do to make it work :-0 (maybe patch26 :-D) R Peter Lei wrote: > I think this is because any bugs that are found are usually > communicated directly to us. > > I think Randy has a better handle on how many people are using > this stack. I'm quite sure it is stable enough to go in to > -current. > > While the SCTP API hasn't gone through last call, it's fairly > stable and we have both "converted" many applications from TCP > to SCTP using the sockets API, as well as had portability between > the KAME SCTP stack and the linux stack for some test applications > used at the last interop event (except for the standard sockets > issues that one runs into even for TCP like no sin_length field > in the sockaddr struct). > > The same stack has also been ported to Mac OSX as a native kernel > build as well as an loadable/unloadble NKE w/a minor kernel change. > > I'm not aware of any KAME SNAP compilation failures w/and w/o SCTP. > The major changes to our SCTP code when it gets committed into KAME > has been that of code format/style. > > What is the existing criteria for a measure of "stability"? > > regards, > --peter > > SUZUKI Shinsuke wrote: > >>>>>>> On Thu, 21 Oct 2004 21:32:48 +0200 >>>>>>> molter@tin.it(Marco Molteni) said: >> >> >> >>> SCTP in KAME is complete, stable and fully supported. >>> It is mainly developed by the SCTP RFC author, Randall Stewart. >> >> >> >> KAME Project haven't received SCTP-related bug report so much, and I >> think it's due to a lack of testers, SCTP-API standard, and SCTP-ready >> applications. >> #Sometimes KAME SNAP compilation fails in SCTP and non-SCTP >> #application fails in compilation due to a change by SCTP. So it's >> #difficult to conclude that SCTP is already stable... >> >> So I'm not still sure if SCTP in KAME is complete and stable enough to >> merge into -current. (If someone can contribute to this kind of >> evaluation, it's quite appreciated, of course!) >> >> Thanks, >> ---- >> SUZUKI, Shinsuke @ KAME Project >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > -- Randall Stewart 803-345-0369 815-342-5222(cell) From owner-freebsd-arch@FreeBSD.ORG Sat Oct 23 13:16:40 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8580416A4CE; Sat, 23 Oct 2004 13:16:40 +0000 (GMT) Received: from stewart.chicago.il.us (dpc674425142.direcpc.com [67.44.25.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D4E143D58; Sat, 23 Oct 2004 13:16:38 +0000 (GMT) (envelope-from randall@stewart.chicago.il.us) Received: from stewart.chicago.il.us (localhost [127.0.0.1]) i9NDGRtr031497; Sat, 23 Oct 2004 09:16:33 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <417A5960.3000708@stewart.chicago.il.us> Date: Sat, 23 Oct 2004 09:15:12 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matt Emmerton References: <4177C8AD.6060706@freebsd.org><20041021153933.GK13756@empiric.icir.org> <4177E25E.804639E@freebsd.org> <00e901c4b79b$d13e6e40$1200a8c0@gsicomp.on.ca> In-Reply-To: <00e901c4b79b$d13e6e40$1200a8c0@gsicomp.on.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Bruce M Simpson cc: freebsd-arch@freebsd.org cc: Andre Oppermann cc: freebsd-net@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2004 13:16:40 -0000 Matt Emmerton wrote: > > > The SCTP home page (www.sctp.org) has a list of implementations. Note that > I had to use Google's cache of the site -- I believe there was a Slashdot > article on SCTP this morning which may have taken down the site. Sigh... It is also over satellite... which is medium speed internet at best.. my provider may also have limits on how many connection attempts I get ... I buy a professional package.. but you can BET I will dump sat has soon as DSL shows up (in the next year or soo I hope)... > > AIX, Solaris, HP and Cisco all support SCTP in their latest OS versions. > There are aslo a few different (non-free) implementations for Windows, and > at least one open-source implementation for Linux (http://www.openss7.org) > Linux has SCTP built into the kernle with the lk-sctp project.. I would not touch the openss7 version.. it is not very compatible with any other SCTP (it does not follow the standard).. At the last interop some of the issues were finally fixed (its really the first time they showed up and tested)... but I don't know if those patches are available or per fee. The lk-sctp project in the kernel is far stabler and they are working to performance tune it (here it needs a lot of work) and AFAIK lk-sctp will ship with all 2.6.6 and greater kernels... turned on by default if I remember right.. R > -- > Matt Emmerton > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > -- Randall Stewart 803-345-0369 815-342-5222(cell) From owner-freebsd-arch@FreeBSD.ORG Sat Oct 23 13:17:24 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0BDB16A4CE; Sat, 23 Oct 2004 13:17:24 +0000 (GMT) Received: from stewart.chicago.il.us (dpc674425142.direcpc.com [67.44.25.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D68943D53; Sat, 23 Oct 2004 13:17:22 +0000 (GMT) (envelope-from randall@stewart.chicago.il.us) Received: from stewart.chicago.il.us (localhost [127.0.0.1]) i9NDHJtr031503; Sat, 23 Oct 2004 09:17:20 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <417A5994.7020306@stewart.chicago.il.us> Date: Sat, 23 Oct 2004 09:16:04 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marco Molteni References: <4177C8AD.6060706@freebsd.org> <20041021153933.GK13756@empiric.icir.org> <4177E25E.804639E@freebsd.org> <20041021213248.223cab2c.molter@tin.it> In-Reply-To: <20041021213248.223cab2c.molter@tin.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: Andre Oppermann cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2004 13:17:25 -0000 Marco Molteni wrote: > On Thu, 21 Oct 2004 Andre Oppermann wrote: > > >>Bruce M Simpson wrote: >> >>>On Thu, Oct 21, 2004 at 04:33:17PM +0200, Andre Oppermann wrote: >>> >>>>Thus after the removal of T/TCP for the reasons above I want to >>>>provide a work-alike replacement for T/TCP's functionality: >>> >>>I disagree. I think the time spent here would be better spent on >>>working on an import of SCTP into the kernel, perhaps the KAME code >>>base would be a good starting point. >> >>Is the SCTP in KAME complete and stable? Are there any other (open >>source) implementations of it? > > > SCTP in KAME is complete, stable and fully supported. > It is mainly developed by the SCTP RFC author, Randall Stewart. > > A T/TCP alternative as you are describing sounds very > similar to PR-SCTP (Partial Reliability SCTP). (Don't let the > name fool you, please read the internet draft). RFC3758 (its a proposed standard now.. not a draft.) :-> R > There is at least another kernel-level open source implementation, > for Linux, plus other user-level implementations. > > marco -- Randall Stewart 803-345-0369 815-342-5222(cell) From owner-freebsd-arch@FreeBSD.ORG Sat Oct 23 13:20:46 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0586E16A4CE; Sat, 23 Oct 2004 13:20:46 +0000 (GMT) Received: from stewart.chicago.il.us (dpc674425142.direcpc.com [67.44.25.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id A037E43D1F; Sat, 23 Oct 2004 13:20:43 +0000 (GMT) (envelope-from randall@stewart.chicago.il.us) Received: from stewart.chicago.il.us (localhost [127.0.0.1]) i9NDKNtr031514; Sat, 23 Oct 2004 09:20:25 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <417A5A4C.1080706@stewart.chicago.il.us> Date: Sat, 23 Oct 2004 09:19:08 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Russell L. Carter" References: <20041022020226.A8D34103A028@feyerabend.hq.pinyon.org> In-Reply-To: <20041022020226.A8D34103A028@feyerabend.hq.pinyon.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Craig Rodrigues cc: freebsd-arch@freebsd.org cc: Andre Oppermann cc: freebsd-net@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2004 13:20:46 -0000 Russell L. Carter wrote: > Greetings, > > It is not easy to get kame up and running, and I know this because > I have. It is beyond all ordinary production installations. Wow.. I have never had a problem installing it.. but of course I have worked in U**X for 20+ years... so maybe I don't notice and am not a good example :-9 > > And as Craig notes it's not possible[1] in the 5* line > yet. Maybe Randall would like to chip in on whether BSD SCTP > is ready for prime time in FreeBSD. But do not underestimate > the gains this protocol provides for fault tolerant > server applications. The 5* port is on my radar... as I just posted in my cross post). The 4* is ready for prime time IMO, I do have a few bugs that need addressing (I will get to them next week I hope ...sigh) R > > Russell > > [1] It's been two months since I tried. > > : > : On Thu, Oct 21, 2004 at 09:32:48PM +0200, Marco Molteni wrote: > : > SCTP in KAME is complete, stable and fully supported. > : > It is mainly developed by the SCTP RFC author, Randall Stewart. > : > : Randall has been maintaining his SCTP stack on FreeBSD 4.x, > : OpenBSD, and NetBSD. It has recently been ported to Darwin. > : > : > : > > : > A T/TCP alternative as you are describing sounds very > : > similar to PR-SCTP (Partial Reliability SCTP). (Don't let the > : > name fool you, please read the internet draft). > : > : Interesting stuff: > : http://www.portaroo.net/ietf/idref/draft-ietf-tsvwg-prsctp/ > : > : > > : > There is at least another kernel-level open source implementation, > : > for Linux, plus other user-level implementations. > : > : There is one kernel implementation of SCTP in > : the Linux 2.6 series of kernels ( http://lksctp.sourceforge.net ), > : and another kernel level implementation available separately > : ( http://www.openss7.org/sctp.html ). > : > : SCTP is an IETF standard, and a lot of people are getting interested > : in it. It would be nice to have it in FreeBSD, especially since > : it is showing up in the Linux distributions. > : > : The only issue with Randall's implementation is that > : it is only for 4.x.....I looked a while back at porting it to 5.x/CURRENT.... > : there is some work that needs to be done, i.e. using > : the new zone(9) API for allocating memory, and probably also > : getting the locking right. > : > : I don't know how much overlap there is with what Andre is going to > : implement, but I thought I would throw the information out there > : for those who may be interested. :) > : > : -- > : Craig Rodrigues > : http://crodrigues.org > : rodrigc@crodrigues.org > : _______________________________________________ > : freebsd-net@freebsd.org mailing list > : http://lists.freebsd.org/mailman/listinfo/freebsd-net > : To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > -- Randall Stewart 803-345-0369 815-342-5222(cell) From owner-freebsd-arch@FreeBSD.ORG Sat Oct 23 13:24:12 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 17B8316A4CE; Sat, 23 Oct 2004 13:24:12 +0000 (GMT) Received: from stewart.chicago.il.us (dpc674425142.direcpc.com [67.44.25.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A73843D69; Sat, 23 Oct 2004 13:24:09 +0000 (GMT) (envelope-from randall@stewart.chicago.il.us) Received: from stewart.chicago.il.us (localhost [127.0.0.1]) i9NDO3tr031523; Sat, 23 Oct 2004 09:24:06 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <417A5B28.9080308@stewart.chicago.il.us> Date: Sat, 23 Oct 2004 09:22:48 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@icir.org References: <20041021183238.00E8977A9D0@guns.icir.org> In-Reply-To: <20041021183238.00E8977A9D0@guns.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: Andre Oppermann cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2004 13:24:12 -0000 Mark Allman wrote: >>Sure. To make you sleep better it will be disabled by default (like >>T/TCP) and possibly even not compliled in by default (#ifdef'd). > > > Part of your argument against T/TCP. :-) > > >>A writeup will follow once I get there. I made this request before I >>start working on it to prevent to waste my time on it if people wanted >>to religiously stick to T/TCP. > > > I think moving on from T/TCP is fine, don't get me wrong. And, I am all > for seeing new schemes that buy us some of the things T/TCP was designed > for. I am just not enthusiastic about dumping things into the kernel > without some review and thought (by more than one person; and, that is > not a knock on you --- if I had a nickel for every half-baked thing I'd > implemented somewhere .... basically, it's good to get different > perspectives). > > Doing this in a systematic way may have benefits beyond FreeBSD, as > well, of course. I would rather have Andre work with me to get any other rinkles out of SCTP that he deems are there... and get the KAME-SCTP stack ported directly in to FreeBSD.. this IMO ... would make more sense... Get something that is pretty well baked (IMO at least) and work to get it "productionized" (even though I don't feel it needs much work in this vein)... R > > allman > > > -- Randall Stewart 803-345-0369 815-342-5222(cell) From owner-freebsd-arch@FreeBSD.ORG Sat Oct 23 14:16:46 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9DF116A4CF for ; Sat, 23 Oct 2004 14:16:46 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2F8E43D41 for ; Sat, 23 Oct 2004 14:16:45 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 96072 invoked from network); 23 Oct 2004 14:15:01 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 23 Oct 2004 14:15:01 -0000 Message-ID: <417A67CC.90E11C98@freebsd.org> Date: Sat, 23 Oct 2004 16:16:44 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Randall Stewart References: <4177C8AD.6060706@freebsd.org> <20041021153933.GK13756@empiric.icir.org> <4177E25E.804639E@freebsd.org> <20041021213248.223cab2c.molter@tin.it> <4179ACB8.4020108@ieee.org> <417A572A.9080306@stewart.chicago.il.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Peter Lei cc: molter@tin.it cc: freebsd-arch@freebsd.org cc: SUZUKI Shinsuke cc: freebsd-net@freebsd.org Subject: SCTP in FreeBSD 5.x/current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2004 14:16:46 -0000 Randall Stewart wrote: > Anyway.. I do think it is stable enough for inclusion in > stable BSD... if you have another 4.x round.. BUT we have > not went in and fully got things working on 5.x... I know > one of our team members (Kozuka-san) has made an effort > to make it compile.. but it as yet does not function :-0 > > I also, before patch 25, would like to finish a third round > of performance optimization. I finally have a second machine > with a Gig-E interface and 2.XMhz .. so I think I can > try to squeak it up a bit more... ah.. plans for next > week if I can find the cycles :-o > > Anyway.. after patch-25 I intend on taking my new machine > to the 5.3 strain and trying to figure out what I need > to do to make it work :-0 (maybe patch26 :-D) Randall, I'm willing to work with you to get SCTP into FreeBSD-CURRENT. All new stuff has to go into -current first before it is allowed to be backported to 5.x and 4.x. -current and 5.x are not much different so a port by you to 5.x will usually work with -current as well. What I can't do is extensive porting/testing of SCTP. But I can "hold your hand" and support you from the FreeBSD team side. The largest difference between 4.x and 5.x is proper SMP locking. The socket layer is fine-grained SMP locked and the underlying transport protocols have to be aware of that to get decent performance. But we can work that out based on the experience we have with locking down the TCP code. Don't be afraid, that way it's less hard than it seems on the first glance. But nontheless having a simple and more secure replacement for T/TCP is a worthwile goal and I will do it, even if just for fun. Keeps me sharp on the TCP code. ;-) -- Andre From owner-freebsd-arch@FreeBSD.ORG Sat Oct 23 16:01:18 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 248D716A4D0; Sat, 23 Oct 2004 16:01:18 +0000 (GMT) Received: from ran.psg.com (ip192.186.dsl-acs2.seawa0.iinet.com [209.20.186.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 821C843D46; Sat, 23 Oct 2004 16:01:17 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=ran.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1CLOKS-000IJt-RJ; Sat, 23 Oct 2004 09:01:16 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16762.32844.243298.206348@ran.psg.com> Date: Sat, 23 Oct 2004 09:01:16 -0700 To: Peter Lei References: <4177C8AD.6060706@freebsd.org> <4177E25E.804639E@freebsd.org> <4179ACB8.4020108@ieee.org> cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: SCTP in KAME / Re: Removing T/TCP and replacing itwithsomething simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2004 16:01:18 -0000 dunno if i am the randy you meant to invoke, but sctp is far more usable and used than t/tcp. but it is not widely used yet. it very well may be. i think it would be good to support it, and i have zero qualms about dumping t/tcp. randy