Date: Tue, 2 Mar 2010 10:47:48 +0200 From: Alexandr Rybalko <ray@dlink.ua> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: geom@freebsd.org, embedded@freebsd.org, hackers@freebsd.org Subject: Re: GEOM_ULZMA Message-ID: <20100302104748.0f27136c.ray@dlink.ua> In-Reply-To: <20100302071736.GF1946@garage.freebsd.pl> References: <20100219163644.da89e882.ray@dlink.ua> <20100302071736.GF1946@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On Tue, 2 Mar 2010 08:17:36 +0100 Pawel Jakub Dawidek <pjd@FreeBSD.org> wrote: >> On Fri, Feb 19, 2010 at 04:36:44PM +0200, Alexandr Rybalko wrote: >> > Hi, >> > I wrote a module GEOM_ULZMA (such as GEOM_UZIP, but compression with lzma), [...] >> >> Wouldn't it be better to modify geom_uzip to be universal decompression >> class with various algorithms implemented as plugins? >> This is bascially what I did for the LABEL class - before we had VOL_FFS >> class only for UFS labels. Yes, you are right, but problem where in kernel code store LZMA code, and what to do with different versions of it? >> >> > [...] in connection with this is an issue best left lzma >> > code in the file "geom_ulzma.c" or store lzma library separately. If separately, then where better? >> >> Definiatelly separately, not sure where. There is ongoing discussion >> somwhere on importing this algorithm to the base for tar(1) to use, it >> would be best to have only one copy of code in the tree. I have already said, that it would be good for embedded platforms have only one copy of the code for the kernel and userland. It is not thought of how done it. >> >> -- >> Pawel Jakub Dawidek http://www.wheelsystems.com >> pjd@FreeBSD.org http://www.FreeBSD.org >> FreeBSD committer Am I Evil? Yes, I Am! -- Рыбалко Александр Консультант D-Link Украина
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100302104748.0f27136c.ray>