From owner-freebsd-geom@FreeBSD.ORG Fri Jan 21 13:02:47 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B07531065674 for ; Fri, 21 Jan 2011 13:02:47 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 6433C8FC08 for ; Fri, 21 Jan 2011 13:02:47 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PgGdZ-0007Xh-QD for freebsd-geom@freebsd.org; Fri, 21 Jan 2011 14:02:45 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 21 Jan 2011 14:02:45 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 21 Jan 2011 14:02:45 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Fri, 21 Jan 2011 14:02:32 +0100 Lines: 8 Message-ID: References: <20110119125407.be7669b9.ray@dlink.ua> <20110120084955.GD1716@garage.freebsd.pl> <20110120122644.9a38974c.ray@dlink.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: X-Enigmail-Version: 1.1.2 Cc: freebsd-embedded@freebsd.org Subject: Re: GEOM_LZMA X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 13:02:47 -0000 On 20/01/2011 16:51, Adrian Chadd wrote: > Well, creating a generic geom_compress module shouldn't increase the > size by all that much. It's just a few function pointers that point at > the decompression class. The rest of the format is the same, right? > (ie, how it's broken into chunks, the chunks are separately > compressed, etc.) I think they are talking about the size of the kernel :)