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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080120122945.GC2613>