Jared Hulbert wrote:
We would still need to add the kernel mapping though.
But that's handled by ioremap()ing it right?
That's right. Ioremap will give you a permanent kernel space mapping
until you do iounmap() again.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On 6/15/07, Carsten Otte <[EMAIL PROTECTED]> wrote:
Nick Piggin wrote:
> Carsten Otte wrote:
>> The current xip stack relies on having struct page behind the memory
>> segment. This causes few impact on memory management, but occupies
>> some more memory. The cramfs patch chose to modify copy on
If you can write code that doesn't need any struct pages that would make
life a bit easier, since we wouldn't need any pseudo memory hotplug code
that just adds struct pages.
That was my gut feel too. However, it seems from Carsten and Jörn
discussion of read/write XIP on Flash (and some new Ph
Nick Piggin wrote:
Carsten Otte wrote:
The current xip stack relies on having struct page behind the memory
segment. This causes few impact on memory management, but occupies
some more memory. The cramfs patch chose to modify copy on write in
order to deal with vmas that don't have struct page
On Fri, Jun 15, 2007 at 11:22:21AM +0200, Carsten Otte wrote:
> Jared Hulbert wrote:
> >>If you're interrested in using the later for xip without
> >>struct page, I would volounteer to go ahead and implement this?
> >I'm very interested in this.
> Good. Let me see if I can come up with a patch on t
Jared Hulbert wrote:
An alternative approach, which does not need to have struct page at
hand, would be to use the nopfn vm operations struct. That one would
have to rely on get_xip_pfn.
Of course! Okay now I'm begining to understand.
Sorry, but I think I was educated yesterday that ->fault() (
An alternative approach, which does not need to have struct page at
hand, would be to use the nopfn vm operations struct. That one would
have to rely on get_xip_pfn.
Of course! Okay now I'm begining to understand.
The current path would then be deprecated.
Why? Wouldn't both paths be valid
Jared Hulbert wrote:
Nick Piggin wrote:
> The question is, why is that not enough (I haven't looked at these
> patches enough to work out if there is anything more they provide).
I think, it just takes trying things out. From reading the code, I
think this should work well for the filemap_xip cod
Nick Piggin wrote:
> The question is, why is that not enough (I haven't looked at these
> patches enough to work out if there is anything more they provide).
I think, it just takes trying things out. From reading the code, I
think this should work well for the filemap_xip code with no struct page.
On Sat, 9 June 2007 09:55:15 +0200, Carsten Otte wrote:
> Jörn Engel wrote:
>
> >Either that or using standard mtd->read() and mtd->write() calls. I see
> >some advantages to mtd->write() in particular, as the device driver
> >needs some notification to trigger unmap_page_range() before the actua
Justin Treon wrote:
--- Carsten Otte <[EMAIL PROTECTED]> wrote:
The nice thing about this approach is: we use page->count and rmap,
both already exist and are perfectly suited for our purpose.
The downside: We need mem_map[] struct page entries behind all memory
segments. Nowerdays we can easil
Jörn Engel wrote:
Whenever writes/erases to the device happen, the device driver would
need to call a function like
/**
* unmap_page_range - remove all mapping to the given range of an address space
* @mapping - the address space in question
* @start_index - index of the first page in the ran
The downside: We need mem_map[] struct page entries behind all memory
segments. Nowerdays we can easily create those via vmem_map/sparsemem.
Opinions?
Frankly this is going to be mostly relevant on ARM architectures at
least at first. Maybe I'm missing something but I don't see that
sparemem i
Whenever writes/erases to the device happen, the device driver would
need to call a function like
/**
* unmap_page_range - remove all mapping to the given range of an address space
* @mapping - the address space in question
* @start_index - index of the first page in the range
* @no_pages - nu
Carsten Otte wrote:
- temporary references (for read/write syscalls and friends) get
retrieved via get_xip_page and returned again via to-be-invented
put_page/page_cache_release
Doh! Meant to state: returned again via stock
put_page/page_cache_release rather then inventing something new.
-
To
Jörn Engel wrote:
Nitbit: Sooner or later the point/unpoint should get replaced by
something with page granularity. Something also needs to keep lists of
mapped pages and invalidate them whenever the device is written to.
That could be done in the filesystem or device driver. I believe the
devi
On Fri, 8 June 2007 17:15:26 +0100, Christoph Hellwig wrote:
>
> I wouldn't call it that. The interface should stay the same except that
> write operations are not supported. In mtd_info you'd just have
> point/unpoint and read/read_oob but no write operations and all the backing
> code wouldn't
On Fri, Jun 08, 2007 at 09:11:47AM -0700, Jared Hulbert wrote:
> >On Fri, Jun 08, 2007 at 09:05:32AM -0700, Jared Hulbert wrote:
> >> Okay so we need some driver that opens/closes this ROM. This has been
> >> done from the dcss block device but that doesn't make sense for most
> >> embedded system
On Fri, Jun 08, 2007 at 09:05:32AM -0700, Jared Hulbert wrote:
> Okay so we need some driver that opens/closes this ROM. This has been
> done from the dcss block device but that doesn't make sense for most
> embedded systems. The MTD allows for this with point(),unpoint().
> That should work jus
On Fri, Jun 08, 2007 at 09:05:32AM -0700, Jared Hulbert wrote:
> Okay so we need some driver that opens/closes this ROM. This has been
> done from the dcss block device but that doesn't make sense for most
> embedded systems. The MTD allows for this with point(),unpoint().
> That should work just
On 6/8/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
On Fri, Jun 08, 2007 at 09:59:20AM +0200, Carsten Otte wrote:
> Christoph Hellwig wrote:
> >Jared's patch currently does ioremap on mount (and no iounmap at all).
> >That mapping needs to move from the filesystem to the device driver.
> The
On 6/8/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
On Thu, Jun 07, 2007 at 01:34:12PM -0700, Jared Hulbert wrote:
> >And we'll need that even when using cramfs. There's not way we'd
> >merge a hack where the user has to specify a physical address on
> >the mount command line.
>
> Why not?
On Thu, 7 June 2007 15:59:00 -0700, Jared Hulbert wrote:
>
> Gee I think it seems logfs would be a better choice. Jffs2 and
> ubifs(jffs3) for that matter combine node and node header in series
> which means your data nodes aren't aligned to page boundarys. Logfs
> nodes could be more easily alig
On Thu, 7 June 2007 22:15:19 +0100, Christoph Hellwig wrote:
>
> With the filemap_xip.c helpers adding xip support to any filesystem
> is pretty trivial for the highlevel filesystem operations. The only
> interesting bit is the lowlevel code (the get_xip_page method and
> the others Carsten menti
On Fri, Jun 08, 2007 at 09:59:20AM +0200, Carsten Otte wrote:
> Christoph Hellwig wrote:
> >Jared's patch currently does ioremap on mount (and no iounmap at all).
> >That mapping needs to move from the filesystem to the device driver.
> The device driver needs to do ioremap on open(), and iounmap()
On Fri, Jun 08, 2007 at 09:50:17AM +0200, Carsten Otte wrote:
> I see your poing with regard to layering, and I agree to it.
> In order to do ioremap/iounmap at least we need a counterpart
> put_xip_page thing to do iounmap in that path. Our dcss segments on
> 390 did not raise that requirement:
Christoph Hellwig wrote:
Jared's patch currently does ioremap on mount (and no iounmap at all).
That mapping needs to move from the filesystem to the device driver.
The device driver needs to do ioremap on open(), and iounmap() on
release. That's effectively what our block driver does.
-
To uns
Christoph Hellwig wrote:
We can have a simpler variant as a start if we really want. But we
need to pass it through the mtd layer. There is a reason we have this
thing called devices drivers, and we don't want to add knowledge of
ioremap to the filesystems and have users find out physical addre
Christoph Hellwig wrote:
And for thus just wanting to take a quick glance, this is the
diff vs an out of tree cramfs where uncompress.c and cramfs_fs_sb.h
are merged into inode.c:
Mkay, I am convinced. Either cramfs should be based on a block device
that does have direct_access() for xip, or the
On Thu, Jun 07, 2007 at 01:34:12PM -0700, Jared Hulbert wrote:
> >And we'll need that even when using cramfs. There's not way we'd
> >merge a hack where the user has to specify a physical address on
> >the mount command line.
>
> Why not? For the use case in question the user usually manually
>
On Fri, Jun 08, 2007 at 09:17:18AM +0200, Carsten Otte wrote:
> Christoph Hellwig wrote:
> >On Thu, Jun 07, 2007 at 07:07:54PM +0200, Carsten Otte wrote:
> >>I've had a few beer long discussion with Joern Engel and David
> >>Woodhouse on this one. To cut a long discussion short: the current XIP
>
Christoph Hellwig wrote:
On Thu, Jun 07, 2007 at 07:07:54PM +0200, Carsten Otte wrote:
I've had a few beer long discussion with Joern Engel and David
Woodhouse on this one. To cut a long discussion short: the current XIP
infrastructure is not sufficient to be used on top of mtd. We'd need
some
If if were actually talking about complex filesystem I'd agree. But
the cramfs xip patch posted here touches about 2/3 of the number of
lines that cramfs has in total.
Fair enough. But look at the complexity rather than number of lines.
It adds tedium to the cramfs_fill_super and one extra lev
I've had a few beer long discussion with Joern Engel and David
Woodhouse on this one. To cut a long discussion short: the current XIP
infrastructure is not sufficient to be used on top of mtd. We'd need
some extenstions:
- on get_xip_page() we'd need to state if we want the reference
read-only or
On Thu, Jun 07, 2007 at 02:11:44PM -0700, Jared Hulbert wrote:
> >that even more important doesn't require pulling in
> >the whole block layer which is especially important for embedded
> >devices at the lower end of the scala.
>
> Good point. That is a big oversight. Though I would prefer to ha
that even more important doesn't require pulling in
the whole block layer which is especially important for embedded
devices at the lower end of the scala.
Good point. That is a big oversight. Though I would prefer to handle
that in the same fs rather than fork.
I still think it'd be even be
On 6/7/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
On Thu, Jun 07, 2007 at 07:07:54PM +0200, Carsten Otte wrote:
> I've had a few beer long discussion with Joern Engel and David
> Woodhouse on this one. To cut a long discussion short: the current XIP
> infrastructure is not sufficient to be
On 6/7/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
On Thu, Jun 07, 2007 at 08:37:07PM +0100, Christoph Hellwig wrote:
> The code is at http://verein.lst.de/~hch/cramfs-xip.tar.gz.
And for thus just wanting to take a quick glance, this is the
diff vs an out of tree cramfs where uncompress.c
On Thu, Jun 07, 2007 at 08:37:07PM +0100, Christoph Hellwig wrote:
> The code is at http://verein.lst.de/~hch/cramfs-xip.tar.gz.
And for thus just wanting to take a quick glance, this is the
diff vs an out of tree cramfs where uncompress.c and cramfs_fs_sb.h
are merged into inode.c:
--- ./inode.
On Thu, Jun 07, 2007 at 07:07:54PM +0200, Carsten Otte wrote:
> I've had a few beer long discussion with Joern Engel and David
> Woodhouse on this one. To cut a long discussion short: the current XIP
> infrastructure is not sufficient to be used on top of mtd. We'd need
> some extenstions:
> - o
On Wed, Jun 06, 2007 at 11:26:38AM -0700, Jared Hulbert wrote:
> >FYI: Cartsten had an xip fs for s390 aswell, and that evolved into
> >the filemap.c bits after a lot of rework an quite a few round of
> >review.
>
> Right. So now we leverage this filemap_xip.c in cramfs. Why is this a
> problem
Christoph Hellwig wrote:
The right way to architect xip for flash-based devices is to implement
a generic get_xip_page for mtd-based devices and integrate that into
an existing flash filesystem or write a simple new flash filesystem
tailored to that use case.
I've had a few beer long discussion w
--- Jared Hulbert <[EMAIL PROTECTED]> wrote:
> The vma->flags = 1875 = 0x753
>
> This is:
> VM_READ
> VM_WRITE
> VM_MAYREAD
> VM_MAYEXEC
> VM_GROWSDOWN
> VM_GROWSUP
> VM_PFNMAP
>
There was a mistake in Jared's previous post in this
thread. The vm_flags were already in hex, i.e. 0x1875
The settin
On Wed, Jun 06, 2007 at 11:40:58AM -0700, Jared Hulbert wrote:
> > The embedded people already use them
> >on flash which is a little dumb, but now we add even more cludge for
> >a non-block based access.
>
> Please justify your assertion that using cramfs on flash is dumb.
> What would be not dum
On 6/6/07, Carsten Otte <[EMAIL PROTECTED]> wrote:
Jared Hulbert wrote:
> (2) failed with the following messages. (This wasn't really busybox.
> It was xxd, not statically link, hence the issue with ld.so)
Could you try to figure what happend to subject page before? Was it
subject to copy on wri
The embedded people already use them
on flash which is a little dumb, but now we add even more cludge for
a non-block based access.
Please justify your assertion that using cramfs on flash is dumb.
What would be not dumb? In an embedded system with addressable Flash
the linear addressing cramf
On Wed, Jun 06, 2007 at 09:07:16AM -0700, Jared Hulbert wrote:
> I estimate something on the order 5-10 million Linux phones use
> something similar to these patches. I wonder if there are that many
> provable users of of the simple cramfs. This is where the community
> has taken cramfs.
This i
On Wed, Jun 06, 2007 at 06:15:04PM +0200, Carsten Otte wrote:
> The clear advantage of using cramfs on embedded platforms over using the
> ext2 stuff is, that one can choose per-file whether it should be
> compressed or xip.
> The real key is, to put both our ext2 stuff and the cramfs xip on a
> c
On Wed, Jun 06, 2007 at 09:07:16AM -0700, Jared Hulbert wrote:
> I estimate something on the order 5-10 million Linux phones use
> something similar to these patches. I wonder if there are that many
> provable users of of the simple cramfs. This is where the community
> has taken cramfs.
This is
Christoph Hellwig wrote:
I might be a little late in the discussion, but I somehow missed this
before. Please don't add this xip support to cramfs, because the
whole point of cramfs is to be a simple _compressed_ filesystem,
and we really don't want to add more complexity to it. Please
use some
On 6/6/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
On Wed, Jun 06, 2007 at 08:17:43AM -0700, Richard Griffiths wrote:
> Too late :) The XIP cramfs patch is widely used in the embedded Linux
> community and has been used for years. It fulfills a need for a small
> XIP Flash file system. Hence
On 6/6/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
I might be a little late in the discussion, but I somehow missed this
before. Please don't add this xip support to cramfs, because the
whole point of cramfs is to be a simple _compressed_ filesystem,
and we really don't want to add more com
On Wed, Jun 06, 2007 at 08:17:43AM -0700, Richard Griffiths wrote:
> Too late :) The XIP cramfs patch is widely used in the embedded Linux
> community and has been used for years. It fulfills a need for a small
> XIP Flash file system. Hence our interest in getting it or some
> variation into the m
On Wed, 2007-06-06 at 12:33 +0100, Christoph Hellwig wrote:
> I might be a little late in the discussion, but I somehow missed this
> before. Please don't add this xip support to cramfs, because the
> whole point of cramfs is to be a simple _compressed_ filesystem,
> and we really don't want to ad
Jared Hulbert wrote:
(2) failed with the following messages. (This wasn't really busybox.
It was xxd, not statically link, hence the issue with ld.so)
Could you try to figure what happend to subject page before? Was it
subject to copy on write? With what flags has this vma been mmaped?
thanks
I might be a little late in the discussion, but I somehow missed this
before. Please don't add this xip support to cramfs, because the
whole point of cramfs is to be a simple _compressed_ filesystem,
and we really don't want to add more complexity to it. Please
use something like the existing ext
On 6/4/07, Carsten Otte <[EMAIL PROTECTED]> wrote:
Nick Piggin wrote:
> The question is, why is that not enough (I haven't looked at these
> patches enough to work out if there is anything more they provide).
I think, it just takes trying things out. From reading the code, I
think this should wor
Nick Piggin wrote:
The question is, why is that not enough (I haven't looked at these
patches enough to work out if there is anything more they provide).
I think, it just takes trying things out. From reading the code, I
think this should work well for the filemap_xip code with no struct page.
A
Jared Hulbert wrote:
> The current xip stack relies on having struct page behind the memory
> segment. This causes few impact on memory management, but occupies some
> more memory. The cramfs patch chose to modify copy on write in order to
> deal with vmas that don't have struct page behind.
> So
> The current xip stack relies on having struct page behind the memory
> segment. This causes few impact on memory management, but occupies some
> more memory. The cramfs patch chose to modify copy on write in order to
> deal with vmas that don't have struct page behind.
> So far, Hugh and Linus h
Carsten Otte wrote:
The current xip stack relies on having struct page behind the memory
segment. This causes few impact on memory management, but occupies some
more memory. The cramfs patch chose to modify copy on write in order to
deal with vmas that don't have struct page behind.
So far, Hu
Yes you can, but I won't have access to a PXA270 for a few weeks. I
assume you don't see the issue if you static link busybox?
I don't know.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger
On Thu, 2007-05-24 at 13:22 -0700, Jared Hulbert wrote:
> On 5/22/07, Richard Griffiths <[EMAIL PROTECTED]> wrote:
> > Venerable cramfs fs Linear XIP patch originally from MontaVista, used in
> > the embedded Linux community for years, updated for 2.6.21. Tested on
> > several systems with NOR Flas
On 5/22/07, Richard Griffiths <[EMAIL PROTECTED]> wrote:
Venerable cramfs fs Linear XIP patch originally from MontaVista, used in
the embedded Linux community for years, updated for 2.6.21. Tested on
several systems with NOR Flash. PXA270, TI OMAP2430, ARM Versatile and
Freescale iMX31ADS.
Whe
Jared Hulbert wrote:
To me, it looks like this
work can be modified to use filemap_xip.
How?
First, get a struct page behind the subject file system image. A good
idea to get there is to use vmem_map, which allows have a
discontiguous mem_map array in virtual storage. Then add the memory
seg
Richard Griffiths (wrs) wrote:
One question I have is the difference in the two models. If I understand
correctly the filemap_xip expects the ext2 to mount as XIP while the
Linear Cramfs only enables XIP for apps that have the sticky bit set.
Hence the Application XIP moniker.
Does the filemap_xi
To me, it looks like this
work can be modified to use filemap_xip.
How?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tu
On Wed, 2007-05-23 at 09:51 +0200, Carsten Otte wrote:
> Andrew Morton wrote:
> > But we'd expected and hoped that flash-based XIP would be able to use
> > the existing xip infrastructure, in mm/filemap_xip.c. Not possible?
> Thanks for the heads up Andrew. Reading the cramfs patch, I've found a
On Tuesday 22 May 2007 23:09:39 Richard Griffiths wrote:
> Venerable cramfs fs Linear XIP patch originally from MontaVista, used in
> the embedded Linux community for years, updated for 2.6.21. Tested on
> several systems with NOR Flash. PXA270, TI OMAP2430, ARM Versatile and
> Freescale iMX31ADS.
Andrew Morton wrote:
But we'd expected and hoped that flash-based XIP would be able to use
the existing xip infrastructure, in mm/filemap_xip.c. Not possible?
Thanks for the heads up Andrew. Reading the cramfs patch, I've found a
lot of similarities between the current mainline xip stack and th
On Tue, 2007-05-22 at 15:49 -0700, Andrew Morton wrote:
> On Tue, 22 May 2007 15:09:39 -0700
> Richard Griffiths <[EMAIL PROTECTED]> wrote:
>
> > Venerable cramfs fs Linear XIP patch originally from MontaVista, used in
> > the embedded Linux community for years, updated for 2.6.21. Tested on
> > s
On Tue, 22 May 2007 15:09:39 -0700
Richard Griffiths <[EMAIL PROTECTED]> wrote:
> Venerable cramfs fs Linear XIP patch originally from MontaVista, used in
> the embedded Linux community for years, updated for 2.6.21. Tested on
> several systems with NOR Flash. PXA270, TI OMAP2430, ARM Versatile an
Venerable cramfs fs Linear XIP patch originally from MontaVista, used in
the embedded Linux community for years, updated for 2.6.21. Tested on
several systems with NOR Flash. PXA270, TI OMAP2430, ARM Versatile and
Freescale iMX31ADS.
---
Richard
---
Signed-off-by: Zumeng Chen <[EMAIL PROTECTED]>
73 matches
Mail list logo
