From: Carsten Otte <cotte@freenet.de>
To: suparna@in.ibm.com
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
schwidefsky@de.ibm.com, akpm@osdl.org,
Christoph Hellwig <hch@infradead.org>
Subject: Re: [RFC/PATCH 2/4] fs/mm: execute in place (3rd version)
Date: Tue, 24 May 2005 16:34:34 +0200 [thread overview]
Message-ID: <42933B7A.3060206@freenet.de> (raw)
In-Reply-To: <20050524133211.GA4896@in.ibm.com>
Suparna Bhattacharya wrote:
>On Tue, May 24, 2005 at 01:09:24PM +0200, Carsten Otte wrote:
>
>
>BTW, your calculation between your previous patch and current one is a
>reasonable argument for not reverting back to the earlier version, but
>then that wasn't what I was suggesting. Hope that was clear. Not complicating
>the common path in filemap.c with if (xip) branches is a good idea.
>
>
True, there is more copied code obviously. I was just comparing
against the soloution to unify things that I found.
>Right now you have chosen what is possibly the lesser of two evils,
>but having had to end up modifying code in multiple places in read/write and
>inadvertant bugs introduced thus in the past and paid for over time :(
>has made me quite wary of code duplication in this particular area, simple
>as it seems.
>
>I'll take a closer look and see if I can think of any other way to abstract
>this better. Maybe the long term solution is what Christoph suggested
>in terms of collapsing interfaces.
>
>
Maintenance effort is a good point. Changes would need to be applied
to both versions, which don't differ too much today.
Embedded folks will likely figure they also need the reverse path to
return references (like put_xip_page()), and indication of required access
(read/write) to make this work with flash chips.
Therefore I guess those two versions to differ more in the future,
making it hard to think about a soloution unifying the code paths
in a sane way so that it will work out for flash in the end.
As for me, I did not find a better one than in version one/two. If you
figure a good one, I will be happy to work on its implementation.
next prev parent reply other threads:[~2005-05-24 14:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1116866094.12153.12.camel@cotte.boeblingen.de.ibm.com>
2005-05-23 17:30 ` [RFC/PATCH 2/4] fs/mm: execute in place (3rd version) Carsten Otte
2005-05-24 9:30 ` Suparna Bhattacharya
2005-05-24 10:28 ` Jörn Engel
2005-05-24 11:09 ` Carsten Otte
2005-05-24 13:32 ` Suparna Bhattacharya
2005-05-24 14:34 ` Carsten Otte [this message]
2005-05-25 17:51 ` Badari Pulavarty
2005-05-26 13:22 ` Suparna Bhattacharya
2005-05-26 13:19 ` Carsten Otte
2005-05-26 16:43 ` Badari Pulavarty
2005-05-26 13:29 ` Carsten Otte
2005-05-28 9:05 ` Christoph Hellwig
2005-05-24 17:01 ` Carsten Otte
2005-05-28 9:08 ` Christoph Hellwig
2005-05-23 17:30 ` [RFC/PATCH 3/4] ext2: " Carsten Otte
2005-05-23 17:30 ` [RFC/PATCH 4/4] 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=42933B7A.3060206@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 \
--cc=suparna@in.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).