Re: [PATCH 08/16 v2] pramfs: headers
On 11/10/2010 09:15 PM, Marco Stornelli wrote: 2010/11/9 Geert Uytterhoeven ge...@linux-m68k.org: On Tue, Nov 9, 2010 at 21:35, Ryan Mallon r...@bluewatersys.com wrote: You can still do all of those things without having a fixed endianess. You just have to have one extra step of telling the external tools what the endianess is. IMHO, it is better to have the overhead of the endian conversion in the tools since it is less costly there than an the embedded system. I'm just trying to understand why the fixed endianess rule cannot be bent for such a specialised filesystem. When it was decided that filesystems should be fixed-endian and support for big-endian ext2 was dropped, the overhead of doing the fixed conversions was deetermined negligible due to compiler optimization. That was ages ago, and current embedded systems run circles around the machines of those days. Note that this is about metadata only. Actual file contents are always just byte streams. I can add that the penalties in this case are negligible due to the compensation of the very fast access of the media. In addition, from performance point of view I'm pretty happy (you can see the some benchmark on the project web site). Thanks for the explanation guys. ~Ryan -- Bluewater Systems Ltd - ARM Technology Solution Centre Ryan Mallon 5 Amuri Park, 404 Barbadoes St r...@bluewatersys.com PO Box 13 889, Christchurch 8013 http://www.bluewatersys.com New Zealand Phone: +64 3 3779127Freecall: Australia 1800 148 751 Fax: +64 3 3779135 USA 1800 261 2934 -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/16 v2] pramfs: headers
2010/11/8 Ryan Mallon r...@bluewatersys.com:
On 11/08/2010 08:49 PM, Marco Stornelli wrote:
2010/11/7 Ryan Mallon r...@bluewatersys.com:
On 11/06/2010 09:58 PM, Marco Stornelli wrote:
From: Marco Stornelli marco.storne...@gmail.com
Definitions for the PRAMFS filesystem.
Signed-off-by: Marco Stornelli marco.storne...@gmail.com
---
diff -Nurp linux-2.6.36-orig/fs/pramfs/pram.h linux-2.6.36/fs/pramfs/pram.h
--- linux-2.6.36-orig/fs/pramfs/pram.h 1970-01-01
01:00:00.0 +0100
+++ linux-2.6.36/fs/pramfs/pram.h 2010-10-30 12:02:45.0 +0200
@@ -0,0 +1,317 @@
+/*
+ * Structure of the super block in PRAMFS
+ */
+struct pram_super_block {
+ __be16 s_sum; /* checksum of this sb, including padding */
+ __be64 s_size; /* total size of fs in bytes */
+ __be32 s_blocksize; /* blocksize in bytes */
+ __be32 s_inodes_count; /* total inodes count (used or free) */
+ __be32 s_free_inodes_count;/* free inodes count */
+ __be32 s_free_inode_hint; /* start hint for locating free inodes */
+ __be32 s_blocks_count; /* total data blocks count (used or free) */
+ __be32 s_free_blocks_count;/* free data blocks count */
+ __be32 s_free_blocknr_hint;/* free data blocks count */
+ __be64 s_bitmap_start; /* data block in-use bitmap location */
+ __be32 s_bitmap_blocks;/* size of bitmap in number of blocks */
+ __be32 s_mtime; /* Mount time */
+ __be32 s_wtime; /* Write time */
+ __be16 s_magic; /* Magic signature */
+ char s_volume_name[16]; /* volume name */
+};
Is there a particular reason to use big endian types for the data
structures? On a little endian machine you will end up converting values
everywhere. I assume that you don't expect the machine to change
endianess between reboots :-). If this is for generating/reading
filesystems from userspace, wouldn't it be better to have the userspace
tools specify the target endianess and do the conversions there?
~Ryan
Yes, there is a reason. In the first review a comment was: the fs must
have a fix endianess layout. This fs is designed for the embedded
world mainly. Since most of cpus used in this case are big-endian, it
means that for typical use case, there is no cost for endianess
conversion.
ARM, which is a large portion of the embedded space, is typically little
endian.
Not always. Indeed, I didn't say *all* cpu used are big-endian.
Why does a filesystem need to have a specific endianess layout?
Especially for a highly specialised filesystem like this.
I didn't agree with it, but in the first review there was more than
one developer that said this thing. The main reason was to read the
format (for example with JTAG) or to create an image with a fix
format. I remember that someone said that there was a similar problem
with jffs2 and the experience tell to us that a fix endianess is
important. At that point I decided to use big-endian. You can see all
the discussion in lkml. The review has been done at June 2009.
Regards,
Marco
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/16 v2] pramfs: headers
On 11/09/2010 09:19 PM, Marco Stornelli wrote:
2010/11/8 Ryan Mallon r...@bluewatersys.com:
On 11/08/2010 08:49 PM, Marco Stornelli wrote:
2010/11/7 Ryan Mallon r...@bluewatersys.com:
On 11/06/2010 09:58 PM, Marco Stornelli wrote:
From: Marco Stornelli marco.storne...@gmail.com
Definitions for the PRAMFS filesystem.
Signed-off-by: Marco Stornelli marco.storne...@gmail.com
---
diff -Nurp linux-2.6.36-orig/fs/pramfs/pram.h
linux-2.6.36/fs/pramfs/pram.h
--- linux-2.6.36-orig/fs/pramfs/pram.h1970-01-01
01:00:00.0 +0100
+++ linux-2.6.36/fs/pramfs/pram.h 2010-10-30 12:02:45.0 +0200
@@ -0,0 +1,317 @@
+/*
+ * Structure of the super block in PRAMFS
+ */
+struct pram_super_block {
+ __be16 s_sum; /* checksum of this sb, including padding */
+ __be64 s_size; /* total size of fs in bytes */
+ __be32 s_blocksize;/* blocksize in bytes */
+ __be32 s_inodes_count; /* total inodes count (used or free) */
+ __be32 s_free_inodes_count;/* free inodes count */
+ __be32 s_free_inode_hint; /* start hint for locating free inodes
*/
+ __be32 s_blocks_count; /* total data blocks count (used or free) */
+ __be32 s_free_blocks_count;/* free data blocks count */
+ __be32 s_free_blocknr_hint;/* free data blocks count */
+ __be64 s_bitmap_start; /* data block in-use bitmap location */
+ __be32 s_bitmap_blocks;/* size of bitmap in number of blocks */
+ __be32 s_mtime;/* Mount time */
+ __be32 s_wtime;/* Write time */
+ __be16 s_magic;/* Magic signature */
+ chars_volume_name[16]; /* volume name */
+};
Is there a particular reason to use big endian types for the data
structures? On a little endian machine you will end up converting values
everywhere. I assume that you don't expect the machine to change
endianess between reboots :-). If this is for generating/reading
filesystems from userspace, wouldn't it be better to have the userspace
tools specify the target endianess and do the conversions there?
~Ryan
Yes, there is a reason. In the first review a comment was: the fs must
have a fix endianess layout. This fs is designed for the embedded
world mainly. Since most of cpus used in this case are big-endian, it
means that for typical use case, there is no cost for endianess
conversion.
ARM, which is a large portion of the embedded space, is typically little
endian.
Not always. Indeed, I didn't say *all* cpu used are big-endian.
My point is that little endian embedded machines make up a large portion
of the devices that this filesystem will be useful on. On those devices
it will also have an (unnecessary) conversion overhead.
Why does a filesystem need to have a specific endianess layout?
Especially for a highly specialised filesystem like this.
I didn't agree with it, but in the first review there was more than
one developer that said this thing. The main reason was to read the
format (for example with JTAG) or to create an image with a fix
format. I remember that someone said that there was a similar problem
with jffs2 and the experience tell to us that a fix endianess is
important. At that point I decided to use big-endian. You can see all
the discussion in lkml. The review has been done at June 2009.
You can still do all of those things without having a fixed endianess.
You just have to have one extra step of telling the external tools what
the endianess is. IMHO, it is better to have the overhead of the endian
conversion in the tools since it is less costly there than an the
embedded system.
I'm just trying to understand why the fixed endianess rule cannot be
bent for such a specialised filesystem.
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
r...@bluewatersys.com PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com New Zealand
Phone: +64 3 3779127Freecall: Australia 1800 148 751
Fax: +64 3 3779135 USA 1800 261 2934
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/16 v2] pramfs: headers
On Tue, Nov 9, 2010 at 21:35, Ryan Mallon r...@bluewatersys.com wrote:
On 11/09/2010 09:19 PM, Marco Stornelli wrote:
2010/11/8 Ryan Mallon r...@bluewatersys.com:
On 11/08/2010 08:49 PM, Marco Stornelli wrote:
2010/11/7 Ryan Mallon r...@bluewatersys.com:
On 11/06/2010 09:58 PM, Marco Stornelli wrote:
From: Marco Stornelli marco.storne...@gmail.com
Definitions for the PRAMFS filesystem.
Signed-off-by: Marco Stornelli marco.storne...@gmail.com
---
diff -Nurp linux-2.6.36-orig/fs/pramfs/pram.h
linux-2.6.36/fs/pramfs/pram.h
--- linux-2.6.36-orig/fs/pramfs/pram.h 1970-01-01
01:00:00.0 +0100
+++ linux-2.6.36/fs/pramfs/pram.h 2010-10-30 12:02:45.0 +0200
@@ -0,0 +1,317 @@
+/*
+ * Structure of the super block in PRAMFS
+ */
+struct pram_super_block {
+ __be16 s_sum; /* checksum of this sb, including padding
*/
+ __be64 s_size; /* total size of fs in bytes */
+ __be32 s_blocksize; /* blocksize in bytes */
+ __be32 s_inodes_count; /* total inodes count (used or free) */
+ __be32 s_free_inodes_count;/* free inodes count */
+ __be32 s_free_inode_hint; /* start hint for locating free inodes
*/
+ __be32 s_blocks_count; /* total data blocks count (used or free)
*/
+ __be32 s_free_blocks_count;/* free data blocks count */
+ __be32 s_free_blocknr_hint;/* free data blocks count */
+ __be64 s_bitmap_start; /* data block in-use bitmap location */
+ __be32 s_bitmap_blocks;/* size of bitmap in number of blocks */
+ __be32 s_mtime; /* Mount time */
+ __be32 s_wtime; /* Write time */
+ __be16 s_magic; /* Magic signature */
+ char s_volume_name[16]; /* volume name */
+};
Is there a particular reason to use big endian types for the data
structures? On a little endian machine you will end up converting values
everywhere. I assume that you don't expect the machine to change
endianess between reboots :-). If this is for generating/reading
filesystems from userspace, wouldn't it be better to have the userspace
tools specify the target endianess and do the conversions there?
~Ryan
Yes, there is a reason. In the first review a comment was: the fs must
have a fix endianess layout. This fs is designed for the embedded
world mainly. Since most of cpus used in this case are big-endian, it
means that for typical use case, there is no cost for endianess
conversion.
ARM, which is a large portion of the embedded space, is typically little
endian.
Not always. Indeed, I didn't say *all* cpu used are big-endian.
My point is that little endian embedded machines make up a large portion
of the devices that this filesystem will be useful on. On those devices
it will also have an (unnecessary) conversion overhead.
Why does a filesystem need to have a specific endianess layout?
Especially for a highly specialised filesystem like this.
I didn't agree with it, but in the first review there was more than
one developer that said this thing. The main reason was to read the
format (for example with JTAG) or to create an image with a fix
format. I remember that someone said that there was a similar problem
with jffs2 and the experience tell to us that a fix endianess is
important. At that point I decided to use big-endian. You can see all
the discussion in lkml. The review has been done at June 2009.
You can still do all of those things without having a fixed endianess.
You just have to have one extra step of telling the external tools what
the endianess is. IMHO, it is better to have the overhead of the endian
conversion in the tools since it is less costly there than an the
embedded system.
I'm just trying to understand why the fixed endianess rule cannot be
bent for such a specialised filesystem.
When it was decided that filesystems should be fixed-endian and support for
big-endian ext2 was dropped, the overhead of doing the fixed conversions was
deetermined negligible due to compiler optimization.
That was ages ago, and current embedded systems run circles around the
machines of those days.
Note that this is about metadata only. Actual file contents are always just
byte streams.
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 I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/16 v2] pramfs: headers
On 11/08/2010 08:49 PM, Marco Stornelli wrote:
2010/11/7 Ryan Mallon r...@bluewatersys.com:
On 11/06/2010 09:58 PM, Marco Stornelli wrote:
From: Marco Stornelli marco.storne...@gmail.com
Definitions for the PRAMFS filesystem.
Signed-off-by: Marco Stornelli marco.storne...@gmail.com
---
diff -Nurp linux-2.6.36-orig/fs/pramfs/pram.h linux-2.6.36/fs/pramfs/pram.h
--- linux-2.6.36-orig/fs/pramfs/pram.h1970-01-01 01:00:00.0
+0100
+++ linux-2.6.36/fs/pramfs/pram.h 2010-10-30 12:02:45.0 +0200
@@ -0,0 +1,317 @@
+/*
+ * Structure of the super block in PRAMFS
+ */
+struct pram_super_block {
+ __be16 s_sum; /* checksum of this sb, including padding */
+ __be64 s_size; /* total size of fs in bytes */
+ __be32 s_blocksize;/* blocksize in bytes */
+ __be32 s_inodes_count; /* total inodes count (used or free) */
+ __be32 s_free_inodes_count;/* free inodes count */
+ __be32 s_free_inode_hint; /* start hint for locating free inodes */
+ __be32 s_blocks_count; /* total data blocks count (used or free) */
+ __be32 s_free_blocks_count;/* free data blocks count */
+ __be32 s_free_blocknr_hint;/* free data blocks count */
+ __be64 s_bitmap_start; /* data block in-use bitmap location */
+ __be32 s_bitmap_blocks;/* size of bitmap in number of blocks */
+ __be32 s_mtime;/* Mount time */
+ __be32 s_wtime;/* Write time */
+ __be16 s_magic;/* Magic signature */
+ chars_volume_name[16]; /* volume name */
+};
Is there a particular reason to use big endian types for the data
structures? On a little endian machine you will end up converting values
everywhere. I assume that you don't expect the machine to change
endianess between reboots :-). If this is for generating/reading
filesystems from userspace, wouldn't it be better to have the userspace
tools specify the target endianess and do the conversions there?
~Ryan
Yes, there is a reason. In the first review a comment was: the fs must
have a fix endianess layout. This fs is designed for the embedded
world mainly. Since most of cpus used in this case are big-endian, it
means that for typical use case, there is no cost for endianess
conversion.
ARM, which is a large portion of the embedded space, is typically little
endian.
Why does a filesystem need to have a specific endianess layout?
Especially for a highly specialised filesystem like this.
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
r...@bluewatersys.com PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com New Zealand
Phone: +64 3 3779127Freecall: Australia 1800 148 751
Fax: +64 3 3779135 USA 1800 261 2934
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/16 v2] pramfs: headers
On 11/06/2010 09:58 PM, Marco Stornelli wrote:
From: Marco Stornelli marco.storne...@gmail.com
Definitions for the PRAMFS filesystem.
Signed-off-by: Marco Stornelli marco.storne...@gmail.com
---
diff -Nurp linux-2.6.36-orig/fs/pramfs/pram.h linux-2.6.36/fs/pramfs/pram.h
--- linux-2.6.36-orig/fs/pramfs/pram.h1970-01-01 01:00:00.0
+0100
+++ linux-2.6.36/fs/pramfs/pram.h 2010-10-30 12:02:45.0 +0200
@@ -0,0 +1,317 @@
+/*
+ * Structure of the super block in PRAMFS
+ */
+struct pram_super_block {
+ __be16 s_sum; /* checksum of this sb, including padding */
+ __be64 s_size; /* total size of fs in bytes */
+ __be32 s_blocksize;/* blocksize in bytes */
+ __be32 s_inodes_count; /* total inodes count (used or free) */
+ __be32 s_free_inodes_count;/* free inodes count */
+ __be32 s_free_inode_hint; /* start hint for locating free inodes */
+ __be32 s_blocks_count; /* total data blocks count (used or free) */
+ __be32 s_free_blocks_count;/* free data blocks count */
+ __be32 s_free_blocknr_hint;/* free data blocks count */
+ __be64 s_bitmap_start; /* data block in-use bitmap location */
+ __be32 s_bitmap_blocks;/* size of bitmap in number of blocks */
+ __be32 s_mtime;/* Mount time */
+ __be32 s_wtime;/* Write time */
+ __be16 s_magic;/* Magic signature */
+ chars_volume_name[16]; /* volume name */
+};
Is there a particular reason to use big endian types for the data
structures? On a little endian machine you will end up converting values
everywhere. I assume that you don't expect the machine to change
endianess between reboots :-). If this is for generating/reading
filesystems from userspace, wouldn't it be better to have the userspace
tools specify the target endianess and do the conversions there?
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
r...@bluewatersys.com PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com New Zealand
Phone: +64 3 3779127Freecall: Australia 1800 148 751
Fax: +64 3 3779135 USA 1800 261 2934
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/16 v2] pramfs: headers
2010/11/7 Ryan Mallon r...@bluewatersys.com:
On 11/06/2010 09:58 PM, Marco Stornelli wrote:
From: Marco Stornelli marco.storne...@gmail.com
Definitions for the PRAMFS filesystem.
Signed-off-by: Marco Stornelli marco.storne...@gmail.com
---
diff -Nurp linux-2.6.36-orig/fs/pramfs/pram.h linux-2.6.36/fs/pramfs/pram.h
--- linux-2.6.36-orig/fs/pramfs/pram.h 1970-01-01 01:00:00.0
+0100
+++ linux-2.6.36/fs/pramfs/pram.h 2010-10-30 12:02:45.0 +0200
@@ -0,0 +1,317 @@
+/*
+ * Structure of the super block in PRAMFS
+ */
+struct pram_super_block {
+ __be16 s_sum; /* checksum of this sb, including padding */
+ __be64 s_size; /* total size of fs in bytes */
+ __be32 s_blocksize; /* blocksize in bytes */
+ __be32 s_inodes_count; /* total inodes count (used or free) */
+ __be32 s_free_inodes_count;/* free inodes count */
+ __be32 s_free_inode_hint; /* start hint for locating free inodes */
+ __be32 s_blocks_count; /* total data blocks count (used or free) */
+ __be32 s_free_blocks_count;/* free data blocks count */
+ __be32 s_free_blocknr_hint;/* free data blocks count */
+ __be64 s_bitmap_start; /* data block in-use bitmap location */
+ __be32 s_bitmap_blocks;/* size of bitmap in number of blocks */
+ __be32 s_mtime; /* Mount time */
+ __be32 s_wtime; /* Write time */
+ __be16 s_magic; /* Magic signature */
+ char s_volume_name[16]; /* volume name */
+};
Is there a particular reason to use big endian types for the data
structures? On a little endian machine you will end up converting values
everywhere. I assume that you don't expect the machine to change
endianess between reboots :-). If this is for generating/reading
filesystems from userspace, wouldn't it be better to have the userspace
tools specify the target endianess and do the conversions there?
~Ryan
Yes, there is a reason. In the first review a comment was: the fs must
have a fix endianess layout. This fs is designed for the embedded
world mainly. Since most of cpus used in this case are big-endian, it
means that for typical use case, there is no cost for endianess
conversion.
Marco
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/16 v2] pramfs: headers
From: Marco Stornelli marco.storne...@gmail.com
Definitions for the PRAMFS filesystem.
Signed-off-by: Marco Stornelli marco.storne...@gmail.com
---
diff -Nurp linux-2.6.36-orig/fs/pramfs/pram.h linux-2.6.36/fs/pramfs/pram.h
--- linux-2.6.36-orig/fs/pramfs/pram.h 1970-01-01 01:00:00.0 +0100
+++ linux-2.6.36/fs/pramfs/pram.h 2010-10-30 12:02:45.0 +0200
@@ -0,0 +1,317 @@
+/*
+ * FILE NAME pram.h
+ *
+ * BRIEF DESCRIPTION
+ *
+ * Definitions for the PRAMFS filesystem.
+ *
+ * Copyright 2009-2010 Marco Stornelli marco.storne...@gmail.com
+ * Copyright 2003 Sony Corporation
+ * Copyright 2003 Matsushita Electric Industrial Co., Ltd.
+ * 2003-2004 (c) MontaVista Software, Inc. , Steve Longerbeam
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+#ifndef __PRAM_H
+#define __PRAM_H
+
+#include linux/buffer_head.h
+#include linux/pram_fs.h
+#include linux/pram_fs_sb.h
+#include linux/crc16.h
+#include linux/mutex.h
+#include linux/types.h
+
+/*
+ * Debug code
+ */
+#define pram_dbg(s, args...) pr_debug(PRAMFS: s, ## args)
+#define pram_err(s, args...) pr_err(PRAMFS: s, ## args)
+#define pram_warn(s, args...) pr_warning(PRAMFS: s, ## args)
+#define pram_info(s, args...) pr_info(PRAMFS: s, ## args)
+
+/* Function Prototypes */
+
+#ifdef CONFIG_PRAMFS_XIP
+
+#define pram_read xip_file_read
+#define pram_write xip_file_write
+#define pram_mmap xip_file_mmap
+#define pram_aio_read NULL
+#define pram_aio_write NULL
+#define pram_readpage NULL
+#define pram_direct_IO NULL
+
+#else
+
+#define pram_read do_sync_read
+#define pram_write do_sync_write
+#define pram_mmap __pram_mmap
+#define pram_aio_read generic_file_aio_read
+#define pram_aio_write generic_file_aio_write
+#define pram_direct_IO __pram_direct_IO
+#define pram_readpage __pram_readpage
+
+extern int pram_get_and_update_block(struct inode *inode, sector_t iblock,
+struct buffer_head *bh, int create);
+
+static inline int __pram_readpage(struct file *file, struct page *page)
+{
+ return block_read_full_page(page, pram_get_and_update_block);
+}
+
+/* file.c */
+extern ssize_t __pram_direct_IO(int rw, struct kiocb *iocb,
+ const struct iovec *iov,
+ loff_t offset, unsigned long nr_segs);
+
+
+#endif /* CONFIG_PRAMFS_XIP */
+
+#define pram_set_bit ext2_set_bit
+#define pram_clear_bit ext2_clear_bit
+#define pram_find_next_zero_bitext2_find_next_zero_bit
+
+/* balloc.c */
+extern void pram_init_bitmap(struct super_block *sb);
+extern void pram_free_block(struct super_block *sb, unsigned long blocknr);
+extern int pram_new_block(struct super_block *sb, unsigned long *blocknr, int
zero);
+extern unsigned long pram_count_free_blocks(struct super_block *sb);
+
+/* dir.c */
+extern int pram_add_link(struct dentry *dentry, struct inode *inode);
+extern int pram_remove_link(struct inode *inode);
+
+/* namei.c */
+extern struct dentry *pram_get_parent(struct dentry *child);
+
+/* inode.c */
+extern int pram_alloc_blocks(struct inode *inode, int file_blocknr, int num);
+extern u64 pram_find_data_block(struct inode *inode,
+int file_blocknr);
+
+extern struct inode *pram_iget(struct super_block *sb, unsigned long ino);
+extern void pram_put_inode(struct inode *inode);
+extern void pram_evict_inode(struct inode *inode);
+extern struct inode *pram_new_inode(struct inode *dir, int mode);
+extern int pram_update_inode(struct inode *inode);
+extern int pram_write_inode(struct inode *inode, struct writeback_control
*wbc);
+extern void pram_dirty_inode(struct inode *inode);
+extern int pram_notify_change(struct dentry *dentry, struct iattr *attr);
+
+
+/* super.c */
+#ifdef CONFIG_PRAMFS_TEST
+extern struct pram_super_block *get_pram_super(void);
+#endif
+extern struct super_block *pram_read_super(struct super_block *sb,
+ void *data,
+ int silent);
+extern int pram_statfs(struct dentry *d, struct kstatfs *buf);
+extern int pram_remount(struct super_block *sb, int *flags, char *data);
+
+/* symlink.c */
+extern int pram_block_symlink(struct inode *inode,
+ const char *symname, int len);
+
+
+#ifdef CONFIG_PRAMFS_WRITE_PROTECT
+extern void pram_writeable(void *vaddr, unsigned long size, int rw);
+
+#define wrprotect(addr, size) pram_writeable(addr, size, 0)
+
+#else
+
+#define wrprotect(addr, size) do {} while (0)
+
+#endif /* CONFIG PRAMFS_WRITE_PROTECT */
+
+/* Inline functions start here */
+
+static inline int pram_calc_checksum(u8 *data, int n)
+{
+ u16 crc = 0;
+ crc = crc16(~0, (__u8 *)data + sizeof(__be16), n - sizeof(__be16));
+ if (*((__be16 *)data) ==
