From: Carsten Otte <cotte@de.ibm.com>
To: Jared Hulbert <jaredeh@gmail.com>
Cc: Christoph Hellwig <hch@infradead.org>,
linux-mm@kvack.org, cotte@de.ibm.com
Subject: Re: Fwd: Re: VM_XIP Request for comments
Date: Fri, 28 Oct 2005 14:43:42 +0200 [thread overview]
Message-ID: <43621CFE.5080900@de.ibm.com> (raw)
In-Reply-To: <200510281155.03466.christian@borntraeger.net>
> I can't find CONFIG_XIP. But I assume you are talking about
> filemap_xip.c and Documentation/filesystems/xip.txt.
Actually the thing consists of three parts:
- a block device that does implement the direct_access method. so far
the only driver that does that is drivers/s390/block/dcssblk.c. We
are aware that this one needs cleanup ;-).
- extension to good old ext2 filesystem that does implement get_xip_page
address space operation. Uses direct_access block device operation.
- the stuff in mm/filemap_xip.c which actually does the job (read,write,
mmap etc.) by calling get_xip_page address space operation.
> I don't know. The code and discussions about it looked very big-iron
> DSCC specific but now on second pass it was meant to more generic. If
> I can learn this infrastructure then maybe this will work.
The only part that is architecture specific is the block device driver.
Both the ext2 extensions and filemap_xip are architecture independent.
> So I'm supposed to create a function in the target fs that gets
> plugged into get_xip_page(). Then I call that function to create an
> proper XIP'ed page in my mmap() and fread() calls. I could use the
> first arg of get_xip_page() to pass in the start address of the cramfs
> volume and the second the offset of the page in the file I want to
> map.
>
> Is that about right?
The first step would be to write a block device driver that allows to
mount your memory backed storage thing [flash chip?]. The block device
driver needs to implement the direct_access method. Now you can mount
ext2 filesystems with -o xip.
Ext2 does not support compression, and all files are xip once you
select -o xip. Would be interresting to have a filesystem that can do
both xip and compression on a per-file basis, but as far as I can tell
the basic layering should also work fine with such filesystem: should
work with any block device, file operations in filemap_xip.c can be
used for those files that are xip [and not compressed].
--
Carsten Otte
IBM Linux technology center
ARCH=s390
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next parent reply other threads:[~2005-10-28 12:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200510281155.03466.christian@borntraeger.net>
2005-10-28 12:43 ` Carsten Otte [this message]
2005-10-28 16:33 ` Fwd: Re: VM_XIP Request for comments Jared Hulbert
2005-11-02 9:03 ` 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=43621CFE.5080900@de.ibm.com \
--to=cotte@de.ibm.com \
--cc=carsteno@de.ibm.com \
--cc=hch@infradead.org \
--cc=jaredeh@gmail.com \
--cc=linux-mm@kvack.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.