Geert Uytterhoeven wrote:
On Thu, 21 Aug 2008, Charles Manning wrote:
Luckily APIs for drivers (the most common stuff that people work on) don't
change that much, and the interfaces are reasonably clear. If you want some
hell then try working on file systems :-).
Really? So how come so few c
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
Jared Hulbert wrote:
The memcpy in question copies a c_node to the page. The len is either
the max length of a c_node and size of the buffer I'm copying to
(PAGE_CACHE_SIZE) or it is the difference between the beginning of the
c_node in the c_block and the end of the c_block, whichever is
smal
> 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
> 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.
>
>
> 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?
That is correct.
> This implies for block devices that the entire filesystem metadata has to be
> cached in RAM. This severely limits the s
On Thu, 2008-08-21 at 21:53 -0400, Randy MacLeod wrote:
> On Wed, Aug 13, 2008 at 3:48 PM, Josh Boyer <[EMAIL PROTECTED]> wrote:
> > Hi All,
> >
> > I'm curious what people are using for a kernel dump solution on embedded
>
> Create a region of memory that pesist across resets.
> Put kernel panic
> 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
Arnd Bergmann wrote:
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);
+
+
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, it should be
little ef
On Wed, Aug 13, 2008 at 3:48 PM, Josh Boyer <[EMAIL PROTECTED]> wrote:
> Hi All,
>
> I'm curious what people are using for a kernel dump solution on embedded
Create a region of memory that pesist across resets.
Put kernel panic info, exceptiions and scheduling events into said memory.
Profit!
If
Jared Hulbert wrote:
+static void axfs_free_region(struct axfs_super *sbi,
+struct axfs_region_desc *region)
+{
+ if (!region)
+ return;
+
+ if (AXFS_IS_REGION_XIP(sbi, region))
+ return;
+
+ if (region->virt_addr)
+
Jared Hulbert wrote:
+
+static int axfs_iget5_test(struct inode *inode, void *opaque)
+{
+ u64 *inode_number = (u64 *) opaque;
+
+ if (inode->i_sb == NULL) {
+ printk(KERN_ERR "axfs_iget5_test:"
+ " the super block is set to null\n");
+ }
+
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 used as an inp
> 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
> Jared, nice work!
Thanks.
> A few questions:
I meant to address these before. Sorry.
> - how does this benchmark compared to cramfs and squashfs in a NAND-only
> system
> (or is it just not a good plan to use this with NAND-only (of course
> I won't get XIP with NAND, I understand that)
I
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,
> > but maybe you should not p
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()
> /proc has the same ABI restrictions as sysfs. We more or less stopped
> allowing new files in /proc some 5 years ago for this reason. I didn't
> even read beyond the word /proc to know that what you do here is wrong.
> debugfs is normally easier to use than procfs as well, you just
> define some
> 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]>
> > ---
> > +static int __init ini
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 despite
> >
> People that care about thei
> 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 filesystem choice know their choices.
P
> 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 "secon
> 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 XFS are similar names
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 keep cramfs a really simple ex
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 separate from the files, please make it
> 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 merged?
--
To unsubscrib
> 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 flexible than the
> > ext2 extension I've do
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(struct super_block *);
> +void
On Thursday 21 August 2008, Jared Hulbert wrote:
>
> +#ifndef __AXFS_H
> +#define __AXFS_H
> +
> +
> +#ifdef __KERNEL__
> +#include
> +#endif
> +#include
> +#include
> +
> +#define AXFS_MAGIC 0x48A0E4CD /* some random number */
> +#define AXFS_SIGNATURE "Advanced XIP FS"
> +#define
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]>
> ---
> +static int __init init_axfs_fs(void)
> +{
> + axfs_uncompress_init();
one
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 separate from the files, please make it the
*last* patch so that you cannot get build errors during a later git-bi
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 used as an input to the image
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 flexible than the
> ext2 extension I've done, and the possibility to select XIP vs.
> compression per
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 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 pre
David Woodhouse wrote:
On Thu, 2008-08-21 at 10:44 +0200, Carsten Otte wrote:
Jared Hulbert wrote:
Profiling is a fault instrumentation and /proc formating system.
This is used to get an accurate picture of what the pages are actually used.
Using this info the image can be optimized for XIP
E
On Thu, 2008-08-21 at 15:02 +1200, Charles Manning wrote:
>
> In-tree is no silver bullet.
>
> When people modify internal APIs they will likely fix anything that breaks
> compilation. However many things are more subtle than that and it is very
> easy to end up with a driver or other code that
On Thu, 2008-08-21 at 10:44 +0200, Carsten Otte wrote:
> Jared Hulbert wrote:
> > Profiling is a fault instrumentation and /proc formating system.
> > This is used to get an accurate picture of what the pages are actually used.
> > Using this info the image can be optimized for XIP
> Exporting pro
On Thu, 2008-08-21 at 10:46 +0200, Geert Uytterhoeven wrote:
> Really? So how come so few changes are needed to keep squashfs
> working?
It's read-only.
--
David WoodhouseOpen Source Technology Centre
[EMAIL PROTECTED] Intel Corporation
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]>
> ---
> diff --git a/fs/axfs/axfs_super.c b/fs/axfs/axfs_super.c
> new file mode 100644
On Wed, 20 Aug 2008, Jared Hulbert wrote:
> Handles the decompression for axfs, modeled after fs/cramfs/uncompress.c.
>
> Signed-off-by: Jared Hulbert <[EMAIL PROTECTED]>
> ---
> diff --git a/fs/axfs/axfs_uncompress.c b/fs/axfs/axfs_uncompress.c
> new file mode 100644
> index 000..b7a2060
> -
Jared Hulbert wrote:
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/axfs_super.c
+/* functions in other axfs files ***/
+int axfs_get_sb_bdev(struct file_system_type *, int, c
Jared Hulbert wrote:
Profiling is a fault instrumentation and /proc formating system.
This is used to get an accurate picture of what the pages are actually used.
Using this info the image can be optimized for XIP
Exporting profiling data for a file system in another file system
(/proc) seems no
On Thu, 21 Aug 2008, Charles Manning wrote:
> On Wednesday 20 August 2008 17:15:01 vb wrote:
> > On Tue, Aug 19, 2008 at 9:29 PM, Paul Gortmaker
> >
> > <[EMAIL PROTECTED]> wrote:
> > > On Tue, Aug 19, 2008 at 11:57 PM, vb <[EMAIL PROTECTED]> wrote:
> > >> so, say a developer submits a proprietary
On Wed, Aug 20, 2008 at 10:44:36PM -0700, Jared Hulbert wrote:
> I'd like to get a first round of review on my AXFS filesystem. This is a
> simple
> read only compressed filesystem like Squashfs and cramfs. AXFS is special
> because it also allows for execute-in-place of your applications. It i
Jared Hulbert wrote:
+/* functions in other axfs files
**/
+int axfs_get_sb(struct file_system_type *, int, const char *, void *,
+ struct vfsmount *);
This is neither implemented nor used in axfs_inode.c - why define it here?
+void ax
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) \
+ AXFS_GET_BYTETABLE_VAL(((struct axfs_sup
Jared Hulbert wrote:
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(-)
Acked-by: Carsten Otte <[EMAIL P
Paulius Zaleckas wrote:
Jared Hulbert wrote:
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 --
Jared Hulbert wrote:
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
70 matches
Mail list logo
