Re: NTFS file system driver (update 3)

[Marco Gerards]

Bean <address@hidden> 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