* Re: [PATCH 02/16 v2] pramfs: super block operations
From: James Hogan @ 2010-11-06 13:12 UTC (permalink / raw)
To: Marco Stornelli
Cc: Linux Kernel, Linux Embedded, Linux FS Devel, Tim Bird,
Andrew Morton
In-Reply-To: <4CD51847.20306@gmail.com>
Hi,
On Sat, Nov 06, 2010 at 09:56:39AM +0100, Marco Stornelli wrote:
> From: Marco Stornelli <marco.stornelli@gmail.com>
>
> Super block operations.
>
> Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com>
> ---
> diff -Nurp linux-2.6.36-orig/fs/pramfs/super.c linux-2.6.36/fs/pramfs/super.c
> --- linux-2.6.36-orig/fs/pramfs/super.c 1970-01-01 01:00:00.000000000 +0100
> +++ linux-2.6.36/fs/pramfs/super.c 2010-09-25 14:09:47.000000000 +0200
<snip>
> + pram_dbg("max name length %d\n", PRAM_NAME_LEN);
I get a warning on this line that could be avoided:
fs/pramfs/super.c: In function ‘pram_init’:
fs/pramfs/super.c:308: warning: format ‘%d’ expects type ‘int’, but
argument 2 has type ‘long unsigned int’
Cheers
James
^ permalink raw reply
* Re: [PATCH 10/16 v2] pramfs: XIP operations
From: James Hogan @ 2010-11-06 13:33 UTC (permalink / raw)
To: Marco Stornelli
Cc: Linux Kernel, Linux Embedded, Linux FS Devel, Tim Bird,
Andrew Morton
In-Reply-To: <4CD518EF.3030306@gmail.com>
Hi,
On Sat, Nov 06, 2010 at 09:59:27AM +0100, Marco Stornelli wrote:
> diff -Nurp linux-2.6.36-orig/fs/pramfs/xip.c linux-2.6.36/fs/pramfs/xip.c
> --- linux-2.6.36-orig/fs/pramfs/xip.c 1970-01-01 01:00:00.000000000 +0100
> +++ linux-2.6.36/fs/pramfs/xip.c 2010-09-14 18:49:52.000000000 +0200
<snip>
> +static int pram_find_and_alloc_blocks(struct inode *inode, sector_t iblock,
> + sector_t *data_block, int create)
> +{
> + int err = -EIO;
> + u64 block;
> +
> + mutex_lock(&PRAM_I(inode)->truncate_lock);
fs/pramfs/xip.c: In function ‘pram_find_and_alloc_blocks’:
fs/pramfs/xip.c:27: error: ‘struct pram_inode_vfs’ has no member named
‘truncate_lock’
fs/pramfs/xip.c:52: error: ‘struct pram_inode_vfs’ has no member named
‘truncate_lock’
i guess that should be truncate_mutex.
> +
> + block = pram_find_data_block(inode, iblock);
> +
> + if (!block) {
> + if (!create) {
> + err = -ENODATA;
> + goto err;
> + }
> +
> + err = pram_alloc_blocks(inode, iblock, 1);
> + if (err)
> + goto err;
> +
> + block = pram_find_data_block(inode, iblock);
> + if (!block) {
> + err = -ENODATA;
> + goto err;
> + }
> + }
> +
> + *data_block = block;
> + err = 0;
> +
> + err:
> + mutex_unlock(&PRAM_I(inode)->truncate_lock);
same here
> + return err;
> +}
Cheers
James
^ permalink raw reply
* Re: [PATCH 01/16 v2] pramfs: documentation
From: Marco Stornelli @ 2010-11-06 14:59 UTC (permalink / raw)
To: James Hogan
Cc: Linux Kernel, Linux Embedded, Linux FS Devel, Tim Bird,
Andrew Morton
In-Reply-To: <20101106103935.GA13172@gandalf.local>
Il 06/11/2010 11:39, James Hogan ha scritto:
> Hi,
>
> On Sat, Nov 06, 2010 at 09:56:18AM +0100, Marco Stornelli wrote:
>> From: Marco Stornelli <marco.stornelli@gmail.com>
>> +PRAMFS is write protected. The page table entries that map the backing-store
>> +RAM are normally marked read-only. Write operations into the filesystem
>> +temporarily mark the affected pages as writeable, the write operation is
>> +carried out with locks held, and then the page table entries is +marked read-only again.
>> +This feature provides protection against filesystem corruption caused by errant
>
> Looks like an accidental lost newline in the patch here, should that be
> "are marked" or is there some text missing?
>
My fault, a problem during email formatting. I'll resend this patch.
Marco
^ permalink raw reply
* Re: [PATCH 02/16 v2] pramfs: super block operations
From: Marco Stornelli @ 2010-11-06 14:59 UTC (permalink / raw)
To: James Hogan
Cc: Linux Kernel, Linux Embedded, Linux FS Devel, Tim Bird,
Andrew Morton
In-Reply-To: <20101106131257.GB13522@gandalf.local>
Il 06/11/2010 14:12, James Hogan ha scritto:
> Hi,
>
> On Sat, Nov 06, 2010 at 09:56:39AM +0100, Marco Stornelli wrote:
>> From: Marco Stornelli <marco.stornelli@gmail.com>
>>
>> Super block operations.
>>
>> Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com>
>> ---
>> diff -Nurp linux-2.6.36-orig/fs/pramfs/super.c linux-2.6.36/fs/pramfs/super.c
>> --- linux-2.6.36-orig/fs/pramfs/super.c 1970-01-01 01:00:00.000000000 +0100
>> +++ linux-2.6.36/fs/pramfs/super.c 2010-09-25 14:09:47.000000000 +0200
> <snip>
>> + pram_dbg("max name length %d\n", PRAM_NAME_LEN);
>
> I get a warning on this line that could be avoided:
>
> fs/pramfs/super.c: In function ‘pram_init’:
> fs/pramfs/super.c:308: warning: format ‘%d’ expects type ‘int’, but
> argument 2 has type ‘long unsigned int’
>
> Cheers
> James
>
Mmmm, very strange, I don't have that warning, maybe the compiler
version. I'll fix it with an int cast to avoid it.
Marco
^ permalink raw reply
* Re: [PATCH 02/16 v2] pramfs: super block operations
From: Marco Stornelli @ 2010-11-06 14:59 UTC (permalink / raw)
To: James Hogan
Cc: Linux Kernel, Linux Embedded, Linux FS Devel, Tim Bird,
Andrew Morton
In-Reply-To: <20101106111627.GA13497@gandalf.local>
Il 06/11/2010 12:16, James Hogan ha scritto:
> Hi Marco,
>
> On Sat, Nov 06, 2010 at 09:56:39AM +0100, Marco Stornelli wrote:
>> From: Marco Stornelli <marco.stornelli@gmail.com>
>> +static void pram_set_blocksize(struct super_block *sb, unsigned long size)
>> +{
>> + int bits;
>> +
>> + /*
>> + * We've already validated the user input and the value here must be
>> + * between PRAM_MAX_BLOCK_SIZE and PRAM_MIN_BLOCK_SIZE
>> + * and it must be a power of 2.
>> + */
>
> Should this comment have spaces after the tabs to be consistent with the
> other multiline comments (pram_ioremap) and the coding style?
>
Ok, no problem.
Thanks for the review.
Regards,
Marco
^ permalink raw reply
* Re: [PATCH 10/16 v2] pramfs: XIP operations
From: Marco Stornelli @ 2010-11-06 15:00 UTC (permalink / raw)
To: James Hogan
Cc: Linux Kernel, Linux Embedded, Linux FS Devel, Tim Bird,
Andrew Morton
In-Reply-To: <20101106133330.GC13522@gandalf.local>
Il 06/11/2010 14:33, James Hogan ha scritto:
> Hi,
>
> On Sat, Nov 06, 2010 at 09:59:27AM +0100, Marco Stornelli wrote:
>> diff -Nurp linux-2.6.36-orig/fs/pramfs/xip.c linux-2.6.36/fs/pramfs/xip.c
>> --- linux-2.6.36-orig/fs/pramfs/xip.c 1970-01-01 01:00:00.000000000 +0100
>> +++ linux-2.6.36/fs/pramfs/xip.c 2010-09-14 18:49:52.000000000 +0200
> <snip>
>> +static int pram_find_and_alloc_blocks(struct inode *inode, sector_t iblock,
>> + sector_t *data_block, int create)
>> +{
>> + int err = -EIO;
>> + u64 block;
>> +
>> + mutex_lock(&PRAM_I(inode)->truncate_lock);
>
> fs/pramfs/xip.c: In function ‘pram_find_and_alloc_blocks’:
> fs/pramfs/xip.c:27: error: ‘struct pram_inode_vfs’ has no member named
> ‘truncate_lock’
> fs/pramfs/xip.c:52: error: ‘struct pram_inode_vfs’ has no member named
> ‘truncate_lock’
>
> i guess that should be truncate_mutex.
>
Oops, my fault, yes it's truncate_mutex. I'll fix it asap.
Marco
^ permalink raw reply
* Re: [PATCH 16/16 v2] pramfs: Makefile and Kconfig
From: Randy Dunlap @ 2010-11-06 15:48 UTC (permalink / raw)
To: Marco Stornelli
Cc: Linux Kernel, Linux Embedded, Linux FS Devel, Tim Bird,
Andrew Morton
In-Reply-To: <4CD51969.3060603@gmail.com>
On Sat, 06 Nov 2010 10:01:29 +0100 Marco Stornelli wrote:
> From: Marco Stornelli <marco.stornelli@gmail.com>
>
> Makefile and Kconfig.
>
> Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com>
> ---
> +config TEST_MODULE
> + tristate "PRAMFS Test"
> + depends on PRAMFS && m
> + select PRAMFS_TEST
> + help
> + Say Y here to build a simple module to test the protection of
> + PRAMFS. The module will be called pramfs_test.
Since kconfig symbols are global, this one needs something like
PRAMFS_ as a prefix, please.
> diff -Nurp linux-2.6.36-orig/fs/pramfs/Makefile linux-2.6.36/fs/pramfs/Makefile
> --- linux-2.6.36-orig/fs/pramfs/Makefile 1970-01-01 01:00:00.000000000 +0100
> +++ linux-2.6.36/fs/pramfs/Makefile 2010-09-14 18:49:52.000000000 +0200
> @@ -0,0 +1,14 @@
> +#
> +# Makefile for the linux pram-filesystem routines.
> +#
> +
> +obj-$(CONFIG_PRAMFS) += pramfs.o
> +obj-$(CONFIG_TEST_MODULE) += pramfs_test.o
> +
> +pramfs-y := balloc.o dir.o file.o inode.o namei.o super.o symlink.o
> +
> +pramfs-$(CONFIG_PRAMFS_WRITE_PROTECT) += wprotect.o
> +pramfs-$(CONFIG_PRAMFS_XIP) += xip.o
> +pramfs-$(CONFIG_PRAMFS_XATTR) += xattr.o xattr_user.o xattr_trusted.o desctree.o
> +pramfs-$(CONFIG_PRAMFS_POSIX_ACL) += acl.o
> +pramfs-$(CONFIG_PRAMFS_SECURITY) += xattr_security.o
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH 15/16 v2] pramfs: test module
From: Randy Dunlap @ 2010-11-06 15:49 UTC (permalink / raw)
To: Marco Stornelli
Cc: Linux Kernel, Linux Embedded, Linux FS Devel, Tim Bird,
Andrew Morton
In-Reply-To: <4CD51958.6040308@gmail.com>
On Sat, 06 Nov 2010 10:01:12 +0100 Marco Stornelli wrote:
> From: Marco Stornelli <marco.stornelli@gmail.com>
>
> Test module.
>
> Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com>
> ---
> diff -Nurp linux-2.6.36-orig/fs/pramfs/pramfs_test.c linux-2.6.36/fs/pramfs/pramfs_test.c
> --- linux-2.6.36-orig/fs/pramfs/pramfs_test.c 1970-01-01 01:00:00.000000000 +0100
> +++ linux-2.6.36/fs/pramfs/pramfs_test.c 2010-09-14 18:49:52.000000000 +0200
> @@ -0,0 +1,49 @@
> +/*
> + * FILE NAME fs/pramfs/namei.c
> + *
> + * BRIEF DESCRIPTION
> + *
> + * Pramfs test module.
Wrong FILE NAME. Better to just omit it completely.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH 08/16 v2] pramfs: headers
From: Ryan Mallon @ 2010-11-07 20:09 UTC (permalink / raw)
To: Marco Stornelli
Cc: Linux Kernel, Linux Embedded, Linux FS Devel, Tim Bird,
Andrew Morton
In-Reply-To: <4CD518C5.6000509@gmail.com>
On 11/06/2010 09:58 PM, Marco Stornelli wrote:
> From: Marco Stornelli <marco.stornelli@gmail.com>
>
> Definitions for the PRAMFS filesystem.
>
> Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com>
> ---
> diff -Nurp linux-2.6.36-orig/fs/pramfs/pram.h linux-2.6.36/fs/pramfs/pram.h
> --- linux-2.6.36-orig/fs/pramfs/pram.h 1970-01-01 01:00:00.000000000 +0100
> +++ linux-2.6.36/fs/pramfs/pram.h 2010-10-30 12:02:45.000000000 +0200
> @@ -0,0 +1,317 @@
> +/*
> + * Structure of the super block in PRAMFS
> + */
> +struct pram_super_block {
> + __be16 s_sum; /* checksum of this sb, including padding */
> + __be64 s_size; /* total size of fs in bytes */
> + __be32 s_blocksize; /* blocksize in bytes */
> + __be32 s_inodes_count; /* total inodes count (used or free) */
> + __be32 s_free_inodes_count;/* free inodes count */
> + __be32 s_free_inode_hint; /* start hint for locating free inodes */
> + __be32 s_blocks_count; /* total data blocks count (used or free) */
> + __be32 s_free_blocks_count;/* free data blocks count */
> + __be32 s_free_blocknr_hint;/* free data blocks count */
> + __be64 s_bitmap_start; /* data block in-use bitmap location */
> + __be32 s_bitmap_blocks;/* size of bitmap in number of blocks */
> + __be32 s_mtime; /* Mount time */
> + __be32 s_wtime; /* Write time */
> + __be16 s_magic; /* Magic signature */
> + char s_volume_name[16]; /* volume name */
> +};
Is there a particular reason to use big endian types for the data
structures? On a little endian machine you will end up converting values
everywhere. I assume that you don't expect the machine to change
endianess between reboots :-). If this is for generating/reading
filesystems from userspace, wouldn't it be better to have the userspace
tools specify the target endianess and do the conversions there?
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
ryan@bluewatersys.com PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com New Zealand
Phone: +64 3 3779127 Freecall: Australia 1800 148 751
Fax: +64 3 3779135 USA 1800 261 2934
^ permalink raw reply
* Re: [PATCH 08/16 v2] pramfs: headers
From: Marco Stornelli @ 2010-11-08 7:49 UTC (permalink / raw)
To: Ryan Mallon
Cc: Linux Kernel, Linux Embedded, Linux FS Devel, Tim Bird,
Andrew Morton
In-Reply-To: <4CD7076D.80507@bluewatersys.com>
2010/11/7 Ryan Mallon <ryan@bluewatersys.com>:
> On 11/06/2010 09:58 PM, Marco Stornelli wrote:
>> From: Marco Stornelli <marco.stornelli@gmail.com>
>>
>> Definitions for the PRAMFS filesystem.
>>
>> Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com>
>> ---
>> diff -Nurp linux-2.6.36-orig/fs/pramfs/pram.h linux-2.6.36/fs/pramfs/pram.h
>> --- linux-2.6.36-orig/fs/pramfs/pram.h 1970-01-01 01:00:00.000000000 +0100
>> +++ linux-2.6.36/fs/pramfs/pram.h 2010-10-30 12:02:45.000000000 +0200
>> @@ -0,0 +1,317 @@
>
>> +/*
>> + * Structure of the super block in PRAMFS
>> + */
>> +struct pram_super_block {
>> + __be16 s_sum; /* checksum of this sb, including padding */
>> + __be64 s_size; /* total size of fs in bytes */
>> + __be32 s_blocksize; /* blocksize in bytes */
>> + __be32 s_inodes_count; /* total inodes count (used or free) */
>> + __be32 s_free_inodes_count;/* free inodes count */
>> + __be32 s_free_inode_hint; /* start hint for locating free inodes */
>> + __be32 s_blocks_count; /* total data blocks count (used or free) */
>> + __be32 s_free_blocks_count;/* free data blocks count */
>> + __be32 s_free_blocknr_hint;/* free data blocks count */
>> + __be64 s_bitmap_start; /* data block in-use bitmap location */
>> + __be32 s_bitmap_blocks;/* size of bitmap in number of blocks */
>> + __be32 s_mtime; /* Mount time */
>> + __be32 s_wtime; /* Write time */
>> + __be16 s_magic; /* Magic signature */
>> + char s_volume_name[16]; /* volume name */
>> +};
>
> Is there a particular reason to use big endian types for the data
> structures? On a little endian machine you will end up converting values
> everywhere. I assume that you don't expect the machine to change
> endianess between reboots :-). If this is for generating/reading
> filesystems from userspace, wouldn't it be better to have the userspace
> tools specify the target endianess and do the conversions there?
>
> ~Ryan
Yes, there is a reason. In the first review a comment was: the fs must
have a fix endianess layout. This fs is designed for the embedded
world mainly. Since most of cpus used in this case are big-endian, it
means that for typical use case, there is no cost for endianess
conversion.
Marco
^ permalink raw reply
* Re: [PATCH 08/16 v2] pramfs: headers
From: Ryan Mallon @ 2010-11-08 19:50 UTC (permalink / raw)
To: Marco Stornelli
Cc: Linux Kernel, Linux Embedded, Linux FS Devel, Tim Bird,
Andrew Morton
In-Reply-To: <AANLkTinJJG0K=BPS0CPzDWcgpRn_yPxZ819N408SwD6d@mail.gmail.com>
On 11/08/2010 08:49 PM, Marco Stornelli wrote:
> 2010/11/7 Ryan Mallon <ryan@bluewatersys.com>:
>> On 11/06/2010 09:58 PM, Marco Stornelli wrote:
>>> From: Marco Stornelli <marco.stornelli@gmail.com>
>>>
>>> Definitions for the PRAMFS filesystem.
>>>
>>> Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com>
>>> ---
>>> diff -Nurp linux-2.6.36-orig/fs/pramfs/pram.h linux-2.6.36/fs/pramfs/pram.h
>>> --- linux-2.6.36-orig/fs/pramfs/pram.h 1970-01-01 01:00:00.000000000 +0100
>>> +++ linux-2.6.36/fs/pramfs/pram.h 2010-10-30 12:02:45.000000000 +0200
>>> @@ -0,0 +1,317 @@
>>
>>> +/*
>>> + * Structure of the super block in PRAMFS
>>> + */
>>> +struct pram_super_block {
>>> + __be16 s_sum; /* checksum of this sb, including padding */
>>> + __be64 s_size; /* total size of fs in bytes */
>>> + __be32 s_blocksize; /* blocksize in bytes */
>>> + __be32 s_inodes_count; /* total inodes count (used or free) */
>>> + __be32 s_free_inodes_count;/* free inodes count */
>>> + __be32 s_free_inode_hint; /* start hint for locating free inodes */
>>> + __be32 s_blocks_count; /* total data blocks count (used or free) */
>>> + __be32 s_free_blocks_count;/* free data blocks count */
>>> + __be32 s_free_blocknr_hint;/* free data blocks count */
>>> + __be64 s_bitmap_start; /* data block in-use bitmap location */
>>> + __be32 s_bitmap_blocks;/* size of bitmap in number of blocks */
>>> + __be32 s_mtime; /* Mount time */
>>> + __be32 s_wtime; /* Write time */
>>> + __be16 s_magic; /* Magic signature */
>>> + char s_volume_name[16]; /* volume name */
>>> +};
>>
>> Is there a particular reason to use big endian types for the data
>> structures? On a little endian machine you will end up converting values
>> everywhere. I assume that you don't expect the machine to change
>> endianess between reboots :-). If this is for generating/reading
>> filesystems from userspace, wouldn't it be better to have the userspace
>> tools specify the target endianess and do the conversions there?
>>
>> ~Ryan
>
> Yes, there is a reason. In the first review a comment was: the fs must
> have a fix endianess layout. This fs is designed for the embedded
> world mainly. Since most of cpus used in this case are big-endian, it
> means that for typical use case, there is no cost for endianess
> conversion.
ARM, which is a large portion of the embedded space, is typically little
endian.
Why does a filesystem need to have a specific endianess layout?
Especially for a highly specialised filesystem like this.
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
ryan@bluewatersys.com PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com New Zealand
Phone: +64 3 3779127 Freecall: Australia 1800 148 751
Fax: +64 3 3779135 USA 1800 261 2934
^ permalink raw reply
* Re: [PATCH 08/16 v2] pramfs: headers
From: Marco Stornelli @ 2010-11-09 8:19 UTC (permalink / raw)
To: Ryan Mallon
Cc: Linux Kernel, Linux Embedded, Linux FS Devel, Tim Bird,
Andrew Morton
In-Reply-To: <4CD85489.8000503@bluewatersys.com>
2010/11/8 Ryan Mallon <ryan@bluewatersys.com>:
> On 11/08/2010 08:49 PM, Marco Stornelli wrote:
>> 2010/11/7 Ryan Mallon <ryan@bluewatersys.com>:
>>> On 11/06/2010 09:58 PM, Marco Stornelli wrote:
>>>> From: Marco Stornelli <marco.stornelli@gmail.com>
>>>>
>>>> Definitions for the PRAMFS filesystem.
>>>>
>>>> Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com>
>>>> ---
>>>> diff -Nurp linux-2.6.36-orig/fs/pramfs/pram.h linux-2.6.36/fs/pramfs/pram.h
>>>> --- linux-2.6.36-orig/fs/pramfs/pram.h 1970-01-01 01:00:00.000000000 +0100
>>>> +++ linux-2.6.36/fs/pramfs/pram.h 2010-10-30 12:02:45.000000000 +0200
>>>> @@ -0,0 +1,317 @@
>>>
>>>> +/*
>>>> + * Structure of the super block in PRAMFS
>>>> + */
>>>> +struct pram_super_block {
>>>> + __be16 s_sum; /* checksum of this sb, including padding */
>>>> + __be64 s_size; /* total size of fs in bytes */
>>>> + __be32 s_blocksize; /* blocksize in bytes */
>>>> + __be32 s_inodes_count; /* total inodes count (used or free) */
>>>> + __be32 s_free_inodes_count;/* free inodes count */
>>>> + __be32 s_free_inode_hint; /* start hint for locating free inodes */
>>>> + __be32 s_blocks_count; /* total data blocks count (used or free) */
>>>> + __be32 s_free_blocks_count;/* free data blocks count */
>>>> + __be32 s_free_blocknr_hint;/* free data blocks count */
>>>> + __be64 s_bitmap_start; /* data block in-use bitmap location */
>>>> + __be32 s_bitmap_blocks;/* size of bitmap in number of blocks */
>>>> + __be32 s_mtime; /* Mount time */
>>>> + __be32 s_wtime; /* Write time */
>>>> + __be16 s_magic; /* Magic signature */
>>>> + char s_volume_name[16]; /* volume name */
>>>> +};
>>>
>>> Is there a particular reason to use big endian types for the data
>>> structures? On a little endian machine you will end up converting values
>>> everywhere. I assume that you don't expect the machine to change
>>> endianess between reboots :-). If this is for generating/reading
>>> filesystems from userspace, wouldn't it be better to have the userspace
>>> tools specify the target endianess and do the conversions there?
>>>
>>> ~Ryan
>>
>> Yes, there is a reason. In the first review a comment was: the fs must
>> have a fix endianess layout. This fs is designed for the embedded
>> world mainly. Since most of cpus used in this case are big-endian, it
>> means that for typical use case, there is no cost for endianess
>> conversion.
>
> ARM, which is a large portion of the embedded space, is typically little
> endian.
Not always. Indeed, I didn't say *all* cpu used are big-endian.
>
> Why does a filesystem need to have a specific endianess layout?
> Especially for a highly specialised filesystem like this.
>
I didn't agree with it, but in the first review there was more than
one developer that said this thing. The main reason was to read the
format (for example with JTAG) or to create an image with a fix
format. I remember that someone said that there was a similar problem
with jffs2 and the experience tell to us that a fix endianess is
important. At that point I decided to use big-endian. You can see all
the discussion in lkml. The review has been done at June 2009.
Regards,
Marco
^ permalink raw reply
* Re: Embedded Linux Flag Version
From: Mike Frysinger @ 2010-11-09 11:19 UTC (permalink / raw)
To: Tim Bird; +Cc: linux-embedded
In-Reply-To: <4CD32EA0.4070805@am.sony.com>
On Thu, Nov 4, 2010 at 18:07, Tim Bird wrote:
> It was noted at the summit that several CE companies and embedded
> projects will be using (or are already using) 2.6.35 for upcoming
> products or releases. This includes Sony, Google, Meego, and Linaro. On
> behalf of the CE Linux Forum and a number of consumer electronics
> companies, projects and community developers, we therefore declare
> 2.6.35 as a flag version of the kernel for embedded use. Several
> companies will be investing in development, integration and testing of
> this version. Entities wanting to do business with those companies would
> therefore be well-advised to make sure their hardware, drivers and
> enhancements work well with this version of the kernel.
wouldnt it make more sense to piggy back the extensive work going into
the "stable" tree ? many of the points you raise after all are the
entire founding point of it. plus, all the main distros form around
that, are spending time working on that, is marked as supported for 2
or 3 years, and there is already infrastructure/framework/process in
place (stable@kernel.org).
so instead of picking arbitrary versions (like 2.6.35) and needlessly
replicating the huge work load, simply declare these stable trees as
the "flag" versions. that means today it'd be 2.6.32.y.
-mike
^ permalink raw reply
* Re: Embedded Linux Flag Version
From: Tim Bird @ 2010-11-09 17:17 UTC (permalink / raw)
To: Mike Frysinger; +Cc: linux-embedded@vger.kernel.org
In-Reply-To: <AANLkTikusrr073mUz3BQ3wP=y7E8WcDDayVms=PPhH8A@mail.gmail.com>
On 11/09/2010 03:19 AM, Mike Frysinger wrote:
> On Thu, Nov 4, 2010 at 18:07, Tim Bird wrote:
>> It was noted at the summit that several CE companies and embedded
>> projects will be using (or are already using) 2.6.35 for upcoming
>> products or releases. This includes Sony, Google, Meego, and Linaro. On
>> behalf of the CE Linux Forum and a number of consumer electronics
>> companies, projects and community developers, we therefore declare
>> 2.6.35 as a flag version of the kernel for embedded use. Several
>> companies will be investing in development, integration and testing of
>> this version. Entities wanting to do business with those companies would
>> therefore be well-advised to make sure their hardware, drivers and
>> enhancements work well with this version of the kernel.
>
> wouldnt it make more sense to piggy back the extensive work going into
> the "stable" tree ? many of the points you raise after all are the
> entire founding point of it. plus, all the main distros form around
> that, are spending time working on that, is marked as supported for 2
> or 3 years, and there is already infrastructure/framework/process in
> place (stable@kernel.org).
>
> so instead of picking arbitrary versions (like 2.6.35) and needlessly
> replicating the huge work load, simply declare these stable trees as
> the "flag" versions. that means today it'd be 2.6.32.y.
The fact that this tree is already a year old, and not likely to be
brought forward for at least another 2 years is the reason we didn't
choose it this time. Most of the high-profile, active embedded projects
are already on 2.6.35. For companies looking to adopt a new base kernel
in the next 12 months, I don't want to have them start with a year-old
kernel. We did consider the utility of synchronizing with the enterprise
stable tree, but the timing just didn't work too well this time around.
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Network Entertainment
=============================
^ permalink raw reply
* Re: Embedded Linux Flag Version
From: Nicholas Mc Guire @ 2010-11-09 17:25 UTC (permalink / raw)
To: Tim Bird; +Cc: Mike Frysinger, linux-embedded@vger.kernel.org
In-Reply-To: <4CD98220.40806@am.sony.com>
On Tue, 09 Nov 2010, Tim Bird wrote:
> On 11/09/2010 03:19 AM, Mike Frysinger wrote:
> > On Thu, Nov 4, 2010 at 18:07, Tim Bird wrote:
> >> It was noted at the summit that several CE companies and embedded
> >> projects will be using (or are already using) 2.6.35 for upcoming
> >> products or releases. This includes Sony, Google, Meego, and Linaro. On
> >> behalf of the CE Linux Forum and a number of consumer electronics
> >> companies, projects and community developers, we therefore declare
> >> 2.6.35 as a flag version of the kernel for embedded use. Several
> >> companies will be investing in development, integration and testing of
> >> this version. Entities wanting to do business with those companies would
> >> therefore be well-advised to make sure their hardware, drivers and
> >> enhancements work well with this version of the kernel.
> >
> > wouldnt it make more sense to piggy back the extensive work going into
> > the "stable" tree ? many of the points you raise after all are the
> > entire founding point of it. plus, all the main distros form around
> > that, are spending time working on that, is marked as supported for 2
> > or 3 years, and there is already infrastructure/framework/process in
> > place (stable@kernel.org).
> >
> > so instead of picking arbitrary versions (like 2.6.35) and needlessly
> > replicating the huge work load, simply declare these stable trees as
> > the "flag" versions. that means today it'd be 2.6.32.y.
>
> The fact that this tree is already a year old, and not likely to be
> brought forward for at least another 2 years is the reason we didn't
> choose it this time. Most of the high-profile, active embedded projects
> are already on 2.6.35. For companies looking to adopt a new base kernel
> in the next 12 months, I don't want to have them start with a year-old
> kernel. We did consider the utility of synchronizing with the enterprise
> stable tree, but the timing just didn't work too well this time around.
>
I guess one of the key issues is that it would need to be defined beforehand
what version will be used as the next "flag" version so vendors could make
sure that there drivers are available. Further if such a selection were to
be made then there would need to be consesus on maintaining the respective
version for a sufficiently long time to allow for the next "flag" version
to evolve. Finally for those working on products even if you would now define
the current version as the "flag" version it would not help much as they
would hardly be able to shift to a different kernel short term - so again the
key is defining what version would be atleast planed for the next "flag"
version - something like now defining it to be 2.6.38 - and then testing
appropriately in the runup to 2.6.38 to deliver, most notably for the
embedded architectures.
thx!
hofrat
^ permalink raw reply
* Re: Embedded Linux Flag Version
From: Tim Bird @ 2010-11-09 17:57 UTC (permalink / raw)
To: Nicholas Mc Guire; +Cc: Mike Frysinger, linux-embedded@vger.kernel.org
In-Reply-To: <20101109172501.GA18326@opentech.at>
On 11/09/2010 09:25 AM, Nicholas Mc Guire wrote:
> I guess one of the key issues is that it would need to be defined beforehand
> what version will be used as the next "flag" version so vendors could make
> sure that there drivers are available.
Yeah. People keep asking about that. Unfortunately, this was
not discussed or settled on - so I can't really comment on that
as an industry representative. However, I will say that we'd like
to work to synchronize our next flag version with the next
enterprise stable release. (But again, it will depend on timing).
Personally (not speaking on behalf of anyone else here), I think
there would be a certain poetry to selecting 2.6.42 (which may
just also be the same as or one before kernel version 3.1)
;-)
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Network Entertainment
=============================
^ permalink raw reply
* Re: Embedded Linux Flag Version
From: Nicolas Pitre @ 2010-11-09 18:38 UTC (permalink / raw)
To: Nicholas Mc Guire
Cc: Tim Bird, Mike Frysinger, linux-embedded@vger.kernel.org
In-Reply-To: <20101109172501.GA18326@opentech.at>
On Tue, 9 Nov 2010, Nicholas Mc Guire wrote:
> On Tue, 09 Nov 2010, Tim Bird wrote:
>
> > On 11/09/2010 03:19 AM, Mike Frysinger wrote:
> > > On Thu, Nov 4, 2010 at 18:07, Tim Bird wrote:
> > >> It was noted at the summit that several CE companies and embedded
> > >> projects will be using (or are already using) 2.6.35 for upcoming
> > >> products or releases. This includes Sony, Google, Meego, and Linaro. On
> > >> behalf of the CE Linux Forum and a number of consumer electronics
> > >> companies, projects and community developers, we therefore declare
> > >> 2.6.35 as a flag version of the kernel for embedded use. Several
> > >> companies will be investing in development, integration and testing of
> > >> this version. Entities wanting to do business with those companies would
> > >> therefore be well-advised to make sure their hardware, drivers and
> > >> enhancements work well with this version of the kernel.
> > >
> > > wouldnt it make more sense to piggy back the extensive work going into
> > > the "stable" tree ? many of the points you raise after all are the
> > > entire founding point of it. plus, all the main distros form around
> > > that, are spending time working on that, is marked as supported for 2
> > > or 3 years, and there is already infrastructure/framework/process in
> > > place (stable@kernel.org).
> > >
> > > so instead of picking arbitrary versions (like 2.6.35) and needlessly
> > > replicating the huge work load, simply declare these stable trees as
> > > the "flag" versions. that means today it'd be 2.6.32.y.
> >
> > The fact that this tree is already a year old, and not likely to be
> > brought forward for at least another 2 years is the reason we didn't
> > choose it this time. Most of the high-profile, active embedded projects
> > are already on 2.6.35. For companies looking to adopt a new base kernel
> > in the next 12 months, I don't want to have them start with a year-old
> > kernel. We did consider the utility of synchronizing with the enterprise
> > stable tree, but the timing just didn't work too well this time around.
> >
> I guess one of the key issues is that it would need to be defined beforehand
> what version will be used as the next "flag" version so vendors could make
> sure that there drivers are available. Further if such a selection were to
> be made then there would need to be consesus on maintaining the respective
> version for a sufficiently long time to allow for the next "flag" version
> to evolve. Finally for those working on products even if you would now define
> the current version as the "flag" version it would not help much as they
> would hardly be able to shift to a different kernel short term - so again the
> key is defining what version would be atleast planed for the next "flag"
> version - something like now defining it to be 2.6.38 - and then testing
> appropriately in the runup to 2.6.38 to deliver, most notably for the
> embedded architectures.
FWIW, the imminent Linaro release is using 2.6.35. The next release
scheduled for May 2011 will most probably use 2.6.38.
Nicolas
^ permalink raw reply
* Re: [PATCH 08/16 v2] pramfs: headers
From: Ryan Mallon @ 2010-11-09 20:35 UTC (permalink / raw)
To: Marco Stornelli
Cc: Linux Kernel, Linux Embedded, Linux FS Devel, Tim Bird,
Andrew Morton
In-Reply-To: <AANLkTim8rAQnVYpZdykd2VuL1N9CvkGj88Kf5qpSuJsC@mail.gmail.com>
On 11/09/2010 09:19 PM, Marco Stornelli wrote:
> 2010/11/8 Ryan Mallon <ryan@bluewatersys.com>:
>> On 11/08/2010 08:49 PM, Marco Stornelli wrote:
>>> 2010/11/7 Ryan Mallon <ryan@bluewatersys.com>:
>>>> On 11/06/2010 09:58 PM, Marco Stornelli wrote:
>>>>> From: Marco Stornelli <marco.stornelli@gmail.com>
>>>>>
>>>>> Definitions for the PRAMFS filesystem.
>>>>>
>>>>> Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com>
>>>>> ---
>>>>> diff -Nurp linux-2.6.36-orig/fs/pramfs/pram.h linux-2.6.36/fs/pramfs/pram.h
>>>>> --- linux-2.6.36-orig/fs/pramfs/pram.h 1970-01-01 01:00:00.000000000 +0100
>>>>> +++ linux-2.6.36/fs/pramfs/pram.h 2010-10-30 12:02:45.000000000 +0200
>>>>> @@ -0,0 +1,317 @@
>>>>
>>>>> +/*
>>>>> + * Structure of the super block in PRAMFS
>>>>> + */
>>>>> +struct pram_super_block {
>>>>> + __be16 s_sum; /* checksum of this sb, including padding */
>>>>> + __be64 s_size; /* total size of fs in bytes */
>>>>> + __be32 s_blocksize; /* blocksize in bytes */
>>>>> + __be32 s_inodes_count; /* total inodes count (used or free) */
>>>>> + __be32 s_free_inodes_count;/* free inodes count */
>>>>> + __be32 s_free_inode_hint; /* start hint for locating free inodes */
>>>>> + __be32 s_blocks_count; /* total data blocks count (used or free) */
>>>>> + __be32 s_free_blocks_count;/* free data blocks count */
>>>>> + __be32 s_free_blocknr_hint;/* free data blocks count */
>>>>> + __be64 s_bitmap_start; /* data block in-use bitmap location */
>>>>> + __be32 s_bitmap_blocks;/* size of bitmap in number of blocks */
>>>>> + __be32 s_mtime; /* Mount time */
>>>>> + __be32 s_wtime; /* Write time */
>>>>> + __be16 s_magic; /* Magic signature */
>>>>> + char s_volume_name[16]; /* volume name */
>>>>> +};
>>>>
>>>> Is there a particular reason to use big endian types for the data
>>>> structures? On a little endian machine you will end up converting values
>>>> everywhere. I assume that you don't expect the machine to change
>>>> endianess between reboots :-). If this is for generating/reading
>>>> filesystems from userspace, wouldn't it be better to have the userspace
>>>> tools specify the target endianess and do the conversions there?
>>>>
>>>> ~Ryan
>>>
>>> Yes, there is a reason. In the first review a comment was: the fs must
>>> have a fix endianess layout. This fs is designed for the embedded
>>> world mainly. Since most of cpus used in this case are big-endian, it
>>> means that for typical use case, there is no cost for endianess
>>> conversion.
>>
>> ARM, which is a large portion of the embedded space, is typically little
>> endian.
>
> Not always. Indeed, I didn't say *all* cpu used are big-endian.
My point is that little endian embedded machines make up a large portion
of the devices that this filesystem will be useful on. On those devices
it will also have an (unnecessary) conversion overhead.
>>
>> Why does a filesystem need to have a specific endianess layout?
>> Especially for a highly specialised filesystem like this.
>>
>
> I didn't agree with it, but in the first review there was more than
> one developer that said this thing. The main reason was to read the
> format (for example with JTAG) or to create an image with a fix
> format. I remember that someone said that there was a similar problem
> with jffs2 and the experience tell to us that a fix endianess is
> important. At that point I decided to use big-endian. You can see all
> the discussion in lkml. The review has been done at June 2009.
You can still do all of those things without having a fixed endianess.
You just have to have one extra step of telling the external tools what
the endianess is. IMHO, it is better to have the overhead of the endian
conversion in the tools since it is less costly there than an the
embedded system.
I'm just trying to understand why the fixed endianess rule cannot be
bent for such a specialised filesystem.
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
ryan@bluewatersys.com PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com New Zealand
Phone: +64 3 3779127 Freecall: Australia 1800 148 751
Fax: +64 3 3779135 USA 1800 261 2934
^ permalink raw reply
* Re: [PATCH 08/16 v2] pramfs: headers
From: Geert Uytterhoeven @ 2010-11-09 20:56 UTC (permalink / raw)
To: Ryan Mallon
Cc: Marco Stornelli, Linux Kernel, Linux Embedded, Linux FS Devel,
Tim Bird, Andrew Morton
In-Reply-To: <4CD9B09F.5090707@bluewatersys.com>
On Tue, Nov 9, 2010 at 21:35, Ryan Mallon <ryan@bluewatersys.com> wrote:
> On 11/09/2010 09:19 PM, Marco Stornelli wrote:
>> 2010/11/8 Ryan Mallon <ryan@bluewatersys.com>:
>>> On 11/08/2010 08:49 PM, Marco Stornelli wrote:
>>>> 2010/11/7 Ryan Mallon <ryan@bluewatersys.com>:
>>>>> On 11/06/2010 09:58 PM, Marco Stornelli wrote:
>>>>>> From: Marco Stornelli <marco.stornelli@gmail.com>
>>>>>>
>>>>>> Definitions for the PRAMFS filesystem.
>>>>>>
>>>>>> Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com>
>>>>>> ---
>>>>>> diff -Nurp linux-2.6.36-orig/fs/pramfs/pram.h linux-2.6.36/fs/pramfs/pram.h
>>>>>> --- linux-2.6.36-orig/fs/pramfs/pram.h 1970-01-01 01:00:00.000000000 +0100
>>>>>> +++ linux-2.6.36/fs/pramfs/pram.h 2010-10-30 12:02:45.000000000 +0200
>>>>>> @@ -0,0 +1,317 @@
>>>>>
>>>>>> +/*
>>>>>> + * Structure of the super block in PRAMFS
>>>>>> + */
>>>>>> +struct pram_super_block {
>>>>>> + __be16 s_sum; /* checksum of this sb, including padding */
>>>>>> + __be64 s_size; /* total size of fs in bytes */
>>>>>> + __be32 s_blocksize; /* blocksize in bytes */
>>>>>> + __be32 s_inodes_count; /* total inodes count (used or free) */
>>>>>> + __be32 s_free_inodes_count;/* free inodes count */
>>>>>> + __be32 s_free_inode_hint; /* start hint for locating free inodes */
>>>>>> + __be32 s_blocks_count; /* total data blocks count (used or free) */
>>>>>> + __be32 s_free_blocks_count;/* free data blocks count */
>>>>>> + __be32 s_free_blocknr_hint;/* free data blocks count */
>>>>>> + __be64 s_bitmap_start; /* data block in-use bitmap location */
>>>>>> + __be32 s_bitmap_blocks;/* size of bitmap in number of blocks */
>>>>>> + __be32 s_mtime; /* Mount time */
>>>>>> + __be32 s_wtime; /* Write time */
>>>>>> + __be16 s_magic; /* Magic signature */
>>>>>> + char s_volume_name[16]; /* volume name */
>>>>>> +};
>>>>>
>>>>> Is there a particular reason to use big endian types for the data
>>>>> structures? On a little endian machine you will end up converting values
>>>>> everywhere. I assume that you don't expect the machine to change
>>>>> endianess between reboots :-). If this is for generating/reading
>>>>> filesystems from userspace, wouldn't it be better to have the userspace
>>>>> tools specify the target endianess and do the conversions there?
>>>>>
>>>>> ~Ryan
>>>>
>>>> Yes, there is a reason. In the first review a comment was: the fs must
>>>> have a fix endianess layout. This fs is designed for the embedded
>>>> world mainly. Since most of cpus used in this case are big-endian, it
>>>> means that for typical use case, there is no cost for endianess
>>>> conversion.
>>>
>>> ARM, which is a large portion of the embedded space, is typically little
>>> endian.
>>
>> Not always. Indeed, I didn't say *all* cpu used are big-endian.
>
> My point is that little endian embedded machines make up a large portion
> of the devices that this filesystem will be useful on. On those devices
> it will also have an (unnecessary) conversion overhead.
>
>>> Why does a filesystem need to have a specific endianess layout?
>>> Especially for a highly specialised filesystem like this.
>>
>> I didn't agree with it, but in the first review there was more than
>> one developer that said this thing. The main reason was to read the
>> format (for example with JTAG) or to create an image with a fix
>> format. I remember that someone said that there was a similar problem
>> with jffs2 and the experience tell to us that a fix endianess is
>> important. At that point I decided to use big-endian. You can see all
>> the discussion in lkml. The review has been done at June 2009.
>
> You can still do all of those things without having a fixed endianess.
> You just have to have one extra step of telling the external tools what
> the endianess is. IMHO, it is better to have the overhead of the endian
> conversion in the tools since it is less costly there than an the
> embedded system.
>
> I'm just trying to understand why the fixed endianess rule cannot be
> bent for such a specialised filesystem.
When it was decided that filesystems should be fixed-endian and support for
big-endian ext2 was dropped, the overhead of doing the fixed conversions was
deetermined negligible due to compiler optimization.
That was ages ago, and current embedded systems run circles around the
machines of those days.
Note that this is about metadata only. Actual file contents are always just
byte streams.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-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
* Avoiding platform-specific callbacks in drivers?
From: Bill Gatliff @ 2010-11-09 22:32 UTC (permalink / raw)
To: linux-embedded
Guys:
Let's say that on a given platform, I need to twiddle with a GPIO pin
when a chip enters and exits suspend. One way to do that is to hack
the driver itself; a slightly less-inelegant way is to add a function
pointer in the platform data, and have the driver call back in its
suspend() and resume() methods. I'm not real keen on either strategy,
because they both involve touching driver code that should be
platform-agnostic. They seem... hacky. :)
I would love to come up with a way that prevents touching the driver
at all, since the activity is terribly platform-specific. Is there
such a way?
One possibility is to set up some sort of parent-child relationship
between the device and a pseudo-device that deals with the GPIO pin.
But I'm not sure that will actually work, and it seems a bit
overly-complicated.
Ideas, anyone? I'll be happy to try them out if they seem feasible,
and post code and feedback.
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: Avoiding platform-specific callbacks in drivers?
From: Kevin Dankwardt @ 2010-11-10 0:02 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <AANLkTinG4y_Uxes0CJYMH+uwr1TcWwjQy+4+_ftyrnML@mail.gmail.com>
> Guys:
>
>
> Let's say that on a given platform, I need to twiddle with a GPIO pin
> when a chip enters and exits suspend. One way to do that is to hack
> the driver itself; a slightly less-inelegant way is to add a function
> pointer in the platform data, and have the driver call back in its
> suspend() and resume() methods. I'm not real keen on either strategy,
> because they both involve touching driver code that should be
> platform-agnostic. They seem... hacky. :)
>
> I would love to come up with a way that prevents touching the driver
> at all, since the activity is terribly platform-specific. Is there
> such a way?
>
> One possibility is to set up some sort of parent-child relationship
> between the device and a pseudo-device that deals with the GPIO pin.
> But I'm not sure that will actually work, and it seems a bit
> overly-complicated.
>
> Ideas, anyone? I'll be happy to try them out if they seem feasible,
> and post code and feedback.
>
>
> b.g.
>
Isn't the general approach to avoid platform-dependencies to abstract
the behavior? As is used throughout the kernel, an "operations" struct
that provides the abstractions and each driver fills in its
implementation as required. The "polymorphism" approach. Maybe the
operations are "begin_suspend()" and "end_suspend()" and in this case
the functions twiddle a GPIO pin?
^ permalink raw reply
* Re: Avoiding platform-specific callbacks in drivers?
From: Nicolas Pitre @ 2010-11-10 0:10 UTC (permalink / raw)
To: Bill Gatliff; +Cc: linux-embedded
In-Reply-To: <AANLkTinG4y_Uxes0CJYMH+uwr1TcWwjQy+4+_ftyrnML@mail.gmail.com>
On Tue, 9 Nov 2010, Bill Gatliff wrote:
> Let's say that on a given platform, I need to twiddle with a GPIO pin
> when a chip enters and exits suspend.
What driver? What platform? This may depend on those.
> One way to do that is to hack the driver itself; a slightly
> less-inelegant way is to add a function pointer in the platform data,
> and have the driver call back in its suspend() and resume() methods.
> I'm not real keen on either strategy, because they both involve
> touching driver code that should be platform-agnostic. They seem...
> hacky. :)
Sure. but if it makes sense for your hardware to do this GPIO
twiddling, maybe someone else is doing that too. In which case a driver
solution might be justifiable.
> I would love to come up with a way that prevents touching the driver
> at all, since the activity is terribly platform-specific. Is there
> such a way?
>
> One possibility is to set up some sort of parent-child relationship
> between the device and a pseudo-device that deals with the GPIO pin.
> But I'm not sure that will actually work, and it seems a bit
> overly-complicated.
That would still be your best bet. The pseudo-device could register the
real device and set itself as the parent.
Nicolas
^ permalink raw reply
* Re: Avoiding platform-specific callbacks in drivers?
From: Bill Gatliff @ 2010-11-10 4:11 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: linux-embedded
In-Reply-To: <alpine.LFD.2.00.1011091905540.13911@xanadu.home>
Nicolas:
On Tue, Nov 9, 2010 at 6:10 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
>
> The pseudo-device could register the
> real device and set itself as the parent.
That little tidbit there is the part I seem to have been missing
before now--- actually doing the physical device registration during
the probing of the pseudo-device. With that, the approach actually
makes sense.
Before now, I was thinking that I would still register both devices
externally, which made things clumsy to think about.
Thanks!
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: Avoiding platform-specific callbacks in drivers?
From: Bill Gatliff @ 2010-11-10 4:17 UTC (permalink / raw)
To: Kevin Dankwardt; +Cc: linux-embedded
In-Reply-To: <4CD9E125.2010207@kcomputing.com>
Kevin:
On Tue, Nov 9, 2010 at 6:02 PM, Kevin Dankwardt <k@kcomputing.com> wrote:
> Isn't the general approach to avoid platform-dependencies to abstract the
> behavior? As is used throughout the kernel, an "operations" struct that
> provides the abstractions and each driver fills in its implementation as
> required. The "polymorphism" approach. Maybe the operations are
> "begin_suspend()" and "end_suspend()" and in this case the functions twiddle
> a GPIO pin?
The begin_suspend()/end_suspend() approach just moves the problem, really.
Unless you put those function pointers into the platform data, you
can't change them without touching the driver code. And if you do put
those function pointers into the platform data, that seems an awful
lot like open-coding. Gets the job done, but seems a fairly blunt
instrument.
In my case, the device model itself already provides the answer. The
"GPIO twiddling" can be dealt with by implementing a pseudo-device
that registers the actual device underneath it. Then the pseudo
device neatly gets the suspend/resume events at the right times
relative to the device. AND you get the benefits of sysfs and debugfs
for free.
I knew the answer was there; it just took an expert like Nicolas Pitre
to point out the obvious to me. I can be so dense sometimes! :)
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: [PATCH 08/16 v2] pramfs: headers
From: Marco Stornelli @ 2010-11-10 8:15 UTC (permalink / raw)
To: Ryan Mallon
Cc: Geert Uytterhoeven, Linux Kernel, Linux Embedded, Linux FS Devel,
Tim Bird, Andrew Morton
In-Reply-To: <AANLkTiky0LLnipJN3tCwcW6F2LEK-REEd=Ovo0ewMubR@mail.gmail.com>
2010/11/9 Geert Uytterhoeven <geert@linux-m68k.org>:
> On Tue, Nov 9, 2010 at 21:35, Ryan Mallon <ryan@bluewatersys.com> wrote:
>> You can still do all of those things without having a fixed endianess.
>> You just have to have one extra step of telling the external tools what
>> the endianess is. IMHO, it is better to have the overhead of the endian
>> conversion in the tools since it is less costly there than an the
>> embedded system.
>>
>> I'm just trying to understand why the fixed endianess rule cannot be
>> bent for such a specialised filesystem.
>
> When it was decided that filesystems should be fixed-endian and support for
> big-endian ext2 was dropped, the overhead of doing the fixed conversions was
> deetermined negligible due to compiler optimization.
> That was ages ago, and current embedded systems run circles around the
> machines of those days.
>
> Note that this is about metadata only. Actual file contents are always just
> byte streams.
>
I can add that the penalties in this case are negligible due to the
compensation of the very fast access of the media. In addition, from
performance point of view I'm pretty happy (you can see the some
benchmark on the project web site).
Marco
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox