Re: [RFC/PATCH 0/5] add execute in place support

[Carsten Otte <cotte@freenet.de>]

David Woodhouse wrote:

>On Wed, 2005-05-11 at 16:29 +0200, Carsten Otte wrote:
>  
>
>>. This is also useful on embedded systems where the block device is
>>located on a flash chip.
>>    
>>
>
>On Wed, 2005-05-11 at 17:33 +0200, Carsten Otte wrote:
>  
>
>>Indeed that seems reasonable. There is no exact reason to have
>>this built into a kernel on a platform that does not have a bdev
>>for this.
>>    
>>
>
>The sanest way to use flash chips is not to pretend that they're a block
>device at all; rather to use a file system directly on top of them. 
>
>But although you _talk_ about block devices, your code does look like it
>should be usable even by flash file systems. I'll try to come up with a
>test case using it on flash.
>
>  
>
Yes and no. For execute in place to work proper, you need an
allignment of data to page boundaries "on disk" (or on flash)
just like you have when mmap()ing to userland.
Before choosing second extended, I also looked at some
flash/rom filesystems. But I was unable to identify one that
alligns the data proper (and does not compress things or
such). The ext family with block size == PAGE_SIZE does
fullfill that requirement once the "block device" starts on page
boundary.
On the other hand I believe that a filesystem specificaly
designed for flash can provide less metadata overhead then
second extended. Would also be interresting in our use-case
on s390.

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