From: Marco Stornelli <[email protected]>
Include files.
Signed-off-by: Marco Stornelli <[email protected]>
---
diff -uprN linux-2.6.30-orig/fs/pramfs/pram_fs.h linux-2.6.30/fs/pramfs/pram_fs.h
--- linux-2.6.30-orig/fs/pramfs/pram_fs.h 1970-01-01 01:00:00.000000000 +0100
+++ linux-2.6.30/fs/pramfs/pram_fs.h 2009-06-13 12:58:49.000000000 +0200
@@ -0,0 +1,388 @@
+/*
+ * FILE NAME include/linux/pram_fs.h
+ *
+ * BRIEF DESCRIPTION
+ *
+ * Definitions for the PRAMFS filesystem.
+ *
+ * Copyright 2009 Marco Stornelli <[email protected]>
+ * 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 _LINUX_PRAM_FS_H
+#define _LINUX_PRAM_FS_H
+
+#include <linux/types.h>
+
+#ifdef __KERNEL__
+#include <linux/sched.h>
+#include <linux/buffer_head.h>
+#include "pram_fs_sb.h"
+#endif
+
+/*
+ * The PRAM filesystem constants/structures
+ */
+
+/*
+ * Define PRAMFS_DEBUG to produce debug messages
+ */
+#define PRAMFS_DEBUG
+
+/*
+ * Debug code
+ */
+#ifdef __KERNEL__
+#define PFX "pramfs"
+#ifdef PRAMFS_DEBUG
+#define pram_dbg(format, arg...) \
+ printk(KERN_DEBUG PFX ": " format , ## arg)
+#else
+#define pram_dbg(format, arg...) do {} while (0)
+#endif
+#define pram_err(format, arg...) \
+ printk(KERN_ERR PFX ": " format , ## arg)
+#define pram_info(format, arg...) \
+ printk(KERN_INFO PFX ": " format , ## arg)
+#define pram_warn(format, arg...) \
+ printk(KERN_WARNING PFX ": " format , ## arg)
+#endif
+
+/*
+ * The PRAM file system magic number
+ */
+#define PRAM_SUPER_MAGIC 0xEFFA
+
+/*
+ * Maximal count of links to a file
+ */
+#define PRAM_LINK_MAX 32000
+
+#define PRAM_MIN_BLOCK_SIZE 512
+#define PRAM_MAX_BLOCK_SIZE 4096
+#define PRAM_DEF_BLOCK_SIZE 2048
+
+#define PRAM_INODE_SIZE 128 /* must be power of two */
+#define PRAM_INODE_BITS 7
+
+/*
+ * Structure of a directory entry in PRAMFS.
+ * Offsets are to the inode that holds the referenced dentry.
+ */
+struct pram_dentry {
+ off_t d_next; /* next dentry in this directory */
+ off_t d_prev; /* previous dentry in this directory */
+ off_t d_parent; /* parent directory */
+ char d_name[0];
+};
+
+
+/*
+ * Structure of an inode in PRAMFS
+ */
+struct pram_inode {
+ __u32 i_sum; /* checksum of this inode */
+ __u32 i_uid; /* Owner Uid */
+ __u32 i_gid; /* Group Id */
+ __u16 i_mode; /* File mode */
+ __u16 i_links_count; /* Links count */
+ __u32 i_blocks; /* Blocks count */
+ __u32 i_size; /* Size of data in bytes */
+ __u32 i_atime; /* Access time */
+ __u32 i_ctime; /* Creation time */
+ __u32 i_mtime; /* Modification time */
+ __u32 i_dtime; /* Deletion Time */
+
+ union {
+ struct {
+ /*
+ * ptr to row block of 2D block pointer array,
+ * file block #'s 0 to (blocksize/4)^2 - 1.
+ */
+ off_t row_block;
+ } reg; /* regular file or symlink inode */
+ struct {
+ off_t head; /* first entry in this directory */
+ off_t tail; /* last entry in this directory */
+ } dir;
+ struct {
+ __u32 rdev; /* major/minor # */
+ } dev; /* device inode */
+ } i_type;
+
+ struct pram_dentry i_d;
+};
+
+#define PRAM_NAME_LEN \
+ (PRAM_INODE_SIZE - offsetof(struct pram_inode, i_d.d_name) - 1)
+
+
+#define PRAM_SB_SIZE 128 /* must be power of two */
+#define PRAM_SB_BITS 7
+
+/*
+ * Structure of the super block in PRAMFS
+ */
+struct pram_super_block {
+ __u32 s_size; /* total size of fs in bytes */
+ __u32 s_blocksize; /* blocksize in bytes */
+ __u32 s_inodes_count; /* total inodes count (used or free) */
+ __u32 s_free_inodes_count;/* free inodes count */
+ __u32 s_free_inode_hint; /* start hint for locating free inodes */
+ __u32 s_blocks_count; /* total data blocks count (used or free) */
+ __u32 s_free_blocks_count;/* free data blocks count */
+ __u32 s_free_blocknr_hint;/* free data blocks count */
+ off_t s_bitmap_start; /* data block in-use bitmap location */
+ __u32 s_bitmap_blocks;/* size of bitmap in number of blocks */
+ __u32 s_mtime; /* Mount time */
+ __u32 s_wtime; /* Write time */
+ __u16 s_magic; /* Magic signature */
+ char s_volume_name[16]; /* volume name */
+ __u32 s_sum; /* checksum of this sb, including padding */
+};
+
+/* The root inode follows immediately after the redundant super block */
+#define PRAM_ROOT_INO PRAM_SB_SIZE
+
+#ifdef __KERNEL__
+
+/* 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 generic_file_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 */
+
+/* balloc.c */
+extern void pram_init_bitmap(struct super_block *sb);
+extern void pram_free_block(struct super_block *sb, int blocknr);
+extern int pram_new_block(struct super_block *sb, int *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);
+
+/* inode.c */
+extern int pram_alloc_blocks(struct inode *inode, int file_blocknr, int num);
+extern off_t pram_find_data_block(struct inode *inode,
+ int file_blocknr);
+extern struct inode *pram_fill_new_inode(struct super_block *sb,
+ struct pram_inode *raw_inode);
+extern void pram_put_inode(struct inode *inode);
+extern void pram_delete_inode(struct inode *inode);
+extern struct inode *pram_new_inode(const struct inode *dir, int mode);
+extern void pram_read_inode(struct inode *inode);
+extern void pram_truncate(struct inode *inode);
+extern int pram_write_inode(struct inode *inode, int wait);
+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);
+
+
+#ifndef CONFIG_PRAMFS_NOWP
+extern void pram_writeable(void *vaddr, unsigned long size, int rw);
+
+#define wrprotect(addr, size) {\
+ spin_lock(&init_mm.page_table_lock);\
+ pram_writeable(addr, size, 0);\
+ spin_unlock(&init_mm.page_table_lock);\
+}
+
+#else
+
+#define wrprotect(addr, size) do {} while (0)
+
+#endif /* CONFIG PRAMFS_NOWP */
+
+/* Inline functions start here */
+
+static inline u32 pram_calc_checksum(u32 *buf, int n)
+{
+ u32 sum = 0;
+ while (n--)
+ sum += *buf++;
+ return sum;
+}
+
+/* If this is part of a read-modify-write of the super block,
+ pram_lock_super() before calling! */
+static inline struct pram_super_block *
+pram_get_super(struct super_block *sb)
+{
+ struct pram_sb_info *sbi = (struct pram_sb_info *)sb->s_fs_info;
+ return (struct pram_super_block *)sbi->virt_addr;
+}
+
+/* pram_lock_super() before calling! */
+static inline void pram_sync_super(struct pram_super_block *ps)
+{
+ ps->s_wtime = get_seconds();
+ ps->s_sum = 0;
+ ps->s_sum -= pram_calc_checksum((u32 *)ps, PRAM_SB_SIZE>>2);
+}
+
+/* pram_lock_inode() before calling! */
+static inline void pram_sync_inode(struct pram_inode *pi)
+{
+ /* pi->i_mtime = CURRENT_TIME; */
+ pi->i_sum = 0;
+ pi->i_sum -= pram_calc_checksum((u32 *)pi, PRAM_INODE_SIZE>>2);
+}
+
+#ifndef CONFIG_PRAMFS_NOWP
+#define pram_lock_range(p, len, flags) {\
+ spin_lock_irqsave(&init_mm.page_table_lock, flags);\
+ pram_writeable((p), (len), 1);\
+}
+
+#define pram_unlock_range(p, len, flags) {\
+ pram_writeable((p), (len), 0);\
+ spin_unlock_irqrestore(&init_mm.page_table_lock, flags);\
+}
+#else
+#define pram_lock_range(p, len, flags) do {} while (0)
+#define pram_unlock_range(p, len, flags) do {} while (0)
+#endif
+
+/* write protection for super block */
+#define pram_lock_super(ps, flags) \
+ pram_lock_range((ps), PRAM_SB_SIZE, flags)
+#define pram_unlock_super(ps, flags) {\
+ pram_sync_super(ps);\
+ pram_unlock_range((ps), PRAM_SB_SIZE, flags);\
+}
+
+/* write protection for inode metadata */
+#define pram_lock_inode(pi, flags) \
+ pram_lock_range((pi), PRAM_INODE_SIZE, flags)
+#define pram_unlock_inode(pi, flags) {\
+ pram_sync_inode(pi);\
+ pram_unlock_range((pi), PRAM_SB_SIZE, flags);\
+}
+
+/* write protection for a data block */
+#define pram_lock_block(sb, bp, flags) \
+ pram_lock_range((bp), (sb)->s_blocksize, flags)
+#define pram_unlock_block(sb, bp, flags) \
+ pram_unlock_range((bp), (sb)->s_blocksize, flags)
+
+static inline void *
+pram_get_bitmap(struct super_block *sb)
+{
+ struct pram_super_block *ps = pram_get_super(sb);
+ return (void *)ps + ps->s_bitmap_start;
+}
+
+/* If this is part of a read-modify-write of the inode metadata,
+ pram_lock_inode() before calling! */
+static inline struct pram_inode *
+pram_get_inode(struct super_block *sb, off_t ino)
+{
+ struct pram_super_block *ps = pram_get_super(sb);
+ return ino ? (struct pram_inode *)((void *)ps + ino) : NULL;
+}
+
+static inline ino_t
+pram_get_inodenr(struct super_block *sb, struct pram_inode *pi)
+{
+ struct pram_super_block *ps = pram_get_super(sb);
+ return (ino_t)((unsigned long)pi - (unsigned long)ps);
+}
+
+static inline off_t
+pram_get_block_off(struct super_block *sb, unsigned long blocknr)
+{
+ struct pram_super_block *ps = pram_get_super(sb);
+ return (off_t)(ps->s_bitmap_start +
+ (blocknr << sb->s_blocksize_bits));
+}
+
+static inline unsigned long
+pram_get_blocknr(struct super_block *sb, off_t block)
+{
+ struct pram_super_block *ps = pram_get_super(sb);
+ return (block - ps->s_bitmap_start) >> sb->s_blocksize_bits;
+}
+
+/* If this is part of a read-modify-write of the block,
+ pram_lock_block() before calling! */
+static inline void *
+pram_get_block(struct super_block *sb, off_t block)
+{
+ struct pram_super_block *ps = pram_get_super(sb);
+ return block ? ((void *)ps + block) : NULL;
+}
+
+
+/*
+ * Inodes and files operations
+ */
+
+/* dir.c */
+extern struct file_operations pram_dir_operations;
+
+/* file.c */
+extern struct inode_operations pram_file_inode_operations;
+extern struct file_operations pram_file_operations;
+
+/* inode.c */
+extern struct address_space_operations pram_aops;
+
+/* namei.c */
+extern struct inode_operations pram_dir_inode_operations;
+
+/* symlink.c */
+extern struct inode_operations pram_symlink_inode_operations;
+
+#endif /* __KERNEL__ */
+
+#endif /* _LINUX_PRAM_FS_H */
diff -uprN linux-2.6.30-orig/fs/pramfs/pram_fs_sb.h linux-2.6.30/fs/pramfs/pram_fs_sb.h
--- linux-2.6.30-orig/fs/pramfs/pram_fs_sb.h 1970-01-01 01:00:00.000000000 +0100
+++ linux-2.6.30/fs/pramfs/pram_fs_sb.h 2009-06-13 12:59:17.000000000 +0200
@@ -0,0 +1,40 @@
+/*
+ * FILE NAME include/linux/pram_fs_sb.h
+ *
+ * Definitions for the PRAM filesystem.
+ *
+ * Copyright 2009 Marco Stornelli <[email protected]>
+ * 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 _LINUX_PRAM_FS_SB
+#define _LINUX_PRAM_FS_SB
+
+/*
+ * PRAM filesystem super-block data in memory
+ */
+struct pram_sb_info {
+ /*
+ * base physical and virtual address of PRAMFS (which is also
+ * the pointer to the super block)
+ */
+ phys_addr_t phys_addr;
+ void *virt_addr;
+
+ /* Mount options */
+ unsigned long bpi;
+ unsigned long num_inodes;
+ unsigned long blocksize;
+ unsigned long initsize;
+ uid_t uid; /* Mount uid for root directory */
+ gid_t gid; /* Mount gid for root directory */
+ mode_t mode; /* Mount mode for root directory */
+};
+
+#endif /* _LINUX_PRAM_FS_SB */
+
On Sat, Jun 13, 2009 at 03:21:48PM +0200, Marco wrote:
> From: Marco Stornelli <[email protected]>
>
> Include files.
>
> Signed-off-by: Marco Stornelli <[email protected]>
> ---
>
> diff -uprN linux-2.6.30-orig/fs/pramfs/pram_fs.h linux-2.6.30/fs/pramfs/pram_fs.h
> --- linux-2.6.30-orig/fs/pramfs/pram_fs.h 1970-01-01 01:00:00.000000000 +0100
> +++ linux-2.6.30/fs/pramfs/pram_fs.h 2009-06-13 12:58:49.000000000 +0200
> @@ -0,0 +1,388 @@
> +/*
> + * FILE NAME include/linux/pram_fs.h
> + *
> + * BRIEF DESCRIPTION
> + *
> + * Definitions for the PRAMFS filesystem.
> + *
> + * Copyright 2009 Marco Stornelli <[email protected]>
> + * 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 _LINUX_PRAM_FS_H
> +#define _LINUX_PRAM_FS_H
> +
> +#include <linux/types.h>
> +
> +#ifdef __KERNEL__
> +#include <linux/sched.h>
> +#include <linux/buffer_head.h>
> +#include "pram_fs_sb.h"
> +#endif
The only reason to have this header file in include/linux/
is that it is used by userspace.
So please split it up so we have one header suitable for exporting
and another header with all the promfs local stuff.
The latter should be in fs/pramsfs/
> +
> +/*
> + * The PRAM filesystem constants/structures
> + */
> +
> +/*
> + * Define PRAMFS_DEBUG to produce debug messages
> + */
> +#define PRAMFS_DEBUG
> +
> +/*
> + * Debug code
> + */
> +#ifdef __KERNEL__
> +#define PFX "pramfs"
> +#ifdef PRAMFS_DEBUG
> +#define pram_dbg(format, arg...) \
> + printk(KERN_DEBUG PFX ": " format , ## arg)
> +#else
> +#define pram_dbg(format, arg...) do {} while (0)
> +#endif
> +#define pram_err(format, arg...) \
> + printk(KERN_ERR PFX ": " format , ## arg)
> +#define pram_info(format, arg...) \
> + printk(KERN_INFO PFX ": " format , ## arg)
> +#define pram_warn(format, arg...) \
> + printk(KERN_WARNING PFX ": " format , ## arg)
> +#endif
For a typical drivers we have some pr_* to avoid the above.
Can they be used for a filesystem too?
> +
> +/*
> + * The PRAM file system magic number
> + */
> +#define PRAM_SUPER_MAGIC 0xEFFA
Move to include/linux/magic.h
> +
> +/*
> + * Structure of an inode in PRAMFS
> + */
> +struct pram_inode {
> + __u32 i_sum; /* checksum of this inode */
> + __u32 i_uid; /* Owner Uid */
> + __u32 i_gid; /* Group Id */
> + __u16 i_mode; /* File mode */
> + __u16 i_links_count; /* Links count */
> + __u32 i_blocks; /* Blocks count */
> + __u32 i_size; /* Size of data in bytes */
> + __u32 i_atime; /* Access time */
> + __u32 i_ctime; /* Creation time */
> + __u32 i_mtime; /* Modification time */
> + __u32 i_dtime; /* Deletion Time */
> +
> + union {
> + struct {
> + /*
> + * ptr to row block of 2D block pointer array,
> + * file block #'s 0 to (blocksize/4)^2 - 1.
> + */
> + off_t row_block;
It is my understanding that we shall use: __kernel_off_t
in exported headers.
The headers are not added to Kbuild - so it is not exported.
I assume thats an oversight.
Sam
On Saturday 13 June 2009, Sam Ravnborg wrote:
> > + union {
> > + struct {
> > + /*
> > + * ptr to row block of 2D block pointer array,
> > + * file block #'s 0 to (blocksize/4)^2 - 1.
> > + */
> > + off_t row_block;
>
> It is my understanding that we shall use: __kernel_off_t
> in exported headers.
That is a correct understanding in general, however this case is
different, because it describes an on-disk data structure,
not a kernel to user space interface. Here, __kernel_off_t is just
as wrong as off_t, because it will differ between 32 and 64 bit
architectures, making the fs layout incompatible. I'd suggest
simply defining this as __u64.
Moreover, file system layout should be described in terms of
big-endian or little-endian types (e.g. __be64 or __le64),
together with the right accessor functions.
Arnd <><
Sam Ravnborg wrote:
> On Sat, Jun 13, 2009 at 03:21:48PM +0200, Marco wrote:
>> From: Marco Stornelli <[email protected]>
>>
>> +#include <linux/types.h>
>> +
>> +#ifdef __KERNEL__
>> +#include <linux/sched.h>
>> +#include <linux/buffer_head.h>
>> +#include "pram_fs_sb.h"
>> +#endif
>
> The only reason to have this header file in include/linux/
> is that it is used by userspace.
> So please split it up so we have one header suitable for exporting
> and another header with all the promfs local stuff.
> The latter should be in fs/pramsfs/
Yeah you're right. Actually it's not used by userspace so I think I can
remove the ifdef.
>
>
>> +
>> +
>> +/*
>> + * Debug code
>> + */
>> +#ifdef __KERNEL__
>> +#define PFX "pramfs"
>> +#ifdef PRAMFS_DEBUG
>> +#define pram_dbg(format, arg...) \
>> + printk(KERN_DEBUG PFX ": " format , ## arg)
>> +#else
>> +#define pram_dbg(format, arg...) do {} while (0)
>> +#endif
>> +#define pram_err(format, arg...) \
>> + printk(KERN_ERR PFX ": " format , ## arg)
>> +#define pram_info(format, arg...) \
>> + printk(KERN_INFO PFX ": " format , ## arg)
>> +#define pram_warn(format, arg...) \
>> + printk(KERN_WARNING PFX ": " format , ## arg)
>> +#endif
>
> For a typical drivers we have some pr_* to avoid the above.
> Can they be used for a filesystem too?
Ok, I'll use them.
>
>> +
>> +/*
>> + * The PRAM file system magic number
>> + */
>> +#define PRAM_SUPER_MAGIC 0xEFFA
>
> Move to include/linux/magic.h
>
Ok.
>> +
>> +/*
>> + * Structure of an inode in PRAMFS
>> + */
>> +struct pram_inode {
>> + __u32 i_sum; /* checksum of this inode */
>> + __u32 i_uid; /* Owner Uid */
>> + __u32 i_gid; /* Group Id */
>> + __u16 i_mode; /* File mode */
>> + __u16 i_links_count; /* Links count */
>> + __u32 i_blocks; /* Blocks count */
>> + __u32 i_size; /* Size of data in bytes */
>> + __u32 i_atime; /* Access time */
>> + __u32 i_ctime; /* Creation time */
>> + __u32 i_mtime; /* Modification time */
>> + __u32 i_dtime; /* Deletion Time */
>> +
>> + union {
>> + struct {
>> + /*
>> + * ptr to row block of 2D block pointer array,
>> + * file block #'s 0 to (blocksize/4)^2 - 1.
>> + */
>> + off_t row_block;
>
> It is my understanding that we shall use: __kernel_off_t
> in exported headers.
>
> The headers are not added to Kbuild - so it is not exported.
> I assume thats an oversight.
>
> Sam
>
As I said it shouldn't be an exported header.
Marco
Arnd Bergmann wrote:
> On Saturday 13 June 2009, Sam Ravnborg wrote:
>>> + union {
>>> + struct {
>>> + /*
>>> + * ptr to row block of 2D block pointer array,
>>> + * file block #'s 0 to (blocksize/4)^2 - 1.
>>> + */
>>> + off_t row_block;
>> It is my understanding that we shall use: __kernel_off_t
>> in exported headers.
>
> That is a correct understanding in general, however this case is
> different, because it describes an on-disk data structure,
> not a kernel to user space interface. Here, __kernel_off_t is just
> as wrong as off_t, because it will differ between 32 and 64 bit
> architectures, making the fs layout incompatible. I'd suggest
> simply defining this as __u64.
>
> Moreover, file system layout should be described in terms of
> big-endian or little-endian types (e.g. __be64 or __le64),
> together with the right accessor functions.
>
> Arnd <><
>
Yep, you're right. I have to change the definition to be compatible
between 32 and 64 bit archs.
Marco
Arnd Bergmann wrote:
> On Saturday 13 June 2009, Sam Ravnborg wrote:
>>> + union {
>>> + struct {
>>> + /*
>>> + * ptr to row block of 2D block pointer array,
>>> + * file block #'s 0 to (blocksize/4)^2 - 1.
>>> + */
>>> + off_t row_block;
>> It is my understanding that we shall use: __kernel_off_t
>> in exported headers.
>
> That is a correct understanding in general, however this case is
> different, because it describes an on-disk data structure,
> not a kernel to user space interface. Here, __kernel_off_t is just
> as wrong as off_t, because it will differ between 32 and 64 bit
> architectures, making the fs layout incompatible. I'd suggest
> simply defining this as __u64.
>
> Moreover, file system layout should be described in terms of
> big-endian or little-endian types (e.g. __be64 or __le64),
> together with the right accessor functions.
>
> Arnd <><
>
I was thinking about your comment and I think I'll use __kernel_off_t
for the exported headers. I know that it will differ between 32 and 64
bit architectures, but for this kind of fs there isn't any compatibility
problem at layout level. You cannot remove a chip of RAM from a board
32bit little endian and attach it to a board with a cpu 64bit big
endian, the memory isn't a disk. Indeed, I see that tmpfs uses simply
"unsigned long" in the exported header file without any problems to
little or big endian.
Regards,
Marco
On Sunday 21 June 2009, Marco wrote:
> I was thinking about your comment and I think I'll use __kernel_off_t
> for the exported headers. I know that it will differ between 32 and 64
> bit architectures, but for this kind of fs there isn't any compatibility
> problem at layout level. You cannot remove a chip of RAM from a board
> 32bit little endian and attach it to a board with a cpu 64bit big
> endian, the memory isn't a disk. Indeed, I see that tmpfs uses simply
> "unsigned long" in the exported header file without any problems to
> little or big endian.
It's still a problem. You might be creating a file system image
for an embedded board with a different endianess. Or even on the
same machine, you could be looking at the file system contents
with a 32 bit process running on a 64 bit kernel.
Arnd <><
2009/6/21 Arnd Bergmann <[email protected]>:
> On Sunday 21 June 2009, Marco wrote:
>> I was thinking about your comment and I think I'll use __kernel_off_t
>> for the exported headers. I know that it will differ between 32 and 64
>> bit architectures, but for this kind of fs there isn't any compatibility
>> problem at layout level. You cannot remove a chip of RAM from a board
>> 32bit little endian and attach it to a board with a cpu 64bit big
>> endian, the memory isn't a disk. Indeed, I see that tmpfs uses simply
>> "unsigned long" in the exported header file without any problems to
>> little or big endian.
>
> It's still a problem. You might be creating a file system image
> for an embedded board with a different endianess.
It's not possible to create an "image" with pramfs, it's like tmpfs.
> Or even on the same machine, you could be looking at the file system contents
> with a 32 bit process running on a 64 bit kernel.
>
> ? ? ? ?Arnd <><
>
Yes, indeed the most important thing is to be sure that a 64bit kernel
works well. I'll try to test it in this environment. If there are
"64bit guys" to help me to test it, it'd be great.
Marco
On Monday 22 June 2009, Marco Stornelli wrote:
> > It's still a problem. You might be creating a file system image
> > for an embedded board with a different endianess.
>
> It's not possible to create an "image" with pramfs, it's like tmpfs.
But the data is persistant, you even support using it as a root file
system, so the data has to have a way to get there. Even if you
don't do it right now, I don't see any fundamental limitation that
prevents you from creating an image on one machine and dumping it
into the nvram of another machine as part of manufacturing or testing.
> > Or even on the same machine, you could be looking at the file system contents
> > with a 32 bit process running on a 64 bit kernel.
>
> Yes, indeed the most important thing is to be sure that a 64bit kernel
> works well. I'll try to test it in this environment. If there are
> "64bit guys" to help me to test it, it'd be great.
This particular problem (__kernel_off_t on 64-bit machines) can be avoided
by just switching to __kernel_loff_t, which is 64 bit long on all machines,
while __kernel_off_t is always the register length (32 or 64 bits).
Arnd <><
Arnd Bergmann wrote:
> On Monday 22 June 2009, Marco Stornelli wrote:
>>> It's still a problem. You might be creating a file system image
>>> for an embedded board with a different endianess.
>> It's not possible to create an "image" with pramfs, it's like tmpfs.
>
> But the data is persistant, you even support using it as a root file
> system, so the data has to have a way to get there. Even if you
> don't do it right now, I don't see any fundamental limitation that
> prevents you from creating an image on one machine and dumping it
> into the nvram of another machine as part of manufacturing or testing.
>
Sorry, I meant it's not *currently* possible. At the moment the only way
to use it as rootfs it's to copy all the data in an already mounted
(empty) ram partition and reboot. However it's not my first item on my
todo list because I think that it's possible to use it as rootfs but it
isn't the standard use for this fs.
>>> Or even on the same machine, you could be looking at the file system contents
>>> with a 32 bit process running on a 64 bit kernel.
>> Yes, indeed the most important thing is to be sure that a 64bit kernel
>> works well. I'll try to test it in this environment. If there are
>> "64bit guys" to help me to test it, it'd be great.
>
> This particular problem (__kernel_off_t on 64-bit machines) can be avoided
> by just switching to __kernel_loff_t, which is 64 bit long on all machines,
> while __kernel_off_t is always the register length (32 or 64 bits).
>
> Arnd <><
>
Yep, it can be a good idea, thanks for the tip.
Marco
On Monday 22 June 2009, Marco wrote:
>
> Sorry, I meant it's not currently possible. At the moment the only way
> to use it as rootfs it's to copy all the data in an already mounted
> (empty) ram partition and reboot. However it's not my first item on my
> todo list because I think that it's possible to use it as rootfs but it
> isn't the standard use for this fs.
Well, it doesn't have to work right away. What I'm asking to
define the data structures in a way that keeps the layout stable
across kernel updates. Since a future version of the file system
might support cross-endian image creation, it would be good to
define the data structures in a fixed endian mode already, so
you don't have to change it in the future.
Arnd <><
Arnd Bergmann wrote:
> On Monday 22 June 2009, Marco wrote:
>> Sorry, I meant it's not currently possible. At the moment the only way
>> to use it as rootfs it's to copy all the data in an already mounted
>> (empty) ram partition and reboot. However it's not my first item on my
>> todo list because I think that it's possible to use it as rootfs but it
>> isn't the standard use for this fs.
>
> Well, it doesn't have to work right away. What I'm asking to
> define the data structures in a way that keeps the layout stable
> across kernel updates. Since a future version of the file system
> might support cross-endian image creation, it would be good to
> define the data structures in a fixed endian mode already, so
> you don't have to change it in the future.
>
> Arnd <><
> --
> 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.org/majordomo-info.html
>
I disagree: that adds an unnecessary overhead for those architectures
where the cpu byte order does not match the data structure ordering. I
think the data structures should be native endian and when mkpramfs is
written it can take a flag (e.g. -r) in the same way mkcramfs does.
Chris Simmonds
On Mon, Jun 22, 2009 at 08:31:10PM +0100, Chris Simmonds wrote:
> Arnd Bergmann wrote:
> >On Monday 22 June 2009, Marco wrote:
> >>Sorry, I meant it's not currently possible. At the moment the only way
> >>to use it as rootfs it's to copy all the data in an already mounted
> >>(empty) ram partition and reboot. However it's not my first item on my
> >>todo list because I think that it's possible to use it as rootfs but it
> >>isn't the standard use for this fs.
> >
> >Well, it doesn't have to work right away. What I'm asking to
> >define the data structures in a way that keeps the layout stable
> >across kernel updates. Since a future version of the file system
> >might support cross-endian image creation, it would be good to
> >define the data structures in a fixed endian mode already, so
> >you don't have to change it in the future.
> >
> > Arnd <><
> >--
> >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.org/majordomo-info.html
> >
>
> I disagree: that adds an unnecessary overhead for those architectures
> where the cpu byte order does not match the data structure ordering.
It is not that we are talking big and complex stuff here.
pramfs is likely to be used for small things and then having to
fix endian on a few headers in the on-dsk format does not matter.
Not compared to the potential disadvantages.
It should be possible to read a file-system on your x86 64bit
box that you wrote with your small powerpc target.
Sam
On Mon, 22 June 2009 20:31:10 +0100, Chris Simmonds wrote:
>
> I disagree: that adds an unnecessary overhead for those architectures
> where the cpu byte order does not match the data structure ordering. I
> think the data structures should be native endian and when mkpramfs is
> written it can take a flag (e.g. -r) in the same way mkcramfs does.
Just to quantify this point, I've written a small crap program:
#include <stdio.h>
#include <stdint.h>
#include <byteswap.h>
#include <sys/time.h>
long long delta(struct timeval *t1, struct timeval *t2)
{
long long delta;
delta = 1000000ull * t2->tv_sec + t2->tv_usec;
delta -= 1000000ull * t1->tv_sec + t1->tv_usec;
return delta;
}
#define LOOPS 100000000
int main(void)
{
long native = 0;
uint32_t narrow = 0;
uint64_t wide = 0, native_wide = 0;
struct timeval t1, t2, t3, t4, t5;
int i;
gettimeofday(&t1, NULL);
for (i = 0; i < LOOPS; i++)
native++;
gettimeofday(&t2, NULL);
for (i = 0; i < LOOPS; i++)
narrow = bswap_32(bswap_64(narrow) + 1);
gettimeofday(&t3, NULL);
for (i = 0; i < LOOPS; i++)
native_wide++;
gettimeofday(&t4, NULL);
for (i = 0; i < LOOPS; i++)
wide = bswap_64(bswap_64(wide) + 1);
gettimeofday(&t5, NULL);
printf("long: %9lld us\n", delta(&t1, &t2));
printf("we32: %9lld us\n", delta(&t2, &t3));
printf("u64: %9lld us\n", delta(&t3, &t4));
printf("we64: %9lld us\n", delta(&t4, &t5));
printf("loops: %9d\n", LOOPS);
return 0;
}
Four loops doing the same increment with different data types: long,
u64, we32 (wrong-endian) and we64. Compile with _no_ optimizations.
Results on my i386 notebook:
long: 453953 us
we32: 880273 us
u64: 504214 us
we64: 2259953 us
loops: 100000000
Or thereabouts, not completely stable. Increasing the data width is 10%
slower, 32bit endianness conversions is 2x slower, 64bit conversion is
5x slower.
However, even the we64 loop still munches through 353MB/s (100M
conversions in 2.2s, 8bytes per converion. Double the number if you
count both conversion to/from wrong endianness). Elsewhere in this
thread someone claimed the filesystem peaks out at 13MB/s. One might
further note that only filesystem metadata has to go through endianness
conversion, so on this particular machine it is completely lost in the
noise.
Feel free to run the program on any machine you care about. If you get
numbers to back up your position, I'm willing to be convinced. Until
then, I consider the alleged overhead of endianness conversion a prime
example of premature optimization.
Jörn
--
Joern's library part 7:
http://www.usenix.org/publications/library/proceedings/neworl/full_papers/mckusick.a
Sam Ravnborg wrote:
> It is not that we are talking big and complex stuff here.
I agree completely.
> pramfs is likely to be used for small things and then having to
> fix endian on a few headers in the on-dsk format does not matter.
I agree with this, but mostly out of exhaustion.
> Not compared to the potential disadvantages.
I can see no potential disadvantages.
> It should be possible to read a file-system on your x86 64bit
> box that you wrote with your small powerpc target.
For a (NV)RAM-based filesystem?? WTH???
This is not my file system, so I don't have a dog in this
fight. I just wanted to clarify what I thought were some
misconceptions about the use cases and priorities for the
FS. My "advocacy" may be interfering with understanding
this system and its purpose. I'll be quiet now.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
On Mon, 2009-06-22 at 23:41 +0200, Jörn Engel wrote:
> Four loops doing the same increment with different data types: long,
> u64, we32 (wrong-endian) and we64. Compile with _no_ optimizations.
That's a bit of a poor test then. Especially on architectures with a
load-and-swap instruction where it really shouldn't be any slower at
all.
(Although since GCC doesn't have an __attribute__((littleendian)) I'm
not entirely sure how to entice it into _using_ said instruction for the
purpose of the test... I think the kernel does manage somehow though, if
you get the sources _just_ right.)
--
David Woodhouse Open Source Technology Centre
[email protected] Intel Corporation
On Monday 22 June 2009, Jörn Engel wrote:
> Four loops doing the same increment with different data types: long,
> u64, we32 (wrong-endian) and we64. Compile with no optimizations.
>
> Results on my i386 notebook:
> long: 453953 us
> we32: 880273 us
> u64: 504214 us
> we64: 2259953 us
> loops: 100000000
(couldn't resist)
The we64 number is artificially high because the glibc bswap_64
implementation forces the conversion to be done on the stack.
Using __builtin_bswap64 make this look more logical, and
makes your point even stronger (on core 2, using -m32):
long: 236792 us
we32: 500827 us
u64: 265990 us
we64: 757380 us
loops: 100000000
Arnd <><
>
> > It should be possible to read a file-system on your x86 64bit
> > box that you wrote with your small powerpc target.
> For a (NV)RAM-based filesystem?? WTH???
dd the full image - dig into it.
Usefull is you have post-mortem info there.
Sam
On Mon, 22 June 2009 23:20:39 +0100, David Woodhouse wrote:
> On Mon, 2009-06-22 at 23:41 +0200, Jörn Engel wrote:
> > Four loops doing the same increment with different data types: long,
> > u64, we32 (wrong-endian) and we64. Compile with _no_ optimizations.
>
> That's a bit of a poor test then. Especially on architectures with a
> load-and-swap instruction where it really shouldn't be any slower at
> all.
>
> (Although since GCC doesn't have an __attribute__((littleendian)) I'm
> not entirely sure how to entice it into _using_ said instruction for the
> purpose of the test... I think the kernel does manage somehow though, if
> you get the sources _just_ right.)
Feel free to improve the test. It is admittedly crap and designed to
support Chris' argument. But seeing that it still fails to do so and
Arnd has already shown one improvement that weakened Chris' argument, I
guess we can all agree that further improvments won't change the
conclusion, can we? ;)
Jörn
--
It's just what we asked for, but not what we want!
-- anonymous
2009/6/22 Arnd Bergmann <[email protected]>:
> On Monday 22 June 2009, Marco wrote:
>>
>> Sorry, I meant it's not currently possible. At the moment the only way
>> to use it as rootfs it's to copy all the data in an already mounted
>> (empty) ram partition and reboot. However it's not my first item on my
>> todo list because I think that it's possible to use it as rootfs but it
>> isn't the standard use for this fs.
>
> Well, it doesn't have to work right away. What I'm asking to
> define the data structures in a way that keeps the layout stable
> across kernel updates. Since a future version of the file system
> might support cross-endian image creation, it would be good to
> define the data structures in a fixed endian mode already, so
> you don't have to change it in the future.
>
> ? ? ? ?Arnd <><
>
I was refering to create a tool "mkpramfs".
Marco
On Tue, 2009-06-23 at 07:57 +0200, Jörn Engel wrote:
>
> Feel free to improve the test. It is admittedly crap and designed to
> support Chris' argument. But seeing that it still fails to do so and
> Arnd has already shown one improvement that weakened Chris' argument,
> I
> guess we can all agree that further improvments won't change the
> conclusion, can we? ;)
True. At this point, I'm actually more interested in just how crap the
kernel code is, that's generated by your test. We don't have a portable
way to store a wrong-endian number. Using st_le32() on PowerPC we can
get it down to something like this...
le32: 27777875 cycles
be32: 26564494 cycles
loops: 100000000
le32: 21739926 cycles
be32: 20289854 cycles
loops: 100000000
le32: 25206069 cycles
be32: 20289854 cycles
loops: 100000000
le32: 21739435 cycles
be32: 17391303 cycles
loops: 100000000
le32: 22197744 cycles
be32: 17391305 cycles
loops: 100000000
le32: 22195411 cycles
be32: 21946167 cycles
loops: 100000000
a0: 7f 4c 42 e6 mftbl r26
a4: 2c 1a 00 00 cmpwi r26,0
a8: 41 a2 ff f8 beq- a0 <.init_module+0x54>
ac: 3c 00 05 f5 lis r0,1525
b0: 3b 7f 00 70 addi r27,r31,112
b4: 60 00 e1 00 ori r0,r0,57600
b8: 7d 20 dc 2c lwbrx r9,0,r27
bc: 39 29 00 01 addi r9,r9,1
c0: 79 29 00 20 clrldi r9,r9,32
c4: 7d 20 dd 2c stwbrx r9,0,r27
c8: 34 00 ff ff addic. r0,r0,-1
cc: 40 82 ff ec bne+ b8 <.init_module+0x6c>
d0: 7f ac 42 e6 mftbl r29
d4: 2c 1d 00 00 cmpwi r29,0
d8: 41 a2 ff f8 beq- d0 <.init_module+0x84>
dc: 3c 00 05 f5 lis r0,1525
e0: 60 00 e1 00 ori r0,r0,57600
e4: 81 3f 00 74 lwz r9,116(r31)
e8: 39 29 00 01 addi r9,r9,1
ec: 91 3f 00 74 stw r9,116(r31)
f0: 34 00 ff ff addic. r0,r0,-1
f4: 40 82 ff f0 bne+ e4 <.init_module+0x98>
f8: 7f 8c 42 e6 mftbl r28
Interestingly, if we get rid of the (gratuitous, afaict) clrldi at 0xc0,
the little-endian version goes _faster_:
le32: 18839472 cycles
be32: 21946166 cycles
loops: 100000000
le32: 25923621 cycles
be32: 29629625 cycles
loops: 100000000
--
David Woodhouse Open Source Technology Centre
[email protected] Intel Corporation
Sam Ravnborg wrote:
>>> It should be possible to read a file-system on your x86 64bit
>>> box that you wrote with your small powerpc target.
>> For a (NV)RAM-based filesystem?? WTH???
>
> dd the full image - dig into it.
> Usefull is you have post-mortem info there.
>
> Sam
>
dd? You haven't got any device file to have a dump. I think we're going
a bit out of scope. I had some doubt to support rootfs in pram and after
some feedback and the comments of this review I think I'll remove it
from the next release (to understand some aspects of this fs with the
kernel community was my main goal for this review). I agree to use the
native endian. As I said the important thing is that if an user want to
use it in a 64bit environment then the fs must work well and then it
must be designed to support even this situation, I think it's obvious.
Marco
On Tue, 23 June 2009 19:38:33 +0200, Marco wrote:
>
> dd? You haven't got any device file to have a dump. I think we're going
> a bit out of scope. I had some doubt to support rootfs in pram and after
> some feedback and the comments of this review I think I'll remove it
> from the next release (to understand some aspects of this fs with the
> kernel community was my main goal for this review). I agree to use the
> native endian. As I said the important thing is that if an user want to
> use it in a 64bit environment then the fs must work well and then it
> must be designed to support even this situation, I think it's obvious.
Glancing at the discussion with Pawel, I see two paths to follow. One
is to turn pramfs into a full-features all-round general-purpose
filesystem with mkfs, fsck, xattr and any number of additional features.
That way lies doom, as you would compete against ext2+xip and have
little new to offer.
The other path is to make/keep pramfs as simple as possible for
comparatively specialized purposes, like flight recorder data and dump
information. Main selling point here is the amount of vulnerable code
in the total package. ext2 + block layer + vfs helpers is relatively
large and many things may go wrong in a panic situation.
So I agree with you that many things expected from general purpose
filesystems simply don't apply to pramfs. Moving mkfs into the kernel
is a fair tradeoff, when the required code is small. Endianness is a
different case imo. dd may not work, but a jtag probe will happily get
you the dump to your development machine.
And even within the same box you can have more than one architecture and
endianness. http://www.top500.org/system/9707 will show you one such
beast, which happens to have the top bragging rights at the moment. I
don't want to endorse such strange beasts, but there is no good reason
not to support reading the ppc-written fs from the opteron. In fact,
there is no reason full stop.
Jörn
--
Beware of bugs in the above code; I have only proved it correct, but
not tried it.
-- Donald Knuth
On Tue, 2009-06-23 at 21:26 +0200, Jörn Engel wrote:
> Endianness is a
> different case imo. dd may not work, but a jtag probe will happily get
> you the dump to your development machine.
And dd on /dev/mem would work, surely?
I'd definitely recommend making it fixed-endian. Not doing so for JFFS2
was a mistake I frequently regretted.
--
David Woodhouse Open Source Technology Centre
[email protected] Intel Corporation
On Tuesday 23 June 2009, David Woodhouse wrote:
> And dd on /dev/mem would work, surely?
Actually, reading from /dev/mem is only valid on real RAM. If the nvram
is part of an IO memory mapping, you have to do mmap()+memcpy() rather
than read(). So dd won't do it, but it's still easy to read from user
space.
> I'd definitely recommend making it fixed-endian. Not doing so for JFFS2
> was a mistake I frequently regretted.
Right.
Arnd <><
2009/6/23 Arnd Bergmann <[email protected]>:
> On Tuesday 23 June 2009, David Woodhouse wrote:
>> And dd on /dev/mem would work, surely?
>
> Actually, reading from /dev/mem is only valid on real RAM. If the nvram
> is part of an IO memory mapping, you have to do mmap()+memcpy() rather
> than read(). So dd won't do it, but it's still easy to read from user
> space.
For "security" reasons pram reserve the region of memory with
reserve_mem_region_exclusive().....
>
>> I'd definitely recommend making it fixed-endian. Not doing so for JFFS2
>> was a mistake I frequently regretted.
>
> Right.
>
> ? ? ? ?Arnd <><
>
On Wednesday 24 June 2009, Marco Stornelli wrote:
> > Actually, reading from /dev/mem is only valid on real RAM. If the nvram
> > is part of an IO memory mapping, you have to do mmap()+memcpy() rather
> > than read(). So dd won't do it, but it's still easy to read from user
> > space.
>
> For "security" reasons pram reserve the region of memory with
> reserve_mem_region_exclusive().....
That will only prevent other device drivers from stepping on it,
/dev/mem does not care about mem_region reservations.
Arnd <><
Arnd Bergmann wrote:
> On Wednesday 24 June 2009, Marco Stornelli wrote:
>>> Actually, reading from /dev/mem is only valid on real RAM. If the nvram
>>> is part of an IO memory mapping, you have to do mmap()+memcpy() rather
>>> than read(). So dd won't do it, but it's still easy to read from user
>>> space.
>> For "security" reasons pram reserve the region of memory with
>> reserve_mem_region_exclusive().....
>
> That will only prevent other device drivers from stepping on it,
> /dev/mem does not care about mem_region reservations.
>
> Arnd <><
>
Userland may not map this resource, so /dev/mem and the sysfs MMIO
access will not be allowed. This restriction depends on STRICT_DEVMEM
option. It's true that currently is only implemented in the x86 world.
Marco