[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200808211424.31966.arnd@arndb.de>
Date: Thu, 21 Aug 2008 14:24:31 +0200
From: Arnd Bergmann <arnd@...db.de>
To: jaredeh@...il.com
Cc: Linux-kernel@...r.kernel.org, linux-embedded@...r.kernel.org,
linux-mtd <linux-mtd@...ts.infradead.org>,
Jörn Engel <joern@...fs.org>,
tim.bird@...sony.com, cotte@...ibm.com, nickpiggin@...oo.com.au
Subject: Re: [PATCH 03/10] AXFS: axfs.h
On Thursday 21 August 2008, Jared Hulbert wrote:
> +static inline u64 axfs_bytetable_stitch(u8 depth, u8 *table, u64 index)
> +{
> + u64 i;
> + u64 output = 0;
> + u64 byte = 0;
> + u64 j;
> + u64 bits;
> +
> + for (i = 0; i < depth; i++) {
> + j = index * depth + i;
> + bits = 8 * (depth - i - 1);
> + byte = table[j];
> + output += byte << bits;
> + }
> + return output;
> +}
> +
> +#define AXFS_GET_BYTETABLE_VAL(desc,index) \
> + axfs_bytetable_stitch(((struct axfs_region_desc)(desc)).table_byte_depth,\
> + (u8 *)((struct axfs_region_desc)(desc)).virt_addr, index)
> +
This bytetable stuff looks overly complicated, both the data structure and
the access method. It seems like you are implementing your own custom Huffman
compression with this.
Is the reasonn for the bytetable just to pack numbers efficiently, or do you
have a different intention?
Did you see a significant size benefit over simply storing all metadata as
uncompressed data structures like in cramfs?
Have you considered storing simple dentry/inode data in node_type==Compressed
nodes?
Arnd <><
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists