XIP ( eng. execute-in-place- execution in place ) är en teknik som ger möjlighet att exekvera programkod direkt från den beständiga lagringsenhet som den finns på, utan att först ladda in i RAM . Det används ofta för initial laddning av datorer, i inbyggda system på grund av behovet av att spara RAM-resurser, i vissa fall används det även för stora system . Sedan 2010-talet, för användning i Linux -serversystem med byteadresserbart icke-flyktigt minne, har det ersatts av en mer allmän teknologi - DAX .
För att tekniken ska fungera måste dess stöd implementeras på tre nivåer: lagring , i operativsystemet och själva de körbara programmen .
För första gången beskrivs uttryckligt stöd för tekniken på lagringsenhetssidan, såväl som dess förkortning och avkodning, i 1990 års PCMCIA- specifikation och är mer inriktade på användning med icke-skrivbara enheter [1] . Till en början associerades tekniken endast med PCMCIA och dess speciella specifikation, som definierade reglerna för att placera en binär kod och ordningen i vilken den lästes och exekveras [2] , men som en sådan teknik implementerades för andra gränssnitt och enheter, den blev starkare för alla lagringsenheter.
För att XIP-läget ska fungera på enheten som programmet finns på måste ett gränssnitt som liknar det som används av den centrala processorn för att komma åt RAM implementeras. Stöd för detta implementeras antingen på mellanprogramsnivå eller med hjälp av filsystemet . Bland de mellanliggande verktygen som tillhandahåller arbete i XIP-läge är MTD -delsystemet ( Memory Technology Device ) , respektive filsystem som arbetar på MTD över blocknivån måste stödja lämpliga anrop för att XIP ska fungera. Samtidigt stöder inte alla filsystem som arbetar genom MTD XIP, eftersom många av dem, ursprungligen fokuserade på bärbar teknik, implementerade komprimering , i detta avseende är implementeringen av XIP i dem icke-trivial, sådana filsystem inkluderar JFFS2 , YAFFS2 , LogFS , UBIFS [3] . Det finns dock XIP-aktiverade komprimeringsfilsystem som arbetar på MTD, såsom AXFS , som framhäver driften av XIP-läge som en definierande funktion ( avancerat XIP-filsystem ) [3] . De stora komprimeringsfilsystemen på blocknivå för beständig lagring, cramfs och squashfs , stöder inte XIP, men det finns en patch för cramfs för att stödja okomprimerad XIP, och de flesta Linux-baserade mobiltelefoner använde denna variant av cramfs [3] .
Bland filsystem för allmänna ändamål som körs ovanpå blocknivån tillhandahålls stöd i Ext2 och Ext3 ; Ext4 började porta XIP-stöd, men 2014 ersattes det av mer allmänna direktåtkomstmetoder - DAX [ [4] .
Trots att tekniken användes i inbyggda system, firmware och ett antal realtidsoperativsystem långt före 2000 -talet [5] , vid sidan av generella operativsystem, implementerades stödet först i Linux-kärnan version 2.6 år 2005 [6] .
2006 stöddes tekniken för IBM zSeries stordatorer , där det fanns ett behov av att köra många olika instanser av z/Linux från en z/VM- miljö med en gemensam kärna och delade bibliotek , men med olika dataregioner [7 ] . Om en liknande funktion för z/OS fanns tidigare, skulle dess direkta implementering för Linux kräva betydande förändringar i operativsystemets kärnkod, så XIP-stödet flyttades till kärngrenen för s390 -arkitekturen och ett antal ytterligare funktioner stöddes, inklusive stöd för på Ext2-sidan [8] . Dessutom tros IBMs behov av att stödja stordatortekniken ha varit drivkraften bakom implementeringen av XIP på Linux [9] .
2010 stöddes tekniken i NetBSD [5] , där implementeringen visade sig vara relativt enkel på grund av funktionerna i det virtuella minneshanteringsundersystemet och buffertcachen, dessutom är den transparent för filsystem (det vill säga den inte kräver särskilt stöd från deras sida).
För att programmet ska fungera i XIP-läge krävs det i kompileringsstadiet att informera om möjligheten att separera områden för datasegment och kodsegment (eftersom datasegmentet måste skapas i RAM, och kodsegmentet måste finnas kvar i filsystemet). GCC använder alternativet -msep-data för detta , och dessutom kräver XIP-program vanligtvis alternativet -mid-shared-library för att generera kod som gör att bibliotek kan anropas av identifierare [10] . Att ställa in något av dessa alternativ gör att -fPIC- flaggan , som står för positionsoberoende kompilering, ställs in.
Huvudsyftet med tekniken är att spara enhetens RAM-minne. Den mest betydande effekten av att spara RAM uppnås när det är nödvändigt att köra flera instanser av programmet, i vilket fall samma utrymme på den skrivskyddade minnesenheten används för att serva alla lanseringar, istället för att allokera ett område i RAM för varje exempel. En annan effekt är att minska enhetens strömförbrukning genom att minska antalet åtkomster till flyktigt RAM [11] .
En annan ofta använd effekt är en snabb uppstart från beständig lagring, i synnerhet för en tillräckligt stor monolitisk Linux-kärna, som på traditionellt sätt måste kopieras initialt till RAM, i XIP kan den exekveras direkt från enheten.
När du använder flash-enheter uppnås den största effekten av XIP med byte-adresserade enheter som NOR flash [5] (medan NAND-flash , liksom hårddiskar , är blockadresserade och åtkomst till en enskild instruktion innebär att man vanligtvis läser 4 KB, kl. minst 512 byte). Detta förklarar också användningen av NOR-blixt för skrivskyddade startminnen och inbyggda system, trots dess högre kostnad och lägre inspelningstäthet (under 2010-talets förhållanden).
En annan effekt är möjligheten att använda beständiga lagringsenheter som delat minne för att köra program utan att använda värdens huvudminnesresurser och separera program- och datasegment, som implementerat i stordatorer .
Under 2014, baserat på XIP-koden i Linux-kärnan (sedan version 3.14), implementerades en mer allmän teknik - DAX ( direktåtkomst ), som kombinerar båda XIP-funktionerna och ger de nödvändiga anropen för direkt dataåtkomst förbi sidcachen [9] . Av filsystemen implementerades tekniken först för Ext4 , senare dök stöd för XFS upp .
Huvudmotivet för en sådan generalisering var uppkomsten i mitten av 2010-talet av rymliga byteadresserbara icke-flyktiga NVDIMM och 3D XPoint- enheter för serversystem, i samband med vilka relevansen av både körande programkod utan att överföras till huvud minne och direkt tillgång till data utan mellanliggande kopiering till RAM. I filsystem fokuserade på sådana enheter, såsom NOVA , PMFS , SCMFS , Aerie [12] , är DAX-stöd implementerat från allra första början och denna funktion anses vara en av deras nyckelfunktioner.