From owner-freebsd-arch@FreeBSD.ORG  Wed May 28 11:35:59 2003
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 7C4F837B401
	for <arch@freebsd.org>; Wed, 28 May 2003 11:35:59 -0700 (PDT)
Received: from rhombus.znep.com (sense-sea-MegaSub-1-507.oz.net
	[216.39.145.253])
	by mx1.FreeBSD.org (Postfix) with ESMTP id D2F9F43F75
	for <arch@freebsd.org>; Wed, 28 May 2003 11:35:58 -0700 (PDT)
	(envelope-from marcs@znep.com)
Received: by rhombus.znep.com (Postfix, from userid 1000)
	id DD25E1A291; Wed, 28 May 2003 11:35:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by rhombus.znep.com (Postfix) with ESMTP
	id C2F7A1AAA5; Wed, 28 May 2003 11:35:57 -0700 (PDT)
Date: Wed, 28 May 2003 11:35:57 -0700 (PDT)
From: Marc Slemko <marcs@znep.com>
To: Igor Sysoev <is@rambler-co.ru>
In-Reply-To: <Pine.BSF.4.21.0305282219570.51226-100000@is>
Message-ID: <Pine.NEB.4.53.0305281125460.28029@rhombus.znep.com>
References: <Pine.BSF.4.21.0305282219570.51226-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
cc: arch@freebsd.org
Subject: Re: sendfile(2) SF_NOPUSH flag proposal
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, 28 May 2003 18:35:59 -0000

On Wed, 28 May 2003, Igor Sysoev wrote:

> No, I do want these flags because they resolve the problem of partially
> filled packets.  I believe that this problem can be solved without a fixing
> the sendfile() implementation.

As people have said a few times now, making an API change to work
around a bug in the implementation of sendfile() simply doesn't
make any sense, especially when there are other workarounds you
can use until it is fixed that impose a very low overhead.  No one
is saying it can't be solved without fixing sendfile(), we are just
saying it _shouldn't_ be because any API changes will be around for
a very long time.