Bean <[EMAIL PROTECTED]> writes: > On Sun, Jul 29, 2007 at 10:31:57PM +0200, Marco Gerards wrote: >> GRUB already has caching code, see kern/disk.c. So this just can >> better be removed, to fix deallocation issues, etc. > > The caching is mainly for decompression. In NTFS, the basic decompression unit > is 4096 bytes. If we don't cache the result, we may need to run the > decompression routine again.
Oh right, I thought you were caching disk blocks. In this case it is sane. :-) >> I still don't really get it ;-). You wrote an NTFS implementation >> which is supposed to know about the disk layout of a file. So why do >> you need a hook to peek how NTFS works? This sounds a bit circular to >> me. >> >> I am sure there is another and cleaner way to fix this. This solution >> can not be used inside a filesystem implementation because it might >> break other code. Can you please look for some other solution? > > In fact, the hook comes from above. > > In grub_ntfs_read: > > mft->read_hook=file->read_hook; > > > In read_data, the hook is enabled: > > ctx->comp.disk=at->mft->data->disk; > > ... > > ctx->comp.disk->read_hook=at->mft->read_hook; > > ... > > ctx->comp.disk->read_hook = 0; > > In read_run_list, the hook is disabled temporarily: > > save_hook = ctx->comp.disk->read_hook; > ctx->comp.disk->read_hook = 0; > run = find_attr (ctx->attr, (unsigned char) *ctx->attr->attr_cur); > ctx->comp.disk->read_hook = save_hook; > > I could have used read_hook as a function parameter, but it seems a waste > of memory becasue it's accessed deep within the function calls. Can you pass it around inside one of the structs? I understand that passing it around as parameter is not really nice. The problem is that this might actually break other code, which I want to prevent. I hope you see this might become a serious problem? -- Marco _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
