From owner-freebsd-arch@FreeBSD.ORG Sun Oct 17 00:07:55 2004
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <scottl@freebsd.org>
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 <drosih@rpi.edu>
References: <20041016174419.GA96297@dragon.nuxi.com>
<p06110436bd975fb79f55@[128.113.24.47]>
In-Reply-To: <p06110436bd975fb79f55@[128.113.24.47]>
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 <strings.h>.
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussion related to FreeBSD architecture
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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 <strings.h>
>> includes the content of <string.h> in addition to the BSD bcmp,
>> et. al. We changed our <strings.h> 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 <strings.h>
> starts pulling in <string.h>.
>
> It looks like 5.x has gone 2 and a half years with <strings.h> not
> including <string.h>, 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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 4D70316A4CE
for <freebsd-arch@FreeBSD.ORG>; 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 <freebsd-arch@FreeBSD.ORG>; 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 <freebsd-arch@FreeBSD.ORG>; 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" <obrien@FreeBSD.ORG>
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 <strings.h>.
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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 <strings.h>
> > includes the content of <string.h> in addition to the BSD bcmp, et. al.
> > We changed our <strings.h> 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 <strings.h> is only portable across BSD's.
<strings.h> isn't POSIX. I totally don't understand why we made a
<strings.h> 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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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" <obrien@freebsd.org>
To: Scott Long <scottl@freebsd.org>
Message-ID: <20041017011712.GB6140@dragon.nuxi.com>
References: <20041016174419.GA96297@dragon.nuxi.com>
<p06110436bd975fb79f55@[128.113.24.47]> <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 <drosih@rpi.edu>
cc: freebsd-arch@freebsd.org
Subject: Re: Proposal to restore traditional BSD behavior in <strings.h>.
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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 <strings.h>
> >>includes the content of <string.h> in addition to the BSD bcmp,
> >>et. al. We changed our <strings.h> 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 <strings.h>
> >starts pulling in <string.h>.
> >
> >It looks like 5.x has gone 2 and a half years with <strings.h> not
> >including <string.h>, 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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id E116316A4D1
for <arch@freebsd.org>; 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 <arch@freebsd.org>; 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 <ryans@gamersimpact.com>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <wollman@khavrinen.lcs.mit.edu>
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 <strings.h>.
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussion related to FreeBSD architecture
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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 <strings.h>
>> > includes the content of <string.h> in addition to the BSD bcmp, et. al.
>> > We changed our <strings.h> 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.
>
><strings.h> 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 <strings.h>. 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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id AB36A16A4CE
for <arch@freebsd.org>; 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 <arch@freebsd.org>; 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 <scottl@freebsd.org>
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 <ryans@gamersimpact.com>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 19ED916A4CE
for <freebsd-arch@freebsd.org>; 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 <freebsd-arch@freebsd.org>; Mon, 18 Oct 2004 14:21:10 +0000 (GMT)
(envelope-from sah@softcardsystems.com)
Received: from athena (athena [12.34.136.114])i9IFJDeM011154
for <freebsd-arch@freebsd.org>; Mon, 18 Oct 2004 10:19:13 -0500
Date: Mon, 18 Oct 2004 10:19:13 -0500 (EST)
From: Sam <sah@softcardsystems.com>
X-X-Sender: sah@athena
To: freebsd-arch@freebsd.org
Message-ID: <Pine.LNX.4.60.0410180948490.10774@athena>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 24DAE16A4CE
for <arch@freebsd.org>; 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 <arch@freebsd.org>; 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 <rcoleman@criticalmagic.com>
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 <ryans@gamersimpact.com>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 7843916A4CE
for <arch@freebsd.org>; 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 <arch@freebsd.org>; 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" <obrien@freebsd.org>
To: Richard Coleman <rcoleman@criticalmagic.com>
Message-ID: <20041018173043.GE5179@dragon.nuxi.com>
Mail-Followup-To: David O'Brien <obrien@FreeBSD.org>,
Richard Coleman <rcoleman@criticalmagic.com>,
Ryan Sommers <ryans@gamersimpact.com>, 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 <ryans@gamersimpact.com>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id A580C16A4CE
for <arch@freebsd.org>; 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 <arch@freebsd.org>; 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" <ryans@gamersimpact.com>
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 <ryans@gamersimpact.com>
cc: Richard Coleman <rcoleman@criticalmagic.com>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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 <bsd.subdir.mk>
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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <obrien@FreeBSD.org>
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: <xzp7jpng7i7.fsf@dwp.des.no>
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 <ryans@gamersimpact.com>
cc: Richard Coleman <rcoleman@criticalmagic.com>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Oct 2004 19:18:32 -0000
"David O'Brien" <obrien@freebsd.org> 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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <rcoleman@criticalmagic.com>
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 <ryans@gamersimpact.com>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <Alexander@Leidinger.net@Andro-Beta.Leidinger.net>;
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 <Alexander@Leidinger.net>
To: obrien@freebsd.org
References: <200410180534.i9I5YsGn053852@repoman.freebsd.org>
<1098101272.4173b21825a40@netchild.homeip.net>
<20041018173955.GB5737@dragon.nuxi.com> <xzpoeizgagq.fsf@dwp.des.no>
<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 <des@des.no>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Oct 2004 10:27:13 -0000
Zitat von David O'Brien <obrien@freebsd.org>:
[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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <sobomax@FreeBSD.org>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "current@freebsd.org" <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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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 <dillon@apollo.backplane.com>
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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 5AB7016A4D0
for <arch@freebsd.org>; 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 <arch@freebsd.org>; Wed, 20 Oct 2004 15:16:56 +0000 (GMT)
(envelope-from mitigator@gmail.com)
Received: by mproxy.gmail.com with SMTP id 79so426704rnk
for <arch@freebsd.org>; 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 <mitigator@gmail.com>
To: Maxim Sobolev <sobomax@freebsd.org>
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 <mitigator@gmail.com>
List-Id: Discussion related to FreeBSD architecture
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <brooks@one-eyed-alien.net>
To: jamie rishaw at google mail <mitigator@gmail.com>
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 <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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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" <imp@bsdimp.com>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Oct 2004 15:32:59 -0000
In message: <6ff30abd04102008163115a32d@mail.gmail.com>
jamie rishaw at google mail <mitigator@gmail.com> 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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 71FB716A4D0
for <arch@freebsd.org>; 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 <arch@freebsd.org>; Wed, 20 Oct 2004 15:39:17 +0000 (GMT)
(envelope-from mitigator@gmail.com)
Received: by mproxy.gmail.com with SMTP id 79so429598rnk
for <arch@freebsd.org>; 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 <mitigator@gmail.com>
To: "M. Warner Losh" <imp@bsdimp.com>
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 <mitigator@gmail.com>
List-Id: Discussion related to FreeBSD architecture
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <wb@freebie.xs4all.nl>
To: "M. Warner Losh" <imp@bsdimp.com>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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 <mitigator@gmail.com> 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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <keramida@freebsd.org>
To: Maxim Sobolev <sobomax@freebsd.org>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Oct 2004 15:45:50 -0000
On 2004-10-20 17:57, Maxim Sobolev <sobomax@freebsd.org> 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 <dillon@apollo.backplane.com>
> : 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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <scottl@freebsd.org>
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 <mitigator@gmail.com>
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 <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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <ceri@submonkey.net>
To: Scott Long <scottl@freebsd.org>
Message-ID: <20041020164002.GH57641@submonkey.net>
Mail-Followup-To: Ceri Davies <ceri@submonkey.net>,
Scott Long <scottl@freebsd.org>,
jamie rishaw at google mail <mitigator@gmail.com>,
Maxim Sobolev <sobomax@freebsd.org>, 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 <setantae@submonkey.net>
cc: Maxim Sobolev <sobomax@freebsd.org>
cc: jamie rishaw at google mail <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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <scottl@freebsd.org>
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 <ceri@submonkey.net>
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 <sobomax@freebsd.org>
cc: jamie rishaw at google mail <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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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" <imp@bsdimp.com>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Oct 2004 16:53:46 -0000
In message: <20041020154026.GA40554@freebie.xs4all.nl>
Wilko Bulte <wb@freebie.xs4all.nl> 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 <mitigator@gmail.com> 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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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" <imp@bsdimp.com>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Oct 2004 16:56:51 -0000
In message: <6ff30abd04102008396bb61196@mail.gmail.com>
jamie rishaw at google mail <mitigator@gmail.com> 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
<imp@village.org>. See end of file for further details.
:-)
Warner Losh
From owner-freebsd-arch@FreeBSD.ORG Wed Oct 20 16:59:51 2004
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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" <imp@bsdimp.com>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Oct 2004 16:59:51 -0000
In message: <20041020154545.GA15763@orion.daedalusnetworks.priv>
Giorgos Keramidas <keramida@freebsd.org> 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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <keramida@freebsd.org>
To: "M. Warner Losh" <imp@bsdimp.com>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Oct 2004 17:10:01 -0000
On 2004-10-20 10:58, "M. Warner Losh" <imp@bsdimp.com> wrote:
> In message: <20041020154545.GA15763@orion.daedalusnetworks.priv>
> Giorgos Keramidas <keramida@freebsd.org> 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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <max@love2party.net>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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: <p06110409bd9c4c227db0@[128.113.24.47]>
In-Reply-To: <41767CF1.2020005@FreeBSD.org>
References: <41767CF1.2020005@FreeBSD.org>
Date: Wed, 20 Oct 2004 13:17:44 -0400
To: Maxim Sobolev <sobomax@freebsd.org>, <current@freebsd.org>
From: Garance A Drosihn <drosih@rpi.edu>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <sobomax@FreeBSD.org>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Alex de Kruijff <freebsd@akruijff.dds.nl>
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" <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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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 <dillon@apollo.backplane.com>
>>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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <sah@softcardsystems.com>
X-X-Sender: sah@athena
To: Max Laier <max@love2party.net>
In-Reply-To: <200410201913.42879.max@love2party.net>
Message-ID: <Pine.LNX.4.60.0410201315040.26392@athena>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <brooks@one-eyed-alien.net>
To: Maxim Sobolev <sobomax@freebsd.org>
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" <current@freebsd.org>
cc: Alex de Kruijff <freebsd@akruijff.dds.nl>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <scottl@freebsd.org>
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 <brooks@one-eyed-alien.net>
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 <sobomax@freebsd.org>
cc: Alex de Kruijff <freebsd@akruijff.dds.nl>
cc: "current@freebsd.org" <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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <ru@freebsd.org>
To: Max Laier <max@love2party.net>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <scottl@freebsd.org>
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 <ru@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>
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 <max@love2party.net>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id E8A1616A4CF
for <freebsd-arch@freebsd.org>; 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 <freebsd-arch@freebsd.org>; 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" <ryans@gamersimpact.com>
To: "Scott Long" <scottl@freebsd.org>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <ru@freebsd.org>
To: Scott Long <scottl@freebsd.org>
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 <max@love2party.net>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <julian@elischer.org>
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 <wb@freebie.xs4all.nl>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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 <mitigator@gmail.com> 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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <dimitry@andric.com>
X-Mailer: The Bat! (v3.0.2.1) Professional
X-Priority: 3 (Normal)
Message-ID: <843590857.20041020231104@andric.com>
To: Scott Long <scottl@freebsd.org>
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 <max@love2party.net>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <dillon@apollo.backplane.com>
Message-Id: <200410202129.i9KLTmTK045310@apollo.backplane.com>
To: Julian Elischer <julian@elischer.org>
References: <41767CF1.2020005@FreeBSD.org>
<6ff30abd04102008163115a32d@mail.gmail.com>
<20041020.093211.78703993.imp@bsdimp.com>
<4176D21F.3060108@elischer.org>
cc: Wilko Bulte <wb@freebie.xs4all.nl>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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: <p0611040ebd9c7ef46715@[128.113.24.47]>
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 <scottl@freebsd.org>, Ruslan Ermilov <ru@freebsd.org>
From: Garance A Drosihn <drosih@rpi.edu>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <julian@elischer.org>
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 <scottl@freebsd.org>
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" <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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <brooks@one-eyed-alien.net>
To: Scott Long <scottl@freebsd.org>
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 <sobomax@freebsd.org>
cc: Alex de Kruijff <freebsd@akruijff.dds.nl>
cc: "current@freebsd.org" <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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <sobomax@portaone.com>
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 <scottl@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>
In-Reply-To: <4176C0C8.4060408@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
cc: Max Laier <max@love2party.net>
cc: freebsd-current@FreeBSD.ORG
cc: Ruslan Ermilov <ru@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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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.<Link the executable as normal. Assuming that is is called>
"foo" then...
1.<Run "objcopy --only-keep-debug foo foo.dbg" to>
create a file containing the debugging info.
1.<Run "objcopy --strip-debug foo" to create a>
stripped executable.
1.<Run "objcopy --add-gnu-debuglink=foo.dbg foo">
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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <sobomax@portaone.com>
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 <scottl@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> <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 <max@love2party.net>
cc: freebsd-current@FreeBSD.ORG
cc: Ruslan Ermilov <ru@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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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.<Link the executable as normal. Assuming that is is called>
> "foo" then...
>
> 1.<Run "objcopy --only-keep-debug foo foo.dbg" to>
> create a file containing the debugging info.
>
> 1.<Run "objcopy --strip-debug foo" to create a>
> stripped executable.
>
> 1.<Run "objcopy --add-gnu-debuglink=foo.dbg foo">
> 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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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: <p06110413bd9c98465661@[128.113.24.47]>
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 <sobomax@portaone.com>,
Scott Long <scottl@freebsd.org>
From: Garance A Drosihn <drosih@rpi.edu>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <ru@FreeBSD.ORG>
To: Maxim Sobolev <sobomax@portaone.com>
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 <max@love2party.net>
cc: freebsd-current@FreeBSD.ORG
cc: Scott Long <scottl@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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <brooks@one-eyed-alien.net>
To: Maxim Sobolev <sobomax@portaone.com>
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 <max@love2party.net>
cc: freebsd-current@freebsd.org
cc: Scott Long <scottl@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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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.<Link the executable as normal. Assuming that is is called>
> > "foo" then...
> >
> > 1.<Run "objcopy --only-keep-debug foo foo.dbg" to>
> > create a file containing the debugging info.
> >
> > 1.<Run "objcopy --strip-debug foo" to create a>
> > stripped executable.
> >
> > 1.<Run "objcopy --add-gnu-debuglink=3Dfoo.dbg foo">
> > 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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 0847516A4D0
for <arch@freebsd.org>; 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 <arch@freebsd.org>; 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 <michaelnottebrock@gmx.net>
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 <julian@elischer.org>
cc: Wilko Bulte <wb@freebie.xs4all.nl>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 446FF16A4CE
for <freebsd-arch@freebsd.org>; 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 <freebsd-arch@freebsd.org>; 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 <andre@freebsd.org>)
by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP
for <freebsd-arch@freebsd.org>; 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 <andre@freebsd.org>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <andre@freebsd.org>
From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 2E6AE16A4CE
for <freebsd-arch@freebsd.org>; 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 <freebsd-arch@freebsd.org>; 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 <andre@freebsd.org>)
by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP
for <phk@phk.freebsd.dk>; 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 <andre@freebsd.org>
X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <richard@codeburst.co.uk>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 4FBB516A4CF
for <freebsd-arch@freebsd.org>; 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 <freebsd-arch@freebsd.org>; 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 <silby@silby.com>
To: Andre Oppermann <andre@freebsd.org>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 12B5F16A4DD
for <freebsd-arch@freebsd.org>; 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 <freebsd-arch@freebsd.org>; 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 <andre@freebsd.org>)
by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP
for <silby@silby.com>; 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 <andre@freebsd.org>
X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Mike Silbersack <silby@silby.com>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <bms@spc.org>
To: Andre Oppermann <andre@freebsd.org>
Message-ID: <20041021153933.GK13756@empiric.icir.org>
Mail-Followup-To: Andre Oppermann <andre@freebsd.org>,
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id BFAC116A4CE
for <freebsd-arch@freebsd.org>; 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 <freebsd-arch@freebsd.org>; 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 <andre@freebsd.org>)
by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP
for <bms@spc.org>; 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 <andre@freebsd.org>
X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce M Simpson <bms@spc.org>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <wollman@khavrinen.lcs.mit.edu>
Message-Id: <200410211627.i9LGRvsj026447@khavrinen.lcs.mit.edu>
To: Mike Silbersack <silby@silby.com>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Oct 2004 16:27:59 -0000
<<On Thu, 21 Oct 2004 10:24:08 -0500 (CDT), Mike Silbersack <silby@silby.com> 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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <andre@freebsd.org>
From: Mark Allman <mallman@icir.org>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 6D1A716A4CE
for <freebsd-arch@freebsd.org>; 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 <freebsd-arch@freebsd.org>; 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 <andre@freebsd.org>)
by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP
for <mallman@icir.org>; 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 <andre@freebsd.org>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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" <matt@gsicomp.on.ca>
To: "Andre Oppermann" <andre@freebsd.org>,
"Bruce M Simpson" <bms@spc.org>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <sean@chittenden.org>
Date: Thu, 21 Oct 2004 11:31:38 -0700
To: Andre Oppermann <andre@freebsd.org>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <andre@freebsd.org>
From: Mark Allman <mallman@icir.org>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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" <obrien@freebsd.org>
To: Andre Oppermann <andre@freebsd.org>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 3609616A4D7
for <freebsd-arch@freebsd.org>; 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 <freebsd-arch@freebsd.org>; 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 <andre@freebsd.org>)
by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP
for <sean@chittenden.org>; 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 <andre@freebsd.org>
X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sean Chittenden <sean@chittenden.org>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <julian@elischer.org>
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 <andre@freebsd.org>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <wollman@khavrinen.lcs.mit.edu>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Oct 2004 19:01:59 -0000
<<On Thu, 21 Oct 2004 11:51:37 -0700, "David O'Brien" <obrien@FreeBSD.ORG> 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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id A96DF16A4CF
for <freebsd-arch@freebsd.org>; 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 <freebsd-arch@freebsd.org>; 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 <andre@freebsd.org>)
by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP
for <freebsd-arch@freebsd.org>; 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 <andre@freebsd.org>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id DFBAB16A4CE
for <freebsd-arch@freebsd.org>; 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 <freebsd-arch@freebsd.org>; 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 <andre@freebsd.org>)
by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP
for <julian@elischer.org>; 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 <andre@freebsd.org>
X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Julian Elischer <julian@elischer.org>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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: <E0C34A72-2396-11D9-9171-000A95C705DC@chittenden.org>
Content-Transfer-Encoding: 7bit
From: Sean Chittenden <sean@chittenden.org>
Date: Thu, 21 Oct 2004 12:24:50 -0700
To: Andre Oppermann <andre@freebsd.org>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <molter@tin.it>
To: Andre Oppermann <andre@freebsd.org>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Oct 2004 19:34:24 -0000
On Thu, 21 Oct 2004 Andre Oppermann <andre@freebsd.org> 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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <is@rambler-co.ru>
X-X-Sender: is@is.park.rambler.ru
To: Sean Chittenden <sean@chittenden.org>
In-Reply-To: <E0C34A72-2396-11D9-9171-000A95C705DC@chittenden.org>
Message-ID: <20041021233447.L91215@is.park.rambler.ru>
References: <4177C8AD.6060706@freebsd.org>
<71C3A1EA-238F-11D9-9171-000A95C705DC@chittenden.org>
<E0C34A72-2396-11D9-9171-000A95C705DC@chittenden.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
cc: Andre Oppermann <andre@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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <rodrigc@crodrigues.org>
To: Marco Molteni <molter@tin.it>
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 <andre@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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <rodrigc@crodrigues.org>
In-Reply-To: Message from Craig Rodrigues <rodrigc@crodrigues.org>
<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" <rcarter@pinyon.org>
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 <molter@tin.it>
cc: freebsd-net@freebsd.org
cc: Andre Oppermann <andre@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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 69F7916A4CE
for <freebsd-arch@freebsd.org>; 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 <freebsd-arch@freebsd.org>; 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 <julian@elischer.org>
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 <rodrigc@crodrigues.org>
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 <molter@tin.it>
cc: bms@spc.org
cc: freebsd-arch@freebsd.org
cc: Andre Oppermann <andre@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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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: <x7r7nrgsol.wl%suz@crl.hitachi.co.jp>
From: SUZUKI Shinsuke <suz@kame.net>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <andre@freebsd.org>
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: <xzpk6tjx8vb.fsf@dwp.des.no>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Oct 2004 11:58:26 -0000
Andre Oppermann <andre@freebsd.org> 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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <andre@freebsd.org>
References: <4177C8AD.6060706@freebsd.org> <xzpk6tjx8vb.fsf@dwp.des.no>
From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=)
Date: Fri, 22 Oct 2004 14:47:30 +0200
In-Reply-To: <xzpk6tjx8vb.fsf@dwp.des.no> (Dag-Erling
=?iso-8859-1?q?Sm=F8rgrav's?= message of "Fri, 22 Oct 2004 13:58:16 +0200")
Message-ID: <xzpfz46yl5p.fsf@dwp.des.no>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 7D09916A4CE
for <freebsd-arch@freebsd.org>; 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 <freebsd-arch@freebsd.org>; 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 <andre@freebsd.org>)
by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP
for <sean@chittenden.org>; 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 <andre@freebsd.org>
X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sean Chittenden <sean@chittenden.org>
References: <4177C8AD.6060706@freebsd.org>
<71C3A1EA-238F-11D9-9171-000A95C705DC@chittenden.org>
<41780672.6AAC705F@freebsd.org>
<E0C34A72-2396-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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id B036616A4D0
for <freebsd-arch@freebsd.org>; 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 <freebsd-arch@freebsd.org>; 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 <andre@freebsd.org>)
by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP
for <molter@tin.it>; 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 <andre@freebsd.org>
X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Marco Molteni <molter@tin.it>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Oct 2004 15:15:01 -0000
Marco Molteni wrote:
>
> On Thu, 21 Oct 2004 Andre Oppermann <andre@freebsd.org> 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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 93DEF16A4D3
for <freebsd-arch@freebsd.org>; 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 <freebsd-arch@freebsd.org>; 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 <andre@freebsd.org>)
by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP
for <des@des.no>; 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 <andre@freebsd.org>
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?= <des@des.no>
References: <4177C8AD.6060706@freebsd.org> <xzpk6tjx8vb.fsf@dwp.des.no>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Oct 2004 15:23:06 -0000
Dag-Erling Smørgrav wrote:
>
> Andre Oppermann <andre@freebsd.org> 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: <owner-freebsd-arch@FreeBSD.ORG>
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 <green@freebsd.org>
To: Andre Oppermann <andre@freebsd.org>
Message-ID: <20041022154517.GN1072@green.homeunix.org>
References: <4177C8AD.6060706@freebsd.org>
<71C3A1EA-238F-11D9-9171-000A95C705DC@chittenden.org>
<41780672.6AAC705F@freebsd.org>
<E0C34A72-2396-11D9-9171-000A95C705DC@chittenden.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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id CAA5C16A4CE
for <freebsd-arch@freebsd.org>; 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 <freebsd-arch@freebsd.org>; 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 <andre@freebsd.org>)
by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP
for <green@freebsd.org>; 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 <andre@freebsd.org>
X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Brian Fundakowski Feldman <green@freebsd.org>
References: <4177C8AD.6060706@freebsd.org>
<71C3A1EA-238F-11D9-9171-000A95C705DC@chittenden.org>
<41780672.6AAC705F@freebsd.org>
<E0C34A72-2396-11D9-9171-000A95C705DC@chittenden.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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <molter@tin.it>
From: Mark Allman <mallman@icir.org>
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 <andre@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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id D1F9416A4CE
for <arch@freebsd.org>; 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 <arch@freebsd.org>; 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 <arch@freebsd.org>; Fri, 22 Oct 2004 23:42:49 +0200 (CEST)
(envelope-from phk@critter.freebsd.dk)
To: arch@freebsd.org
From: Poul-Henning Kamp <phk@phk.freebsd.dk>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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 <sys/kernel.h>
#include <sys/lock.h>
#include <sys/mutex.h>
-#include <machine/stdarg.h>
+#include <sys/proc.h>
#include <sys/errno.h>
#include <sys/time.h>
#include <geom/geom.h>
#include <geom/geom_int.h>
+#include <machine/stdarg.h>
+
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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <peter.lei@ieee.org>
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 <suz@kame.net>
References: <4177C8AD.6060706@freebsd.org>
<20041021153933.GK13756@empiric.icir.org> <4177E25E.804639E@freebsd.org>
<20041021213248.223cab2c.molter@tin.it> <x7r7nrgsol.wl%suz@crl.hitachi.co.jp>
In-Reply-To: <x7r7nrgsol.wl%suz@crl.hitachi.co.jp>
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 <randall@stewart.chicago.il.us>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <randall@stewart.chicago.il.us>
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 <peter.lei@ieee.org>
References: <4177C8AD.6060706@freebsd.org>
<20041021153933.GK13756@empiric.icir.org> <4177E25E.804639E@freebsd.org>
<20041021213248.223cab2c.molter@tin.it> <x7r7nrgsol.wl%suz@crl.hitachi.co.jp>
<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 <suz@kame.net>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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 <or> 815-342-5222(cell)
From owner-freebsd-arch@FreeBSD.ORG Sat Oct 23 13:16:40 2004
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <randall@stewart.chicago.il.us>
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 <matt@gsicomp.on.ca>
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 <bms@spc.org>
cc: freebsd-arch@freebsd.org
cc: Andre Oppermann <andre@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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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 <or> 815-342-5222(cell)
From owner-freebsd-arch@FreeBSD.ORG Sat Oct 23 13:17:24 2004
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <randall@stewart.chicago.il.us>
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 <molter@tin.it>
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 <andre@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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Oct 2004 13:17:25 -0000
Marco Molteni wrote:
> On Thu, 21 Oct 2004 Andre Oppermann <andre@freebsd.org> 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 <or> 815-342-5222(cell)
From owner-freebsd-arch@FreeBSD.ORG Sat Oct 23 13:20:46 2004
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <randall@stewart.chicago.il.us>
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" <rcarter@pinyon.org>
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 <rodrigc@crodrigues.org>
cc: freebsd-arch@freebsd.org
cc: Andre Oppermann <andre@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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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 <or> 815-342-5222(cell)
From owner-freebsd-arch@FreeBSD.ORG Sat Oct 23 13:24:12 2004
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <randall@stewart.chicago.il.us>
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 <andre@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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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 <or> 815-342-5222(cell)
From owner-freebsd-arch@FreeBSD.ORG Sat Oct 23 14:16:46 2004
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id B9DF116A4CF
for <freebsd-arch@freebsd.org>; 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 <freebsd-arch@freebsd.org>; 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 <andre@freebsd.org>)
by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP
for <randall@stewart.chicago.il.us>; 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 <andre@freebsd.org>
X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Randall Stewart <randall@stewart.chicago.il.us>
References: <4177C8AD.6060706@freebsd.org>
<20041021153933.GK13756@empiric.icir.org> <4177E25E.804639E@freebsd.org>
<20041021213248.223cab2c.molter@tin.it> <x7r7nrgsol.wl%suz@crl.hitachi.co.jp>
<4179ACB8.4020108@ieee.org> <417A572A.9080306@stewart.chicago.il.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
cc: Peter Lei <peter.lei@ieee.org>
cc: molter@tin.it
cc: freebsd-arch@freebsd.org
cc: SUZUKI Shinsuke <suz@kame.net>
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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 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 <randy@psg.com>
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 <peter.lei@ieee.org>
References: <4177C8AD.6060706@freebsd.org>
<4177E25E.804639E@freebsd.org>
<x7r7nrgsol.wl%suz@crl.hitachi.co.jp>
<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
<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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