Hi guys, I just looked over liu's code as of today, and it looks pretty good; obviously you have gotten a huge amount of work done already! However, in the short term, we will most likely not have memory management -- malloc/free -- available in the core (making that possible is part of KlausM's project, but I want to decouple those.) The code currently uses malloc() in disklab.c, which is used from cache.c. The solution there is pretty simple: add a pointer to get getoneblk() prototype for a target buffer, then use a chunk of .bss memory for the cache. As previously discussed, we really want the cache system to handle multiple block sizes (first of all, because hard disks are going to be changing from 512 to 4K sectors over the next several years, and second because filesystems like ext2 have metadata which is more logically cached on the filesystem block level): static struct cache_struct cache_head, cache[MAX_CACHE_ENTRIES]; static uint8_t cache_data[65536]; static int cache_block_size; static int cache_entries; void cache_init(int block_size) { struct cache_struct *prev, *cur; uint8_t *data = cache_data; int i; cache_block_size = block_size; cache_entries = sizeof cache_data / block_size; if (cache_entries > MAX_CACHE_ENTRIES) cache_entries = MAX_CACHE_ENTRIES; cache_head.prev = &cache[cache_entries-1]; cache_head.prev->next = &cache_head; prev = &cache_head; for (i = 0; i < cache_entries; i++) { cur = cache[i]; cur->block = 0; cur->prev = prev; prev->next = cur; cur->data = data; data += block_size; prev = cur++; } } There is also one use of malloc() in search_dos_dir, but it looks like it can simply be replaced by an automatic (stack) variable, either a simple array or using alloca(). (It also doesn't look like it gets freed in the current code, which is another good hint that it should be replaced by an automatic allocation.) -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.