Lines Matching +full:input +full:- +full:depth

2 --------------------------
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)
61 	aligned to a 4-byte boundary. The block size is either blksize
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'.
74 applied to the i'th blksize-sized chunk of the input data if the
76 otherwise it is the input data directly.
77 (For the last <block> of the file, the input may of course be smaller.)
80 <block>s are merely byte-aligned, not generally u32-aligned.
84 the previous/next blocks. In that case it is minimally u32-aligned.
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
126 for blksize, whereas Linux-2.3.39 uses its PAGE_SIZE, which in
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.
175 Option 3 is easy to implement if we don't mind being CPU-inefficient:
182 will disagree.  (If it is implemented, then I'll re-use that code in
187 block size, but that just means adding and parsing a -b option.
191 ----------