Lines Matching +full:as +full:- +full:is
2 --------------------------
7 a given directory are contiguous, as this is used by readdir).
9 All data is currently in host-endian format; neither mkcramfs nor the
22 Filename. Not generally null-terminated, but it is
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
28 same order as `ls -AUR' (but without the /^\..*:$/ directory header
29 lines); put another way, the same order as `find -type d -exec
30 ls -AU1 {} \;'.
34 exist, speeds up user-space directory sorts, etc.
38 regular file of non-zero st_size.
42 (where nblocks = (st_size - 1) / blksize + 1)
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 When the CRAMFS_FLAG_EXT_BLOCK_POINTERS capability bit is set, each
53 <block_pointer>'s top bits may contain special flags as follows:
56 The block data is not compressed and should be copied verbatim.
61 aligned to a 4-byte boundary. The block size is either blksize
62 if CRAMFS_BLK_FLAG_UNCOMPRESSED is also specified, otherwise
63 the compressed data length is included in the first 2 bytes of
64 the block data. This is used to allow discontiguous data layout
68 The order of <file_data>'s is a depth-first descent of the directory
69 tree, i.e. the same order as `find -size +0 \( -type f -o -type l \)
70 -print'.
73 <block>: The i'th <block> is the output of zlib's compress function
74 applied to the i'th blksize-sized chunk of the input data if the
75 corresponding CRAMFS_BLK_FLAG_UNCOMPRESSED <block_ptr> bit is not set,
76 otherwise it is the input data directly.
80 <block>s are merely byte-aligned, not generally u32-aligned.
82 When CRAMFS_BLK_FLAG_DIRECT_PTR is specified then the corresponding
84 the previous/next blocks. In that case it is minimally u32-aligned.
85 If CRAMFS_BLK_FLAG_UNCOMPRESSED is also specified then the size is always
86 blksize except for the last block which is limited by the file length.
87 If CRAMFS_BLK_FLAG_DIRECT_PTR is set and CRAMFS_BLK_FLAG_UNCOMPRESSED
88 is not set then the first 2 bytes of the block contains the size of the
89 remaining block data as this cannot be determined from the placement of
94 -----
100 with -z if you want it to create files that can have holes in them.
104 -----
106 The cramfs user-space tools, including mkcramfs and cramfsck, are
114 ----------
116 (Block size in cramfs refers to the size of input data that is
125 Currently, mkcramfs #define's PAGE_SIZE as 4096 and uses that
126 for blksize, whereas Linux-2.3.39 uses its PAGE_SIZE, which in
127 turn is defined as PAGE_SIZE (which can be as large as 32KB on arm).
128 This discrepancy is a bug, though it's not clear which should be
131 One option is to change mkcramfs to take its PAGE_SIZE from
135 is that the generated cramfs cannot always be shared between different
137 PAGE_SIZE is subject to change between kernel versions
142 One part of that is addressing endianness. The two options here are
143 `always use little-endian' (like ext2fs) or `writer chooses
144 endianness; kernel adapts at runtime'. Little-endian wins because of
145 code simplicity and little CPU overhead even on big-endian machines.
147 The cost of swabbing is changing the code to use the le32_to_cpu
148 etc. macros as used by ext2fs. We don't need to swab the compressed
152 The other part of making cramfs more sharable is choosing a block
166 The cost of option 1 is that kernels with a larger PAGE_SIZE
167 value don't get as good compression as they can.
169 The cost of option 2 relative to option 1 is that the code uses
170 variables instead of #define'd constants. The gain is that people
175 Option 3 is easy to implement if we don't mind being CPU-inefficient:
178 Getting read_folio to read into all the covered pages is harder.
180 The main advantage of option 3 over 1, 2, is better compression. The
181 cost is greater complexity. Probably not worth it, but I hope someone
182 will disagree. (If it is implemented, then I'll re-use that code in
186 Another cost of 2 and 3 over 1 is making mkcramfs use a different
187 block size, but that just means adding and parsing a -b option.
191 ----------
193 Given that cramfs will probably be used for CDs etc. as well as just