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
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
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
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
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()
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()
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 this.
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
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
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 write in
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
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
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 code
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
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
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
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
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
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
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 easily
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 actual
write
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
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 -
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
burned
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
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
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 aligned.
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? For the
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 device
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 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 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 systems. The
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 be
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
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
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 -
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
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
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
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
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:
---
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:
> -
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
>
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
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
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?
Using
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:
- on
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:
---
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 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 used
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
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 handle
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
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
--- 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
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
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
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
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
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
>
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
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
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.
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
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
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
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?
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
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
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 work
1 - 100 of 146 matches
Mail list logo
