On Fri, Jan 21, 2011 at 03:46:36PM +0200, Alexandr Rybalko wrote:
> On Fri, 21 Jan 2011 14:02:32 +0100
> Ivan Voras <[email protected]> wrote:
> 
> >> 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 :)
> 
> Exact match :)
> 
> But really, gzip in most cases already compiled into kernel (my not) and 
> anyway have small footprint.
> 
> So I done join GEOM_UZIP + GEOM_ULZMA module, called GEOM_ULZMA yet. 
> 
> Module name open for discussion :)
> Since they must have short and understandable name.
> Maybe GEOM_COMPR,
> maybe full GEOM_COMPRESSION,
> maybe GEOM_REDUCE,
> etc.

What's wrong with GEOM_COMPRESS? We already have equally long or longer
class names:

        GEOM_LINUX_LVM
        GEOM_MOUNTVER
        GEOM_MULTIPATH
        GEOM_SUNLABEL

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
[email protected]                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!

Attachment: pgp3PAwBBaeia.pgp
Description: PGP signature

Reply via email to