linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
To: Carsten Otte <cotte@freenet.de>
Cc: David Woodhouse <dwmw2@infradead.org>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	schwidefsky@de.ibm.com, akpm@osdl.org
Subject: Re: [RFC/PATCH 0/5] add execute in place support
Date: Thu, 12 May 2005 10:57:41 +0200	[thread overview]
Message-ID: <20050512085741.GA16361@wohnheim.fh-wedel.de> (raw)
In-Reply-To: <42823450.8030007@freenet.de>

On Wed, 11 May 2005 18:35:28 +0200, Carsten Otte wrote:
> >
> Yes and no. For execute in place to work proper, you need an
> allignment of data to page boundaries "on disk" (or on flash)
> just like you have when mmap()ing to userland.
> Before choosing second extended, I also looked at some
> flash/rom filesystems. But I was unable to identify one that
> alligns the data proper (and does not compress things or
> such). The ext family with block size == PAGE_SIZE does
> fullfill that requirement once the "block device" starts on page
> boundary.
> On the other hand I believe that a filesystem specificaly
> designed for flash can provide less metadata overhead then
> second extended. Would also be interresting in our use-case
> on s390.

In principle, both the block device abstraction and the mtd
abstraction fit your bill.  But jffs2 doesn't, so no in-kernel fs
could make use of a xip-aware mtd abstraction.

Patching jffs2 for xip looks like a major effort, at best, and utterly
insane at worst.  I'd prefer not to go down that path.

Jörn

-- 
Optimizations always bust things, because all optimizations are, in
the long haul, a form of cheating, and cheaters eventually get caught.
-- Larry Wall 
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2005-05-12  8:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-11 14:29 [RFC/PATCH 0/5] add execute in place support Carsten Otte
2005-05-11 16:19 ` David Woodhouse
2005-05-11 16:35   ` Carsten Otte
2005-05-12  8:57     ` Jörn Engel [this message]
2005-05-12  9:10       ` Carsten Otte
2005-05-12  9:43       ` David Woodhouse
2005-06-01  9:33         ` Coywolf Qi Hunt
2005-06-01 11:31           ` Jörn Engel
2005-06-01 10:12 ` Coywolf Qi Hunt
2005-06-01 12:06   ` Arnd Bergmann
2005-06-01 13:39     ` Jörn Engel
2005-06-01 14:03       ` Carsten Otte
2005-06-01 14:10         ` Jörn Engel

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=20050512085741.GA16361@wohnheim.fh-wedel.de \
    --to=joern@wohnheim.fh-wedel.de \
    --cc=akpm@osdl.org \
    --cc=cotte@freenet.de \
    --cc=dwmw2@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).