Hi Jared,
What happened to AXFS?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists
On Wed, 20 Aug 2008, Jared Hulbert wrote:
> --- /dev/null
> +++ b/fs/axfs/axfs_super.c
> +static int axfs_fill_region_data(struct super_block *sb,
> + struct axfs_region_desc *region, int force)
> +{
> + struct axfs_super *sbi = AXFS_SB(sb);
>
On Mon, 15 Sep 2008, Jared Hulbert wrote:
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
> 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 depe
On Mon, 15 Sep 2008, Jamie Lokier wrote:
This is all very interesting - I had no prior experience with NOR, so
didn't know that 0.6MB/s was slow. It's fast compared with older
EEPROMs after all, and had imagined that people wanting fast flash
would use NAND.
NAND is significantly faster whe
>> >> 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 :-)
Jared Hulbert wrote:
> > 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 ti
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 S29GL128N, which reads at about 0.6 MByte/s.
> >
> > By the way,
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 usi
> 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 t
On Tue, 2 Sep 2008, Jared Hulbert wrote:
> > However, there still are weird things going on, like `find' not seeing all
> > files and directories, or just aborting, and `ls -lR' showing actual file
> > contents in its output.
>
> Do you see this behavior for all builds for just the PS3?
The `find
>> 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 bloc
On Tue, 2 September 2008 09:44:19 -0700, Jared Hulbert wrote:
>
> 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 differen
> 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.
>
>
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 AxFS a try on PS3 (ppc64, always use big-endian 64-bit for testing
Hi Jared,
On Thu, 21 Aug 2008, Jared Hulbert wrote:
> > 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
> > al
/users/jehulber/axfs.git
>
> > Which platform(s) do you use for testing?
>
> ARM, x86
>
> > I gave AxFS a try on PS3 (ppc64, always use big-endian 64-bit for testing
> > new
> > code ;-).
>
> Smart. Hmmm, If only I had a PS3
I heard you got one? ;-)
> &
oc() attempts to
defragment by evicting everything.
Sure.
But that's fiddly to do right in general.
The natural thing for AXFS to do to support no-MMU FDPIC-ELF or
BFLT-XIP is store the code segment uncompressed and contiguous, and
the data segment however the filesystem prefers,
On Fri, 2008-08-22 at 09:51 -0700, Jared Hulbert wrote:
> Can you run mkfs.axfs on the same trivial directory on both ia32 and
> PPC64 and then get me the resulting images?
git.infradead.org is a big-endian box, and I know you have an account
there...
--
David Woodhouse
emory pressure while kmalloc() attempts to
defragment by evicting everything.
But that's fiddly to do right in general.
The natural thing for AXFS to do to support no-MMU FDPIC-ELF or
BFLT-XIP is store the code segment uncompressed and contiguous, and
the data segment however the file
Geert Uytterhoeven wrote:
From your good relationship with the s390 developers, I had hoped you would
have done some tests on s390 ;-)
Haha, we let you sort out the endianess issues first and then take the
easy path :-). We have'nt tried it yet so far.
--
To unsubscribe from this list: send the
/users/jehulber/axfs.git
>
> > Which platform(s) do you use for testing?
>
> ARM, x86
Ah, little endian.
>From your good relationship with the s390 developers, I had hoped you would
have done some tests on s390 ;-)
> > I gave AxFS a try on PS3 (ppc64, always use big-endian 64-b
On Fri, 22 Aug 2008, Will Marone wrote:
> Geert Uytterhoeven wrote:
> > I gave AxFS a try on PS3 (ppc64, always use big-endian 64-bit for testing
> > new
> > code ;-).
> > When mounting the image, I got the crash below:
> >
> > | attempt to access beyond end
Hi Jared,
Jared Hulbert wrote:
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 p
On Thu, Aug 21, 2008 at 2:45 PM, Jared Hulbert <[EMAIL PROTECTED]> wrote:
> All the block device code goes here.
>
> Signed-off-by: Jared Hulbert <[EMAIL PROTECTED]>
> ---
> diff --git a/fs/axfs/axfs_bdev.c b/fs/axfs/axfs_bdev.c
> new file mode 100644
> index
Geert Uytterhoeven wrote:
I gave AxFS a try on PS3 (ppc64, always use big-endian 64-bit for testing new
code ;-).
When mounting the image, I got the crash below:
| attempt to access beyond end of device
| loop0: rw=0, want=4920, limit=4912
| Unable to handle kernel paging request for data at
On Thursday 21 August 2008, Jared Hulbert wrote:
> 1) same mount point -
> I don't see how this works without an ioctl. I can't just make up
> files in my mounted filesystem. You expect the mounted version to
> match input to the mkfs. I'd not be happy with an ioctl. You can
> just read it.
>
in readdir
> 7. Indexed directories for fast lookup
> 8. NFS exporting
> 9. No need to cache entire metadata in memory
>
> Squashfs has been optimised for block-based rotating media like hard
> disks, CDROMS. AXFS has been optimised for flash based media. Squashfs
> will out
On Friday 22 August 2008, Jared Hulbert wrote:
> > 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...
Yes. And if y
On Friday 22 August 2008, you wrote:
> You mean to take this off list?
No, i replied to your mail that was sent just to me.
Putting everyone back on now
> > In 3, you create files with sysfs_create_file, and are fairly limited
> > with how you can use it. A structured file like you have in procfs
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 S29GL128N, which reads at about 0.6 MByte/s.
By the way, w
Jared Hulbert wrote:
> On Fri, Aug 22, 2008 at 11:13 AM, Jamie Lokier <[EMAIL PROTECTED]> wrote:
> > Greg Ungerer wrote:
> >> One thing for sure is that many people who do non-MMU setups
> >> are interested in XIP to get the space savings. These are very
> >> often small devices with very constrain
On Fri, Aug 22, 2008 at 11:13 AM, Jamie Lokier <[EMAIL PROTECTED]> wrote:
> Greg Ungerer wrote:
>> One thing for sure is that many people who do non-MMU setups
>> are interested in XIP to get the space savings. These are very
>> often small devices with very constrained RAM and flash. (For
>> whate
Greg Ungerer wrote:
> One thing for sure is that many people who do non-MMU setups
> are interested in XIP to get the space savings. These are very
> often small devices with very constrained RAM and flash. (For
> whatever it is worth single NOR flash only boards are common in
> these smaller form
>> So do I understand right that 3 bytes is your minimum size, and going
>> smaller than that would not be helpful? Otherwise I would assume that
>> storing a '5' should only take one byte instead of three.
Right. But you need 3 bytes to store the maximum value 0x0a
If we had:
0x
Greg Ungerer wrote:
>
> Jamie Lokier wrote:
> >Jared Hulbert wrote:
> >>The biggest improvement is in the way AXFS allows for each page to be XIP
> >>or
> >>not. First, a user collects information about which pages are accessed
> >>on a
> >
> Elsewhere in this maze of threads Arnd claimed to have tested the
> benefits of metadata compression - and it making little impact.
>
> My guess is that it would make a large impact if metadata would be a
> significant part of the filesystem image. Usually metadata is close
> enough to 0% to be
On Fri, 22 August 2008 18:08:51 +0100, Phillip Lougher wrote:
>
> Squashfs stores significantly more metadata than cramfs. Remember
> cramfs has no support for filesystems > ~ 16Mbytes, no inode timestamps,
> truncates uid/gids, no hard-links, no nlink counts, no hashed
> directories, no uniq
> 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 linux-embe
> 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 "unsubs
> 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;
>>+
Arnd Bergmann wrote:
On Friday 22 August 2008, Jared Hulbert wrote:
This implies for block devices that the entire filesystem metadata has to be
cached in RAM. This severely limits the size of AXFS filesystems when using
block devices, or the else memory usage will be excessive.
This is where
Arnd Bergmann wrote:
On Friday 22 August 2008, Phillip Lougher wrote:
This looks very nice, but could use some comments about how the data is
actually stored on disk. It took me some time to figure out that it actually
allows to do tail merging into compressed blocks, which I was about to sugges
On Friday 22 August 2008, Jared Hulbert wrote:
> > This implies for block devices that the entire filesystem metadata has to be
> > cached in RAM. This severely limits the size of AXFS filesystems when using
> > block devices, or the else memory usage will be excessive.
>
t; I gave AxFS a try on PS3 (ppc64, always use big-endian 64-bit for testing new
> code ;-).
Smart. Hmmm, If only I had a PS3
> When mounting the image, I got the crash below:
>
> | attempt to access beyond end of device
> | loop0: rw=0, want=4920, limit=4912
> | [c000
On Friday 22 August 2008, Geert Uytterhoeven wrote:
> I gave AxFS a try on PS3 (ppc64, always use big-endian 64-bit for testing new
> code ;-).
> When mounting the image, I got the crash below:
>
> | attempt to access beyond end of device
> | loop0: rw=0, want=4920, limit=
Hi Jared,
On Wed, 20 Aug 2008, Jared Hulbert wrote:
> I'd like to get a first round of review on my AXFS filesystem. This is a
> simple
> See http://axfs.sourceforge.net for more info.
The version in SVN seems to be slightly older than the one you submitted?
Which plat
On Wed, Aug 20, 2008 at 10:45:47PM -0700, Jared Hulbert wrote:
>+/**
>+ *
>+ * axfs_copy_block_data
>+ *
>+ * Description: Helper function to read data from block device
>+ *
>+ * Parameters:
>+ *(IN) sb - pointer to su
EL);
>+ if (!sbo)
>+ return -ENOMEM;
>+
>+ axfs_copy_metadata(sb, (void *)sbo, 0, sizeof(*sbo));
>+
>+ /* Do sanity checks on the superblock */
>+ if (be32_to_cpu(sbo->magic) != AXFS_MAGIC) {
>+ printk(KERN_ERR "
On Fri, 22 Aug 2008, Arnd Bergmann wrote:
> On Friday 22 August 2008, Jared Hulbert wrote:
> > If I have an array of u64 numbers tracking small numbers (a[0] = 1;
> > a[1] = 2;) just throwing that onmedia is a big waste.
> > (0x0001; 0x0002) Having different array types
> >
On Friday 22 August 2008, Jared Hulbert wrote:
> > This bytetable stuff looks overly complicated, both the data structure and
> > the access method. It seems like you are implementing your own custom
> > Huffman
> > compression with this.
> >
> > Is the reasonn for the bytetable just to pack numbe
block size in cramfs is smaller than in squashfs, but they both
have user selectable block sizes. I found the impact of compressed metadata
to be almost zero. I hacked up a mksquashfs to avoid tail merging, and found
that the image size for squashfs and cramfs is practically identical if you
use the sam
how AXFS works. Read
the [PATCH 00/10] thread again.
I agree, the profiling part is the sweet spot. Profiling should be in,
probably even selectable at runtime as opposed to a config-switch.
This way we could have it in enterprise distros that would'nt build
another kernel image for this.
Jared Hulbert wrote:
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 oc
er is
smaller. The confusion is probably because of the fact that this
copies extra crap to the page for tails.
Ah yes, that's where I got confused :) Glad to see AXFS uses tail packing.
Phillip
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
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
compression.
>
> The AXFS code is rather obscure but it doesn't look to me that it does tail
> merging. The following code wouldn't work if the block in question was a
> tail contained in a larger block. It assumes the block extends to the end
> of the compressed block (cbl
verely limits the size of AXFS filesystems when using
> block devices, or the else memory usage will be excessive.
This is where 64bit squashfs could be a better fit.
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to [EMAIL PRO
> 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 thin
On Friday 22 August 2008 00:13, Jared Hulbert wrote:
> > Agreed. I haven't had a good look through it yet, but at a glance it
> > looks pretty neat. The VM side of things looks pretty reasonable
> > (I fear XIP faulting might have another race or two, but that's a
> > core mm issue rather than file
ion. But tail merging (fragments in Squashfs
terminology) is obviously a major reason why Squashfs gets good compression.
The AXFS code is rather obscure but it doesn't look to me that it does
tail merging. The following code wouldn't work if the block in question
was a tail contained i
On Friday 22 August 2008 05:32, Jared Hulbert wrote:
> > Jared, nice work!
> > - would axfs be suitable as a filesystem on a ram disk?
>
> It could be. I plan on implementing support for brd. That might work
> nicely.
I was going to take a look at this too. With any luck
vfree(buff);
+ } else {
+ axfs_copy_metadata(sb, vaddr, fsoffset, size);
+ }
+
+ return 0;
From this it would appear that if the region data can't be mapped XIP
(i.e. it is compressed or on a block device), it is cached in its
entirety in RAM?
This implies for bloc
k is set to null\n");
+ }
+ if (inode->i_ino == *inode_number)
+ return 1; /* matches */
+ else
+ return 0; /* does not match */
+}
+
This implies inode_numbers are unique in AXFS? If so you can get rid of
the axfs_iget5_set/test logic.
Hi Jared,
Jared Hulbert wrote:
How does it fare with no MMU? Can the profiler and image builder lay
out the XIP pages in such a way that no-MMU mmaps can map those regions?
No complaint if not, it would be a nice bonus though.
Sorry. I don't believe it will work on no-MMU as is. That said
Jamie Lokier wrote:
Jared Hulbert wrote:
The biggest improvement is in the way AXFS allows for each page to be XIP or
not. First, a user collects information about which pages are accessed on a
compressed image for each mmap()ed region from /proc/axfs/volume0. That
'profile' is
> This bytetable stuff looks overly complicated, both the data structure and
> the access method. It seems like you are implementing your own custom Huffman
> compression with this.
>
> Is the reasonn for the bytetable just to pack numbers efficiently, or do you
> have a different intention?
It lo
> I think it would be much cleaner to do all these similar macro's as
> static inline functions.
Yeah. Been thinking about that.
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.or
>> +#define AXFS_PAGE_SIZE 4096
>
> What happens on systems where AXFS_PAGE_SIZE != PAGE_SIZE?
Right now, bad things I imagine. I meant to revisit this, there was
some reason during development for this, I don't remember. No reason
for AXFS_PAGE_SIZE I think.
--
To unsubscribe from this list: se
NAND, I understand that)
I don't know, I'm interested to find out. I just benchmarked that.
Actually it should work very well as a NAND-only fs. Also you do get
something like XIP with NAND. If you boot an XIP AXFS image on NAND
or a blkdev it will copy that XIP region into RAM and "
On Thursday 21 August 2008, Jared Hulbert wrote:
> So /sys/kernel/debug/axfs/volume0 would work?
>
> > 4) no profiling at all
> > The profiling code has certainly been useful to you during development,
> > and you should keep that code around for your own work on it,
>
On Thu, 21 Aug 2008, Arnd Bergmann wrote:
> On Thursday 21 August 2008, Jared Hulbert wrote:
> 4) no profiling at all
> The profiling code has certainly been useful to you during development,
> and you should keep that code around for your own work on it,
> but maybe you should not push that upstre
On Thursday 21 August 2008, Jared Hulbert wrote:
> > Have you seen any benefit of the rwsem over a simple mutex? I would guess
> > that you can never even get into the situation where you get concurrent
> > readers since I haven't found a single down_read() in your code, only
> > downgrade_write()
ust
> define some file_operations with read/write callbacks and call
> debugfs_create_file with the path name below /sys/kernel/debug.
no /proc.
thanks for the explanation.
So /sys/kernel/debug/axfs/volume0 would work?
> 4) no profiling at all
> The profiling code has certai
> Have you seen any benefit of the rwsem over a simple mutex? I would guess
> that you can never even get into the situation where you get concurrent
> readers since I haven't found a single down_read() in your code, only
> downgrade_write()
We implemented a rwsem here because you can get concurre
On Thursday 21 August 2008, Jared Hulbert wrote:
> 1) same mount point -
> I don't see how this works without an ioctl. I can't just make up
> files in my mounted filesystem. You expect the mounted version to
> match input to the mkfs. I'd not be happy with an ioctl. You can
> just read it.
On Thu, 21 Aug 2008, Jared Hulbert wrote:
> > Use DEFINE_MUTEX and drop the mutex_init() down in the init function.
>
> okay. by drop you mean delete?
Yes.
> > axfs_uncompress_init() and axfs_uncompress_exit() are only called during
> > init and exit of the module, no need for the initialized
On Thu, 21 Aug 2008, Sven Wegener wrote:
> On Wed, 20 Aug 2008, Jared Hulbert wrote:
>
> > 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
On Thu, Aug 21, 2008 at 4:39 AM, Arnd Bergmann <[EMAIL PROTECTED]> wrote:
> On Thursday 21 August 2008, David Woodhouse wrote:
>> On Thu, 2008-08-21 at 10:44 +0200, Carsten Otte wrote:
>> >
>> > Exporting profiling data for a file system in another file system
>> > (/proc) seems not very straigtfor
On Thu, 21 Aug 2008, Leon Woestenberg wrote:
> On Thu, Aug 21, 2008 at 4:19 PM, Jared Hulbert <[EMAIL PROTECTED]> wrote:
> >> FWIW, I'm not sure it's a good idea to name this new filesystem AXFS.
> >> People are almost certainly going to confuse it with XFS
> What if the use-case did not cover all cases of XIP use?
>
> If a compressed page is attempted to be executed, will the filesystem
> fall back to decompression to RAM and execution from RAM, or will this
> result in a faulty system?
No this will not result in a faulty system. It is perfectly
ac
> Use DEFINE_MUTEX and drop the mutex_init() down in the init function.
okay. by drop you mean delete?
> axfs_uncompress_init() and axfs_uncompress_exit() are only called during
> init and exit of the module, no need for the initialized variable and the
> functions can be annotated with __init a
> 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 c
Hello Jared,
On Thu, Aug 21, 2008 at 4:19 PM, Jared Hulbert <[EMAIL PROTECTED]> wrote:
>> FWIW, I'm not sure it's a good idea to name this new filesystem AXFS.
>> People are almost certainly going to confuse it with XFS despite
>
People that care about their files
uld call this NAND or eMMC the
"secondary device" because the primary device is the NOR.
Assuming my NOR was at /dev//mtd2 and my NAND at /dev/mtd5. I would
call the following to mount such a system:
mount -t axfs -o second_dev=/dev/mtd5 /dev/mtd2 /mnt/axfs
--
To unsubscribe from this list: s
> FWIW, I'm not sure it's a good idea to name this new filesystem AXFS.
> People are almost certainly going to confuse it with XFS despite
> the filesystems being aimed at diammetrically opposed ends of the
> storage spectrum. ;)
In principle I think you are right. AXFS and
On Thursday 21 August 2008, Jared Hulbert wrote:
> > One thing that would be really nice is if you could add fake-write
> > support in the way that I proposed for cramfs a few months ago.
> > This would make axfs much more interesting for another set of
> > users, and kee
On Thu, Aug 21, 2008 at 01:24:22PM +0200, Arnd Bergmann wrote:
> On Thursday 21 August 2008, Jared Hulbert wrote:
> > The Kconfig edits and Makefiles required for AXFS.
> >
> > Signed-off-by: Jared Hulbert <[EMAIL PROTECTED]>
>
> If you split out this patch sep
> One thing that would be really nice is if you could add fake-write
> support in the way that I proposed for cramfs a few months ago.
> This would make axfs much more interesting for another set of
> users, and keep cramfs a really simple example file system.
Did that get m
> Agreed. I haven't had a good look through it yet, but at a glance it
> looks pretty neat. The VM side of things looks pretty reasonable
> (I fear XIP faulting might have another race or two, but that's a
> core mm issue rather than filesystem specific).
How might I design a test to flush those b
> How does it fare with no MMU? Can the profiler and image builder lay
> out the XIP pages in such a way that no-MMU mmaps can map those regions?
>
> No complaint if not, it would be a nice bonus though.
Sorry. I don't believe it will work on no-MMU as is. That said you
_could_ tweak the mkfs t
On Wed, 2008-08-20 at 22:45 -0700, Jared Hulbert wrote:
> +#define AXFS_GET_BYTETABLE_VAL(desc,index) \
> + axfs_bytetable_stitch(((struct
> axfs_region_desc)(desc)).table_byte_depth,\
> + (u8 *)((struct axfs_region_desc)(desc)).virt_addr, index)
> +
> +#define AXFS_GET_NODE_TYPE(sbi,node_index)
On Thursday 21 August 2008, Nick Piggin wrote:
> On Thursday 21 August 2008 20:25, Carsten Otte wrote:
> > Jared Hulbert wrote:
> > > I'd like to get a first round of review on my AXFS filesystem.
> >
> > I like the general approach of it. It's much more f
On Thu, 21 Aug 2008, Artem Bityutskiy wrote:
> On Wed, 2008-08-20 at 22:46 -0700, Jared Hulbert wrote:
> > + err = zlib_inflateReset(&stream);
> > + if (err != Z_OK) {
> > + printk(KERN_ERR "zlib_inflateReset error %d\n", err);
> > + zlib_inflateEnd(&stream);
> > +
On Thursday 21 August 2008, Jared Hulbert wrote:
> +static inline u64 axfs_bytetable_stitch(u8 depth, u8 *table, u64 index)
> +{
> + u64 i;
> + u64 output = 0;
> + u64 byte = 0;
> + u64 j;
> + u64 bits;
> +
> + for (i = 0; i < depth; i++) {
> + j =
On Thursday 21 August 2008, Jared Hulbert wrote:
> + array_index = AXFS_GET_INODE_ARRAY_INDEX(sbi, ino_number);
> + array_index += page->index;
> +
> + node_index = AXFS_GET_NODE_INDEX(sbi, array_index);
> + node_type = AXFS_GET_NODE_TYPE(sbi, array_index);
> +
> + if
On Wed, 2008-08-20 at 22:46 -0700, Jared Hulbert wrote:
> + err = zlib_inflateReset(&stream);
> + if (err != Z_OK) {
> + printk(KERN_ERR "zlib_inflateReset error %d\n", err);
> + zlib_inflateEnd(&stream);
> + zlib_inflateInit(&stream);
> + }
Jared,
On Thursday 21 August 2008, David Woodhouse wrote:
> On Thu, 2008-08-21 at 10:44 +0200, Carsten Otte wrote:
> >
> > Exporting profiling data for a file system in another file system
> > (/proc) seems not very straigtforward to me. I think it is worth
> > considering to export this information via
On Thursday 21 August 2008, Jared Hulbert wrote:
> +/* functions in other axfs files
> **/
> +int axfs_get_sb(struct file_system_type *, int, const char *, void *,
> + struct vfsmount *);
> +void axfs_kill_super(str
KERNEL__ and user space parts in your header.
Function declarations clearly don't belong in the user visible parts.
I suggest you only leave on-disk data structure definitions and user
interfaces in the user-visible include/linux/axfs.h file, and move
all internal interfaces to fs/axfs/axfs.h.
1 - 100 of 129 matches
Mail list logo
