Re: [RFC/PATCH 2/5] mm/fs: execute in place (V2)

[Carsten Otte]

Christoph Hellwig wrote:

>On Wed, May 18, 2005 at 04:56:42PM +0200, Carsten Otte wrote:
>  
>
>>I do plainly agree that this would make the code more readable here.
>>But it has a significant downside:
>>Once you have a different set of file operations for either case, you
>>also need to have a different file_operations struct in each individual
>>filesystem using this. Also, this moves the check "do we have xip today?"
>>from here to the filesystem that needs to decide which file operations
>>struct to use.
>>Looking forward, there may be multiple filesystems using this which
>>leads to duplicating the need for this check.
>>    
>>
>
>I don't think that's much of a problem.  The filesystem has a new file_operations
>instance and decided at read_inode time which one to use.  You already have different
>address_space operations and a different truncate anyway.
>
>  
>
Yea, but in addition to the multiplication for the check it would duplicate
significant part of filemap:
- generic_file_read           => xip_file_read
- generic_file_aio_read    => xip_file_aio_read
- __generic_file_aio_read => __xip_file_aio_read
- generic_file_sendfile     => xip_file_sendfile
- generic file_readv          => xip_file_readv
- generic_file_write          => xip_file_write
- generic_file_aio_write_nolock => xip_file_write_nolock
- __generic_file_write_nolock => __xip_file_write_nolock
- generic_file_write_nolock => xip_file_write_nolock
- generic_file_aio_write => xip_file_aio_write
- generic_file_mmap => xip_file_mmap
- generic_file_readonly_mmap => xip_file_readonly_mmap

All changes to these functions would need to be mirrored, and the binary
kernel images with xip enabled would grow by the size of those functions.

But given that the copies of those function would be equivalent to their
original, I honestly think that duplicating them is worse then splitting
the read/write pathes at where handling is in fact different:
- mapping_read
- nopage
- generic_file_write
- truncate page

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/