linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 06/14] Pramfs: Include files
@ 2009-06-13 13:21 Marco
  2009-06-13 14:04 ` Sam Ravnborg
  0 siblings, 1 reply; 28+ messages in thread
From: Marco @ 2009-06-13 13:21 UTC (permalink / raw)
  To: Linux FS Devel; +Cc: Linux Embedded, Linux Kernel, Daniel Walker

From: Marco Stornelli <marco.stornelli@gmail.com>

Include files.

Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com>
---

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 <marco.stornelli@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 _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 <marco.stornelli@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 _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 */
+


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 06/14] Pramfs: Include files
  2009-06-13 13:21 [PATCH 06/14] Pramfs: Include files Marco
@ 2009-06-13 14:04 ` Sam Ravnborg
  2009-06-13 22:59   ` Arnd Bergmann
  2009-06-14  7:15   ` Marco
  0 siblings, 2 replies; 28+ messages in thread
From: Sam Ravnborg @ 2009-06-13 14:04 UTC (permalink / raw)
  To: Marco; +Cc: Linux FS Devel, Linux Embedded, Linux Kernel, Daniel Walker

On Sat, Jun 13, 2009 at 03:21:48PM +0200, Marco wrote:
> From: Marco Stornelli <marco.stornelli@gmail.com>
> 
> Include files.
> 
> Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com>
> ---
> 
> 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 <marco.stornelli@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 _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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 06/14] Pramfs: Include files
  2009-06-13 14:04 ` Sam Ravnborg
@ 2009-06-13 22:59   ` Arnd Bergmann
  2009-06-14  7:15     ` Marco
  2009-06-21 17:07     ` Marco
  2009-06-14  7:15   ` Marco
  1 sibling, 2 replies; 28+ messages in thread
From: Arnd Bergmann @ 2009-06-13 22:59 UTC (permalink / raw)
  To: Sam Ravnborg
  Cc: Marco, Linux FS Devel, Linux Embedded, Linux Kernel, Daniel Walker

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 <><

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 06/14] Pramfs: Include files
  2009-06-13 14:04 ` Sam Ravnborg
  2009-06-13 22:59   ` Arnd Bergmann
@ 2009-06-14  7:15   ` Marco
  1 sibling, 0 replies; 28+ messages in thread
From: Marco @ 2009-06-14  7:15 UTC (permalink / raw)
  To: Sam Ravnborg; +Cc: Linux FS Devel, Linux Embedded, Linux Kernel, Daniel Walker

Sam Ravnborg wrote:
> On Sat, Jun 13, 2009 at 03:21:48PM +0200, Marco wrote:
>> From: Marco Stornelli <marco.stornelli@gmail.com>
>>
>> +#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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 06/14] Pramfs: Include files
  2009-06-13 22:59   ` Arnd Bergmann
@ 2009-06-14  7:15     ` Marco
  2009-06-21 17:07     ` Marco
  1 sibling, 0 replies; 28+ messages in thread
From: Marco @ 2009-06-14  7:15 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Sam Ravnborg, Linux FS Devel, Linux Embedded, Linux Kernel,
	Daniel Walker

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 06/14] Pramfs: Include files
  2009-06-13 22:59   ` Arnd Bergmann
  2009-06-14  7:15     ` Marco
@ 2009-06-21 17:07     ` Marco
  2009-06-21 20:22       ` Arnd Bergmann
  1 sibling, 1 reply; 28+ messages in thread
From: Marco @ 2009-06-21 17:07 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: Sam Ravnborg, Linux FS Devel, Linux Embedded, Linux Kernel

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 06/14] Pramfs: Include files
  2009-06-21 17:07     ` Marco
@ 2009-06-21 20:22       ` Arnd Bergmann
  2009-06-22  6:23         ` Marco Stornelli
  0 siblings, 1 reply; 28+ messages in thread
From: Arnd Bergmann @ 2009-06-21 20:22 UTC (permalink / raw)
  To: Marco; +Cc: Sam Ravnborg, Linux FS Devel, Linux Embedded, Linux Kernel

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 <><

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 06/14] Pramfs: Include files
  2009-06-21 20:22       ` Arnd Bergmann
@ 2009-06-22  6:23         ` Marco Stornelli
  2009-06-22 11:17           ` Arnd Bergmann
  0 siblings, 1 reply; 28+ messages in thread
From: Marco Stornelli @ 2009-06-22  6:23 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: Sam Ravnborg, Linux FS Devel, Linux Embedded, Linux Kernel

2009/6/21 Arnd Bergmann <arnd@arndb.de>:
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 06/14] Pramfs: Include files
  2009-06-22  6:23         ` Marco Stornelli
@ 2009-06-22 11:17           ` Arnd Bergmann
  2009-06-22 18:05             ` Marco
  0 siblings, 1 reply; 28+ messages in thread
From: Arnd Bergmann @ 2009-06-22 11:17 UTC (permalink / raw)
  To: Marco Stornelli
  Cc: Sam Ravnborg, Linux FS Devel, Linux Embedded, Linux Kernel

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 <><

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 06/14] Pramfs: Include files
  2009-06-22 11:17           ` Arnd Bergmann
@ 2009-06-22 18:05             ` Marco
  2009-06-22 18:33               ` Arnd Bergmann
  0 siblings, 1 reply; 28+ messages in thread
From: Marco @ 2009-06-22 18:05 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: Sam Ravnborg, Linux FS Devel, Linux Embedded, Linux Kernel

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 06/14] Pramfs: Include files
  2009-06-22 18:05             ` Marco
@ 2009-06-22 18:33               ` Arnd Bergmann
  2009-06-22 19:31                 ` Chris Simmonds
  2009-06-23  6:40                 ` Marco Stornelli
  0 siblings, 2 replies; 28+ messages in thread
From: Arnd Bergmann @ 2009-06-22 18:33 UTC (permalink / raw)
  To: Marco; +Cc: Sam Ravnborg, Linux FS Devel, Linux Embedded, Linux Kernel

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 <><

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 06/14] Pramfs: Include files
  2009-06-22 18:33               ` Arnd Bergmann
@ 2009-06-22 19:31                 ` Chris Simmonds
  2009-06-22 20:30                   ` Sam Ravnborg
  2009-06-22 21:41                   ` Jörn Engel
  2009-06-23  6:40                 ` Marco Stornelli
  1 sibling, 2 replies; 28+ messages in thread
From: Chris Simmonds @ 2009-06-22 19:31 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Marco, Sam Ravnborg, Linux FS Devel, Linux Embedded, Linux Kernel

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 majordomo@vger.kernel.org
> 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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 06/14] Pramfs: Include files
  2009-06-22 19:31                 ` Chris Simmonds
@ 2009-06-22 20:30                   ` Sam Ravnborg
  2009-06-22 22:00                     ` Tim Bird
  2009-06-22 21:41                   ` Jörn Engel
  1 sibling, 1 reply; 28+ messages in thread
From: Sam Ravnborg @ 2009-06-22 20:30 UTC (permalink / raw)
  To: Chris Simmonds
  Cc: Arnd Bergmann, Marco, Linux FS Devel, Linux Embedded, Linux Kernel

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 majordomo@vger.kernel.org
> >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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 06/14] Pramfs: Include files
  2009-06-22 19:31                 ` Chris Simmonds
  2009-06-22 20:30                   ` Sam Ravnborg
@ 2009-06-22 21:41                   ` Jörn Engel
  2009-06-22 22:20                     ` David Woodhouse
  2009-06-22 23:07                     ` Arnd Bergmann
  1 sibling, 2 replies; 28+ messages in thread
From: Jörn Engel @ 2009-06-22 21:41 UTC (permalink / raw)
  To: Chris Simmonds
  Cc: Arnd Bergmann, Marco, Sam Ravnborg, Linux FS Devel,
	Linux Embedded, Linux Kernel

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 06/14] Pramfs: Include files
  2009-06-22 20:30                   ` Sam Ravnborg
@ 2009-06-22 22:00                     ` Tim Bird
  2009-06-23  4:21                       ` Sam Ravnborg
  0 siblings, 1 reply; 28+ messages in thread
From: Tim Bird @ 2009-06-22 22:00 UTC (permalink / raw)
  To: Sam Ravnborg
  Cc: Chris Simmonds, Arnd Bergmann, Marco, Linux FS Devel,
	Linux Embedded, Linux Kernel

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
=============================

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 06/14] Pramfs: Include files
  2009-06-22 21:41                   ` Jörn Engel
@ 2009-06-22 22:20                     ` David Woodhouse
  2009-06-23  5:57                       ` Jörn Engel
  2009-06-22 23:07                     ` Arnd Bergmann
  1 sibling, 1 reply; 28+ messages in thread
From: David Woodhouse @ 2009-06-22 22:20 UTC (permalink / raw)
  To: Jörn Engel
  Cc: Chris Simmonds, Arnd Bergmann, Marco, Sam Ravnborg,
	Linux FS Devel, Linux Embedded, Linux Kernel

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
David.Woodhouse@intel.com                              Intel Corporation

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 06/14] Pramfs: Include files
  2009-06-22 21:41                   ` Jörn Engel
  2009-06-22 22:20                     ` David Woodhouse
@ 2009-06-22 23:07                     ` Arnd Bergmann
  1 sibling, 0 replies; 28+ messages in thread
From: Arnd Bergmann @ 2009-06-22 23:07 UTC (permalink / raw)
  To: Jörn Engel
  Cc: Chris Simmonds, Marco, Sam Ravnborg, Linux FS Devel,
	Linux Embedded, Linux Kernel

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 <><
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 06/14] Pramfs: Include files
  2009-06-22 22:00                     ` Tim Bird
@ 2009-06-23  4:21                       ` Sam Ravnborg
  2009-06-23 17:38                         ` Marco
  0 siblings, 1 reply; 28+ messages in thread
From: Sam Ravnborg @ 2009-06-23  4:21 UTC (permalink / raw)
  To: Tim Bird
  Cc: Chris Simmonds, Arnd Bergmann, Marco, Linux FS Devel,
	Linux Embedded, Linux Kernel

> 
> > 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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 06/14] Pramfs: Include files
  2009-06-22 22:20                     ` David Woodhouse
@ 2009-06-23  5:57                       ` Jörn Engel
  2009-06-23  8:31                         ` David Woodhouse
  0 siblings, 1 reply; 28+ messages in thread
From: Jörn Engel @ 2009-06-23  5:57 UTC (permalink / raw)
  To: David Woodhouse
  Cc: Chris Simmonds, Arnd Bergmann, Marco, Sam Ravnborg,
	Linux FS Devel, Linux Embedded, Linux Kernel

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 06/14] Pramfs: Include files
  2009-06-22 18:33               ` Arnd Bergmann
  2009-06-22 19:31                 ` Chris Simmonds
@ 2009-06-23  6:40                 ` Marco Stornelli
  1 sibling, 0 replies; 28+ messages in thread
From: Marco Stornelli @ 2009-06-23  6:40 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: Sam Ravnborg, Linux FS Devel, Linux Embedded, Linux Kernel

2009/6/22 Arnd Bergmann <arnd@arndb.de>:
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 06/14] Pramfs: Include files
  2009-06-23  5:57                       ` Jörn Engel
@ 2009-06-23  8:31                         ` David Woodhouse
  0 siblings, 0 replies; 28+ messages in thread
From: David Woodhouse @ 2009-06-23  8:31 UTC (permalink / raw)
  To: Jörn Engel
  Cc: Chris Simmonds, Arnd Bergmann, Marco, Sam Ravnborg,
	Linux FS Devel, Linux Embedded, Linux Kernel

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
David.Woodhouse@intel.com                              Intel Corporation

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 06/14] Pramfs: Include files
  2009-06-23  4:21                       ` Sam Ravnborg
@ 2009-06-23 17:38                         ` Marco
  2009-06-23 19:26                           ` Jörn Engel
  0 siblings, 1 reply; 28+ messages in thread
From: Marco @ 2009-06-23 17:38 UTC (permalink / raw)
  To: Sam Ravnborg
  Cc: Tim Bird, Chris Simmonds, Arnd Bergmann, Linux FS Devel,
	Linux Embedded, Linux Kernel

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


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 06/14] Pramfs: Include files
  2009-06-23 17:38                         ` Marco
@ 2009-06-23 19:26                           ` Jörn Engel
  2009-06-23 21:15                             ` David Woodhouse
  0 siblings, 1 reply; 28+ messages in thread
From: Jörn Engel @ 2009-06-23 19:26 UTC (permalink / raw)
  To: Marco
  Cc: Sam Ravnborg, Tim Bird, Chris Simmonds, Arnd Bergmann,
	Linux FS Devel, Linux Embedded, Linux Kernel

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 06/14] Pramfs: Include files
  2009-06-23 19:26                           ` Jörn Engel
@ 2009-06-23 21:15                             ` David Woodhouse
  2009-06-23 21:55                               ` Arnd Bergmann
  0 siblings, 1 reply; 28+ messages in thread
From: David Woodhouse @ 2009-06-23 21:15 UTC (permalink / raw)
  To: Jörn Engel
  Cc: Marco, Sam Ravnborg, Tim Bird, Chris Simmonds, Arnd Bergmann,
	Linux FS Devel, Linux Embedded, Linux Kernel

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
David.Woodhouse@intel.com                              Intel Corporation

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 06/14] Pramfs: Include files
  2009-06-23 21:15                             ` David Woodhouse
@ 2009-06-23 21:55                               ` Arnd Bergmann
  2009-06-24  6:32                                 ` Marco Stornelli
  0 siblings, 1 reply; 28+ messages in thread
From: Arnd Bergmann @ 2009-06-23 21:55 UTC (permalink / raw)
  To: David Woodhouse
  Cc: Jörn Engel, Marco, Sam Ravnborg, Tim Bird, Chris Simmonds,
	Linux FS Devel, Linux Embedded, Linux Kernel

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 <><

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 06/14] Pramfs: Include files
  2009-06-23 21:55                               ` Arnd Bergmann
@ 2009-06-24  6:32                                 ` Marco Stornelli
  2009-06-24 15:30                                   ` Arnd Bergmann
  0 siblings, 1 reply; 28+ messages in thread
From: Marco Stornelli @ 2009-06-24  6:32 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: David Woodhouse, Jörn Engel, Sam Ravnborg, Tim Bird,
	Chris Simmonds, Linux FS Devel, Linux Embedded, Linux Kernel

2009/6/23 Arnd Bergmann <arnd@arndb.de>:
> 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 <><
>

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 06/14] Pramfs: Include files
  2009-06-24  6:32                                 ` Marco Stornelli
@ 2009-06-24 15:30                                   ` Arnd Bergmann
  2009-06-24 16:49                                     ` Marco
  0 siblings, 1 reply; 28+ messages in thread
From: Arnd Bergmann @ 2009-06-24 15:30 UTC (permalink / raw)
  To: Marco Stornelli
  Cc: David Woodhouse, Jörn Engel, Sam Ravnborg, Tim Bird,
	Chris Simmonds, Linux FS Devel, Linux Embedded, Linux Kernel

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 <><

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 06/14] Pramfs: Include files
  2009-06-24 15:30                                   ` Arnd Bergmann
@ 2009-06-24 16:49                                     ` Marco
  0 siblings, 0 replies; 28+ messages in thread
From: Marco @ 2009-06-24 16:49 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: David Woodhouse, Jörn Engel, Sam Ravnborg, Tim Bird,
	Chris Simmonds, Linux FS Devel, Linux Embedded, Linux Kernel

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

end of thread, other threads:[~2009-06-24 16:49 UTC | newest]

Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-06-13 13:21 [PATCH 06/14] Pramfs: Include files Marco
2009-06-13 14:04 ` Sam Ravnborg
2009-06-13 22:59   ` Arnd Bergmann
2009-06-14  7:15     ` Marco
2009-06-21 17:07     ` Marco
2009-06-21 20:22       ` Arnd Bergmann
2009-06-22  6:23         ` Marco Stornelli
2009-06-22 11:17           ` Arnd Bergmann
2009-06-22 18:05             ` Marco
2009-06-22 18:33               ` Arnd Bergmann
2009-06-22 19:31                 ` Chris Simmonds
2009-06-22 20:30                   ` Sam Ravnborg
2009-06-22 22:00                     ` Tim Bird
2009-06-23  4:21                       ` Sam Ravnborg
2009-06-23 17:38                         ` Marco
2009-06-23 19:26                           ` Jörn Engel
2009-06-23 21:15                             ` David Woodhouse
2009-06-23 21:55                               ` Arnd Bergmann
2009-06-24  6:32                                 ` Marco Stornelli
2009-06-24 15:30                                   ` Arnd Bergmann
2009-06-24 16:49                                     ` Marco
2009-06-22 21:41                   ` Jörn Engel
2009-06-22 22:20                     ` David Woodhouse
2009-06-23  5:57                       ` Jörn Engel
2009-06-23  8:31                         ` David Woodhouse
2009-06-22 23:07                     ` Arnd Bergmann
2009-06-23  6:40                 ` Marco Stornelli
2009-06-14  7:15   ` Marco

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).