I know. It wasn't my intention to introduce it but as I said in my first
patch I've done a porting of this code from 2.6.10 and to remove it I
need time to analyze well the code to avoid deadlock and so on. If
someone would like to help me I'd really appreciate it. However I see
the use of
+/* init_mm.page_table_lock must be held before calling! */
+static void pram_page_writeable(unsigned long addr, int rw)
+{
+ pgd_t *pgdp;
+ pud_t *pudp;
+ pmd_t *pmdp;
+ pte_t *ptep;
+
+ pgdp = pgd_offset_k(addr);
+ if (!pgd_none(*pgdp)) {
+
NAND is significantly faster when writing than NOR, read speed is of the
same magnitude, possibly slower in many cases.
Right.
Specifically, read bandwidth is on the same order of magnitude.
However the read latency of NAND is a couple orders of magnitude
higher (100ns vs 20,000ns) so it
I'm using Spansion MirrorBit S29GL128N, which reads at about 0.6 MByte/s.
If you are using a GL, you'll probably find our P33 a good fit and at
competitive prices to GL as I understand it. That's I think 50Mhz.
What's a GL? Never heard of it - all I can think of is OpenGL :-)
S29_GL_128N
I think the fast in fast synchronous gives it away :-)
Yes, I suppose it does.
I'm using Spansion MirrorBit S29GL128N, which reads at about 0.6 MByte/s.
I think you should get more like an order of magnitude higher Get
an expert to look at your timings in the bootloader. Make sure things
On Fri, Aug 22, 2008 at 11:43 AM, Jamie Lokier [EMAIL PROTECTED] wrote:
Jamie Lokier wrote:
Jared Hulbert wrote:
What kind of NOR you using? That is not what I measure with fast
synchronous burst NOR's.
I think the fast in fast synchronous gives it away :-)
I'm using Spansion MirrorBit
I found what's wrong.
The size of an AxFS image created by mkfs.axfs is always n*4096+4 bytes large.
So when it wants to check the magic value in the last 4 bytes, the block layer
tries to read a whole 512-byte sector, which fails for loop-mounted images.
If you test on real FLASH,
How is one expected to read those last 4 bytes of a loopbacked file?
Are they unreadable? We can add the padding. I am just wondering if
this is a bug or a known limitation in the loopback handling or if
there is a different safer way of reading block devs with truncated
last blocks.
The version in SVN seems to be slightly older than the one you submitted?
Oops. Okay I must have neglected to sync at the very end. Thanks.
I forgot, there is also a git repo at
git://git.infradead.org/users/jehulber/axfs.git
Which platform(s) do you use for testing?
ARM, x86
I gave
mismatch between documentation and implementation WRT the function name ;)
oops.
+{
+ struct axfs_super *sbi = AXFS_SB(sb);
+ u64 boffset = AXFS_FSOFFSET_2_DEVOFFSET(sbi, fsoffset);
+ u64 blocks;
+ u64 blksize = sb-s_blocksize;
+ unsigned long dst;
+ unsigned long
Squashfs and AXFS should be seen as complementary filesystems, and there
should be room in the Linux kernel for both.
Exactly. We had different design assumptions. One is not _better_
than the other, they are just different.
--
To unsubscribe from this list: send the line unsubscribe
It certainly sounds like something for your medium-term TODO list,
although I wouldn't think of it as a show-stopper.
Maybe. It more of a feature rather than a bug. It makes stat() and
such fast. The trade off is RAM...
--
To unsubscribe from this list: send the line unsubscribe
I like the general approach of it. It's much more flexible than the ext2
extension I've done, and the possibility to select XIP vs. compression per
page is really really neat. I can imagine that people will prefer this over
the ext2 implementation on s390. It is unclear to me how the secondary
If you want support for multiple decompression algorithms, you can switch
from using zlib_inflate*() directly to calling zlib through the crypto API.
Then you can call crypto_alloc_comp() with the correct decompression algorithm
name.
For squashfs, I had to modify only ca. 40 lines of code.
That would be enough I think. If you could manually select
which files are contiguous-and-uncompressed that would be
useful for some too here.
So If you don't have an MMU when do you call -fault? Does the
noMMU code just loop through -fault()ing all the pages in an mmap()?
One thing for
Squashfs has much larger block sizes than cramfs (last time I looked it was
limited to 4K blocks), and it compresses the metadata which helps to get
better compression. But tail merging (fragments in Squashfs terminology) is
obviously a major reason why Squashfs gets good compression.
The
I assume compressed blocks can be larger than PAGE_CACHE_SIZE? This suffers
from the rather obvious inefficiency that you decompress a big block
PAGE_CACHE_SIZE, but only copy one PAGE_CACHE_SIZE page out of it. If
multiple files are being read simultaneously (a common occurrence), then
We'll need this for AXFS. The equivalent function in filemap.c is exported.
Signed-off-by: Jared Hulbert [EMAIL PROTECTED]
---
include/linux/mm.h |4
mm/filemap_xip.c |3 ++-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
The AXFS header.
Signed-off-by: Jared Hulbert [EMAIL PROTECTED]
---
diff --git a/include/linux/axfs.h b/include/linux/axfs.h
new file mode 100644
index 000..87af84a
--- /dev/null
+++ b/include/linux/axfs.h
@@ -0,0 +1,360 @@
+/*
+ * Advanced XIP File System for Linux - AXFS
+ * Readonly
This is the main filesystem logic.
Signed-off-by: Jared Hulbert [EMAIL PROTECTED]
---
diff --git a/fs/axfs/axfs_inode.c b/fs/axfs/axfs_inode.c
new file mode 100644
index 000..cbf3dd1
--- /dev/null
+++ b/fs/axfs/axfs_inode.c
@@ -0,0 +1,488 @@
+/*
+ * Advanced XIP File System for Linux - AXFS
The many different devices AXFS can mount to and the various
dual device mounting schemes are supported here.
Signed-off-by: Jared Hulbert [EMAIL PROTECTED]
---
diff --git a/fs/axfs/axfs_super.c b/fs/axfs/axfs_super.c
new file mode 100644
index 000..5efab38
--- /dev/null
+++ b/fs/axfs
While we use mtd_super.c for most MTD mounting there are several things
we do here to interface with the MTD devices.
Signed-off-by: Jared Hulbert [EMAIL PROTECTED]
---
diff --git a/fs/axfs/axfs_mtd.c b/fs/axfs/axfs_mtd.c
new file mode 100644
index 000..35c8a98
--- /dev/null
+++ b/fs/axfs
22 matches
Mail list logo
