Lines Matching refs:a

5 a bit looser, e.g. it doesn't care if the <file_data> items are
7 a given directory are contiguous, as this is used by readdir).
23 		 null-padded to a multiple of 4 bytes.
27 a directory's entries before recursing down its subdirectories: the
33 allows cramfs_lookup to return more quickly when a filename does not
37 	One <file_data> for each file that's either a symlink or a
46 The i'th <block_pointer> for a file stores the byte offset of the
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
78 Each <block> may be a different size.  (See <block_pointer> above.)
117 compressed at a time.  It's intended to be somewhere around
128 This discrepancy is a bug, though it's not clear which should be
152 The other part of making cramfs more sharable is choosing a block
163 It's easy enough to change the kernel to use a smaller value than
166 The cost of option 1 is that kernels with a larger PAGE_SIZE
176 e.g. get readpage to decompress to a buffer of size MAX_BLKSIZE (which
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.
194 silicon ROMs, it might make sense to expand the inode a little from
196 by filename, so the expansion doesn't even have to be a multiple of 4