From: Carsten Otte <cotte@freenet.de>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
schwidefsky@de.ibm.com, akpm@osdl.org
Subject: Re: [RFC/PATCH 2/5] mm/fs: execute in place (V2)
Date: Wed, 18 May 2005 17:31:13 +0200 [thread overview]
Message-ID: <428B5FC1.3090704@freenet.de> (raw)
In-Reply-To: <20050518150053.GA24389@infradead.org>
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
next prev parent reply other threads:[~2005-05-18 15:31 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1116422644.2202.1.camel@cotte.boeblingen.de.ibm.com>
2005-05-18 13:53 ` [RFC/PATCH 1/5] bdev: execute in place (V2) Carsten Otte
2005-05-18 14:27 ` Christoph Hellwig
2005-05-18 15:36 ` Carsten Otte
2005-05-18 15:37 ` Christoph Hellwig
2005-05-18 13:53 ` [RFC/PATCH 2/5] mm/fs: " Carsten Otte
2005-05-18 14:27 ` Christoph Hellwig
2005-05-18 14:56 ` Carsten Otte
2005-05-18 15:00 ` Christoph Hellwig
2005-05-18 15:31 ` Carsten Otte [this message]
2005-05-18 15:36 ` Christoph Hellwig
2005-05-18 15:50 ` Carsten Otte
2005-05-18 15:53 ` Christoph Hellwig
2005-05-18 13:53 ` [RFC/PATCH 3/5] ext2: " Carsten Otte
2005-05-18 13:53 ` [RFC/PATCH 4/5] loop: " Carsten Otte
2005-05-18 14:28 ` Christoph Hellwig
2005-05-18 14:38 ` Carsten Otte
2005-05-18 13:54 ` [RFC/PATCH 5/5] madvice/fadvice: " Carsten Otte
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=428B5FC1.3090704@freenet.de \
--to=cotte@freenet.de \
--cc=akpm@osdl.org \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=schwidefsky@de.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).