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 16:56:42 +0200 [thread overview]
Message-ID: <428B57AA.2030006@freenet.de> (raw)
In-Reply-To: <20050518142707.GA23162@infradead.org>
Christoph Hellwig wrote:
> I don't like this read split at all. Please just define a completely
>
>separate entry point for read, xip_file_read except for verifying the
>iovecs you don't share any code.
>Similar please add a separate xip_file_mmap.
>Dito with xip_file_write.
>
>
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.
>
>
>>diff -ruN linux-git/mm/filemap.h linux-git-xip/mm/filemap.h
>>--- linux-git/mm/filemap.h 1970-01-01 01:00:00.000000000 +0100
>>+++ linux-git-xip/mm/filemap.h 2005-05-17 18:33:57.792451512 +0200
>>@@ -0,0 +1,141 @@
>>+/*
>>+ * linux/mm/filemap.h
>>+ *
>>+ * Copyright (C) 2005 IBM Corporation
>>
>>
>
>I think just adding an IBM copyright isn't fair. Just copy it from
>filemap.c
>
>
Agreed.
>
>You should probably use page_check_address(). Currently it's static in rmap.c,
>but that could be changed.
>
>
Good point. This was derived from try_to_unmap_one before that one
was added. Btw: Should'nt this function move to rmap.c anyway?
next prev parent reply other threads:[~2005-05-18 14:56 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 [this message]
2005-05-18 15:00 ` Christoph Hellwig
2005-05-18 15:31 ` Carsten Otte
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=428B57AA.2030006@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).