Lines Matching refs:of

23 		 null-padded to a multiple of 4 bytes.
25 The order of inode traversal is described as "width-first" (not to be
26 confused with breadth-first); i.e. like depth-first but listing all of
38 	 regular file of non-zero st_size.
44 	padding to multiple of 4 bytes
46 The i'th <block_pointer> for a file stores the byte offset of the
47 *end* of the i'th <block> (i.e. one past the last byte, which is the
48 same as the start of the (i+1)'th <block> if there is one).  The first
52 The order of <file_data>'s is a depth-first descent of the directory
57 <block>: The i'th <block> is the output of zlib's compress function
58 applied to the i'th blksize-sized chunk of the input data.
59 (For the last <block> of the file, the input may of course be smaller.)
67 This kernel supports cramfs holes (i.e. [efficient representation of]
68 blocks in uncompressed data consisting entirely of NUL bytes), but by
87 (Block size in cramfs refers to the size of input data that is
104 require the least amount of change: just change `#define
107 kernels, not even necessarily kernels of the same architecture if
113 One part of that is addressing endianness.  The two options here are
115 endianness; kernel adapts at runtime'.  Little-endian wins because of
118 The cost of swabbing is changing the code to use the le32_to_cpu
123 The other part of making cramfs more sharable is choosing a block
137 The cost of option 1 is that kernels with a larger PAGE_CACHE_SIZE
140 The cost of option 2 relative to option 1 is that the code uses
141 variables instead of #define'd constants.  The gain is that people
142 with kernels having larger PAGE_CACHE_SIZE can make use of that if
147 e.g. get readpage to decompress to a buffer of size MAX_BLKSIZE (which
151 The main advantage of option 3 over 1, 2, is better compression.  The
157 Another cost of 2 and 3 over 1 is making mkcramfs use a different
167 by filename, so the expansion doesn't even have to be a multiple of 4