Execute-in-place
Carsten Otte (of IBM) has posted a set of patches adding XIP support to the 2.6 kernel. These patches, in addition, enable fast memory-to-memory block I/O for such devices, shorting out the page cache and most of the block layer. As a result, the XIP patches are useful in a number of situations, such as, as Carsten notes, for shared-memory block devices used to communicate between (virtual) systems.
The first step is to add support at the block driver level. To that end, a new method is added to the block_device_operations structure:
int (*direct_access) (struct inode *inode, sector_t sector, unsigned long *data);
This method, if implemented, should come up with a kernel virtual address corresponding to the given sector on the block device represented by inode. That address, which must remain valid until the device is closed, is returned in *data. The return value is zero on success or a negative error code in case of problems.
The next step is a new method in the address_space_operations structure:
struct page *(*get_xip_page)(struct address_space *space, sector_t blockno, int create);
This method's job is to translate a specific block number within a filesystem to a page structure pointing to its directly-mapped data. It is a filesystem-specific function which will translate blockno to a sector number on the underlying device, then use that device's direct_access() method to get an address. Carsten has posted an implementation for ext2 which shows how this method can be put together.
So far, the XIP patches enable fast, memory-to-memory device access, but they do not yet implement true execute-in-place operation. The last step is to replace the usual nopage() VMA operation (filemap_nopage()) with a new version (filemap_xip_nopage()) when the underlying device and filesystem support XIP. The new nopage() method will (using get_xip_page()) handle page faults by causing a process's page tables to point directly to the on-"disk" pages, rather than reading those pages into RAM. Some other technique will be needed to run the kernel itself in an XIP mode, but anything that is invoked thereafter can be run directly from the memory device.
Put the above pieces together, and Linux has a complete execute-in-place
implementation. Supporting XIP at the block level is not the only way it
could be implemented; David Woodhouse pointed
out that an alternative approach is to use a special-purpose
filesystem. Carsten's patches, however, point out a way in which any
filesystem could be made to work in an XIP mode.
Index entries for this article | |
---|---|
Kernel | Block layer |
Kernel | Execute in place |
Posted May 12, 2005 10:33 UTC (Thu)
by cotte (subscriber, #7812)
[Link] (3 responses)
Posted May 12, 2005 11:06 UTC (Thu)
by cotte (subscriber, #7812)
[Link] (2 responses)
Posted May 12, 2005 13:58 UTC (Thu)
by karim (subscriber, #114)
[Link] (5 responses)
There may be an advantage for XIP in the case of mass-produced masked-ROMs, maybe, but that probably benefits to a handfull of companies on this planet only ...
Posted May 12, 2005 19:19 UTC (Thu)
by oak (guest, #2786)
[Link] (1 responses)
Posted May 13, 2005 6:26 UTC (Fri)
by phiggins (subscriber, #5605)
[Link]
Posted May 15, 2005 19:57 UTC (Sun)
by obobo (guest, #684)
[Link]
Interesting point, though.
Posted May 21, 2005 20:17 UTC (Sat)
by dmag (guest, #17775)
[Link] (1 responses)
Posted Sep 1, 2005 14:46 UTC (Thu)
by jg (guest, #17537)
[Link]
Certainly on the iPAQ we've lived fine without XIP, and flash is more precious that RAM. And the paging system does very well at throwing away unused pages of text that have been pulled into RAM.
So I think we need data here, rather than proof by loud assertion...
>So far, the XIP patches enable fast, memory-to-memory device access,Execute-in-place
>but they do not yet implement true execute-in-place operation.
That is not true. In fact the filemap_xip_nopage function for xip in mm/filemap.c directly maps on-disk content into userspace - that's exactly what execute in place is.
...maybe I should read the article to the end before complaining ;)Execute-in-place
It would be important to highlight that there isn't concensus on the availability/use of XIP within the embedded Linux community. David Woodhouse who maintains the MTD layer, for example, has said a number of times that the only ones who profit from XIP are flash manufacturers. The truth of the matter is that flash costs more than RAM and having XIP means having the binaries uncompressed in flash. The more XIP you have, the larger the flash you need. From that point of view, it's clear that having the classic compressed FS in flash and the apps running in RAM is usually the best way to go. ... not that this fact is going to stop developers from asking for this feature ...Execute-in-place
But doesn't RAM need refresh whereas Flash doesn't? Execute-in-place
I.e. XIP with less RAM might make your battery last longer...
Depends on the type of RAM. XIP would save a lot of power if you use DRAM, but not so much with SRAM and the Magnetic RAM. I think those cost more than flash right now, though.Execute-in-place
It is typical for microcontrollers with on-die flash and RAM to have significantly more flash than RAM. Granted that today, most of these microcontrollers don't have enough memory to run Linux with or without XIP, but bigger chips will come through at some point.Execute-in-place
There is also a latency issue. XIP will boot faster. It will also run faster in the case where you have more flash than RAM.Execute-in-place
I see assertions, with no data, I think often by people with no experience in the area.Execute-in-place
- Jim