add execute in place support

. This is also useful on embedded systems where the block device is located on a flash chip.

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.

Quoted 4 lines · Carsten Otte

. This is also useful on embedded systems where the block device is located on a flash chip.

Quoted 5 lines · Carsten Otte

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.

Quoted 1 line

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.

In principle, both the block device abstraction and the mtd

abstraction fit your bill. But jffs2 doesn't, so no in-kernel fs could make use of a xip-aware mtd abstraction.

In principle, both the block device abstraction and the mtd abstraction fit your bill. But jffs2 doesn't, so no in-kernel fs could make use of a xip-aware mtd abstraction.

Patching jffs2 for xip looks like a major effort, at best, and utterly insane at worst. I'd prefer not to go down that path.

Quoted 6 lines · Jörn Engel

In principle, both the block device abstraction and the mtd abstraction fit your bill. But jffs2 doesn't, so no in-kernel fs could make use of a xip-aware mtd abstraction.

Patching jffs2 for xip looks like a major effort, at best, and utterly insane at worst. I'd prefer not to go down that path.

You and me both. The time has definitely come to recognise that JFFS2 needs replacing ;)

Quoted 5 lines · David Woodhouse

Quoted 4 lines · Jörn Engel

In principle, both the block device abstraction and the mtd abstraction fit your bill. But jffs2 doesn't, so no in-kernel fs could make use of a xip-aware mtd abstraction.

Quoted 5 lines

Quoted 2 lines

Patching jffs2 for xip looks like a major effort, at best, and utterly insane at worst. I'd prefer not to go down that path.

You and me both. The time has definitely come to recognise that JFFS2 needs replacing ;)

I'd say yaffs seems to be a good one.

Folks,

this is the intro to a small series of patches that introduce execute in place into the I/O stack. File I/O to memory-backed block devices is performed directly, bypassing the page cache and io schedulers. On s390, we use this for block devices based on shared memory between multiple virtual machines. This is also useful on embedded systems where the block device is located on a flash chip. This work is a result of a prior discussion with Andrew Morton about my first implementation which basically was a filesystem derived from ext2.

As I'd like to aim for integration into -mm and vanilla later on, I'd like to encourage everyone to give it a read and provide feedback. All patches apply against git-head as of today.

Quoted 4 lines

As I'd like to aim for integration into -mm and vanilla later on, I'd like to encourage everyone to give it a read and provide feedback. All patches apply against git-head as of today.

I feel the name "execute in place" misleading. This is not the real XIP, IMHO. Invent another term or be tolerant?

Quoted 5 lines · Coywolf Qi Hunt

Quoted 4 lines

As I'd like to aim for integration into -mm and vanilla later on, I'd like to encourage everyone to give it a read and provide feedback. All patches apply against git-head as of today.

Quoted 2 lines

I feel the name "execute in place" misleading. This is not the real XIP, IMHO. Invent another term or be tolerant?

If this is not real execute in place, then what is? The term seems to describe the patch rather well and we don't have this ability for Linux applications anywhere else, at least not in official kernels.

Quoted 12 lines · Arnd Bergmann

Quoted 9 lines · Coywolf Qi Hunt

Quoted 5 lines

As I'd like to aim for integration into -mm and vanilla later on, I'd like to encourage everyone to give it a read and provide feedback. All patches apply against git-head as of today.

I feel the name "execute in place" misleading. This is not the real XIP, IMHO. Invent another term or be tolerant?

Quoted 5 lines

If this is not real execute in place, then what is? The term seems to describe the patch rather well and we don't have this ability for Linux applications anywhere else, at least not in official kernels.

We can execute the kernel in place, thanks to Nicolas Pitre. For userspace I have seen to preparation patches, but nothing serious.

Quoted 2 lines · Jörn Engel

We can execute the kernel in place, thanks to Nicolas Pitre. For userspace I have seen to preparation patches, but nothing serious.

Quoted 1 line

Given that execute in place describes the ability to run code at the very same location where it is permanently stored, and that this is exactly what the patch enables, I think the wording is correct.