Linux: How to Enable Execute in Place (Xip) for Ramfs/Tmpfs

Is executable code stored uniquely in tmpfs copied to another part of RAM when run?

Your question appears to have been answered in a post on the Linux Kernel Mailing List in 2007

(As tmps is a scheme for storing in the filesystem cache code, with no backing storage, the mentioned buffer cache should I believe be the "original")

Phillip Susi asked:

The question is, when you execute a binary on tmpfs, does its code segment get
mapped directly where it's at in the buffer cache, or does it get copied to
another page for the executing process? At least, assuming this is possible
due to the vma and file offsets of the segment being aligned.

And Hugh Dickens replied

Its pages are mapped directly into the executing process, without copying.

You might want to read the full thread - a note is made that this depends on having a system with an MMU, and then the discussion veers into tmpfs's non-persistence.

Linux's copy-on-write behavior would I believe mean that any data page you write to would get a unique copy created for your process at the time of the first writing.

Initramfs built into custom Linux kernel is not running

I figured it out. I will post the answer in case anyone else has this issue.

I was missing a console device, this line was the clue:

Warning: unable to open an initial console.

After adding printk's so that I better understood the startup sequence, I realized that console device is opened prior to running the init script. Therefore, the console device must be in the initramfs filesystem directly, and we cannot rely on the devtmpfs mount to create that.

I think when the init script ran the shell was trying to open the console and failed, that's why the kernel was outputting:

Kernel panic - not syncing: Attempted to kill init!

Executing the folowing commands from within the /dev directory of initramfs on the kernel build machine will generate the required device nodes:

mknod -m 622 console c 5 1
mknod -m 622 tty0 c 4 0

After re-CPIO archiving the filesystem and rebuilding the kernel, I finally have a working filesystem in initramfs that the kernel will boot.

Linux initramfs switch_root unable to find console which kernel uses

Finally I found the solution (and the mistake I made)!

The console device was created with the wrong major/minor numbers.
Creating it with the same as the kernel assigns to ttymxc* it works:

mknod -m 644 ${ROOT}/dev/${CONSOLE} c 207 17

---

Related Topics