Date: Sun, 20 Jan 2008 07:29:45 -0500 From: David Schultz <das@FreeBSD.ORG> To: "Mikhail T." <mi@aldan.algebra.com> Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: bin/96393: [libz] [patch] assembler implementations for libz on i386 Message-ID: <20080120122945.GC2613@VARK.MIT.EDU> In-Reply-To: <200801200951.29254@Misha> References: <200707051510.l65FAAEp090370@freefall.freebsd.org> <20080115061921.GA48648@VARK.MIT.EDU> <200801200951.29254@Misha>
index | next in thread | previous in thread | raw e-mail
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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080120122945.GC2613>