From owner-freebsd-bugs@FreeBSD.ORG Sun Jan 20 12:31:02 2008 Return-Path: Delivered-To: freebsd-bugs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9CB216A418 for ; Sun, 20 Jan 2008 12:31:02 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.freebsd.org (Postfix) with ESMTP id A42D013C46A for ; Sun, 20 Jan 2008 12:31:02 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.14.2/8.14.1) with ESMTP id m0KCTjK1004971; Sun, 20 Jan 2008 07:29:45 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.14.2/8.14.1/Submit) id m0KCTjD9004970; Sun, 20 Jan 2008 07:29:45 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Sun, 20 Jan 2008 07:29:45 -0500 From: David Schultz To: "Mikhail T." Message-ID: <20080120122945.GC2613@VARK.MIT.EDU> Mail-Followup-To: "Mikhail T." , freebsd-bugs@FreeBSD.ORG References: <200707051510.l65FAAEp090370@freefall.freebsd.org> <20080115061921.GA48648@VARK.MIT.EDU> <200801200951.29254@Misha> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200801200951.29254@Misha> Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: bin/96393: [libz] [patch] assembler implementations for libz on i386 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2008 12:31:03 -0000 On Sun, Jan 20, 2008, Mikhail T. wrote: > вівторок 15 січень 2008, David Schultz, Ви написали: > = Have you considered submitting these patches to the vendor? > > I have and I did :) The assembly-code is included in the vendor's release, but > in the part of it, which we do not import. The vendor has a contrib/ > subdirectory, where various assembler-implementations are kept. > > The vendor would not maintain those, however... Because the assembler code > needs to know the offsetts of various fields in the libz structures, it must > rely on the offsets-generating auxiliary C-program, which is not included in > the original patch submitted. Hmm, sorry, but I don't think we should be in the business of supporting complex optimizations to vendor code that the vendor himself won't support. It would take a substantial amount of effort to verify that the changes are (a) correct and (b) faster, and things could break in subsequent imports. It looks like you've put a considerable amount of thought into these optimizations, though, and I'd hate to see that go to waste. Perhaps the best thing to do is to put this in as a port, if it isn't already. That way people who want your optimized libz can install it easily, but there's less pressure on others to keep it maintained.