Hem / Problem / UNIX-standardisering av operativsystem och posix. Standarder för operativsystem i realtid

UNIX-standardisering av operativsystem och posix. Standarder för operativsystem i realtid

Om standarder i allmänhet

Bland utövare Programmerare är uppfattningen att standarderna i programmeringen inte alls behövs, eftersom

(1) De är ursprungligen meningslösa, eftersom deras författare inte skriver datorprogram;

(2) De kämpar för initiativ av programmerare.

(3) Programmerare kommer alltid att vara överens utan standarder.

Kanske bör denna åsikt inte uppmärksammas om inte två omständigheter:

(1) Hans praxis uttrycker, det vill säga det är de som "utfärdar programvaror";

(2) Ovannämnda argument upptäcktes av författaren till denna artikel i en av publikationerna på Internet på standarden för programmeringsspråket i C, vilket det blev klart att en sådan åsikt spriddes "på internationell nivå", och inte bara bland arrogant ryska "superfrogramister".

Ordet "standard" är vanligtvis förknippat med något material (standarddimensioner, standard elspänning etc.), medan datorprogrammet är ett immateriellt objekt ("det nya immateriella"), och kanske normerna i den immateriella sfären är verkligen meningslösa?

Det finns emellertid ett revisionsexempel. Kombinationen av reglerna för stavningen av det ryska språket är i huvudsak en standard, men inte godkänd av standardiseringsmyndigheterna. Vidare, med undantag för reglerna (eller om du, kraven) av stavning, finns det syntaktiska regler och, viktigast av allt, semantik. Den senare illustrerar "Barnens" fråga: Varför ringer katten en katt? Det finns ett korrekt svar på den här frågan: Eftersom våra förfäder kom överens om det. Briternas förfäder kom överens om att ringa samma djurkatt, tyskarna - kattungeens förfäder, etc. I allmänhet, meningen eller semantiken eller reglerna för tolkningen av något ord eller en kombination av ord - frågan om överenskommelse.

Utnämning och "Superbate" av standardposixen

Som följer av namnet, POSIX (bärbar Operativ system. Gränssnittet) är en standard för parning (gränssnitt) mellan operativsystemet och applikationsprogrammet. Tider när programmerare skrev program för den "nakna" -maskinen (implementering av sina egna paket med I / O-program, trigonometriska funktioner etc.), passerade oåterkalleligt. Texten POSIX betonar upprepade gånger att standarden inte lägger fram några krav på operativsystemets verksamhet. Det kan betraktas som en helhet av avtal mellan applikationsprogrammerare och utvecklare operativsystem. Således (igen, i motsats till en ganska populär åsikt), är POSIX av intresse inte bara för utvecklare av operativsystem, utan först och främst, för en mycket mer många former av programmerare - tillämpad.

Behovet av standarden av detta slag realiserades på 1980-talet, när UNIX-operativsystemen var utbredd. Det visade sig att även om detta system var tänkt som en förenad, ledde skillnaderna mellan dess specifika implementering till det faktum att de ansökningsprogram som skrivits för ett system inte alltid kunde utföras i en annan. Om beslutet av det här problemet, känt som problemet med rörlighet programvara, Posix riktad. Den första utgåvan av standarden släpptes 1988 (det finns en översättning, se), där alla olika frågor som rör programmobiliteten var uppdelad i två delar: (1) Programgränssnitt, (2) Kommandotolk och verktyg (Användargränssnitt); Dessa delar kallades posix.1 och posix.2, respektive1.

Vi kommer att ange att den här artikeln endast kommer att prata om standarden för applikationsgränssnittet, POSIX.1, vars andra (och sista hittills) godkändes den 12 juli 1996.

Den informativa delen av standarden betonar också att posix inte är en beskrivning av gränssnittet för något "idealiskt" operativsystem, men resultatet av generalisering och systematisering av erfarenheter som uppnåtts i utvecklingen av UNIX-operativsystem. Dessutom kan POSIX inte fungera som en guide- eller träningshandbok för operativsystem, även om den informativa delen innehåller rekommendationer till programmerare och fragment av program.

Standarden hänvisar till det faktum att det är omöjligt att skapa ett fullfjädrat operativsystem, med inriktning uteslutande på gränssnittsfunktionerna som beskrivs i den. (I synnerhet är POSIX.1 inte att återspegla sådana problem som nätverks- och relaterade gränssnittsfunktioner eller ett grafiskt gränssnitt.) De finansiella kostnaderna som orsakas av programmets nongeterbarhet och behovet av gränssnittet är dock så stor att de flesta tillverkare föredrar Har åtminstone någon standard än ingen. Av denna anledning försöker mycket många mjukvaruutvecklare att navigera på POSIX. Detta gör det möjligt om du inte eliminerar programens nonumininitet helt, då minskt avsevärt minskat den nongetrabla delen av programmet.

Om semantik

Som redan nämnts kan POSIX betraktas som en uppsättning avtal mellan operativsystemet och applikationsprogrammeraren. "Avtal" betyder först av all provning av tolkning (semantik) av ord och uttryck. Följande är exempel som illustrerar svårigheten att uppnå ett avtal.

Hur man förmedlar mening när man översätter

Först och främst måste du komma ihåg att POSIX-standarden anges på engelska, vilket i naturen provocerar tvetydighet (till exempel kan samma ord vara substantiv, adjektiv och verb), och "semantiska fällor" lyssnade nästan på varje sida. En bra illustration av nämnda är ett exempel på fiktion. En av de mest kända verk av Oscar Wilde, som briljant använde den här funktionen på det engelska språket, - vikten av att vara allvarlig - är känd på ryska kallade "hur viktigt att vara allvarlig". Men det engelska namnet har en andra betydelse: allvarlig (allvarlig) - efternamnet för en av karaktärerna, och namnet kan översättas annorlunda: "Hur viktigt är Ernst". Det finns ett ryskt efternamnet silver, och om det var ett allvarligt efternamn, skulle översättningen vara perfekt exakt, med överföringen av båda betydelserna.

Detsamma är fallet med namnet på standard: bärbart operativsystemgränssnitt. Den adjektiv bärbara (mobilen) avser operativsystemet och till applikationsprogrammet, men det är inte möjligt att uttrycka det inom ryska, du kan översätta som ett "mobil operativsystemgränssnitt" eller "operativsystemgränssnitt som ger rörlighet för ansökningsprogram. " Det andra alternativet återspeglar bättre standardutvecklarens avsikter, men samtidigt förlorades den första tvätten (det mer kända första alternativet var bevarat).

Semantik av ordet "Standard"

Huvudtexten i standarden är preammed av ingressen, där betydelsen av ordet IEEE-standarder2 förklaras. Som följer av dessa förtydliganden finns det minst tre semantiska skillnader från den rysktalande termen GOST:

(1) Intuitivt anser att GOST har kraften i den lag vars överträdelse förföljs POSIX är en uppsättning krav, varefter är fallet exklusivt frivilligt.

(2) GOST fungerar upp till avbokning (många, förmodligen, var tvungna att höra uttrycket "GOST ingen avbröt"); I ingressen till POSIX sägs det att om standarden inte reviderades i 5 år betyder det att frågor som övervägs troligtvis förlorat relevansen, och det kan anses vara avbeställt automatiskt.

(3) Gost anonomen; I den inledande delen av POSIX ges en lista över de personer som deltog i utvecklingen av denna standard, och ger också den adress där du kan skicka tolkningsförfrågningar. Det sägs också att svaret på varje begäran är föremål för samordningsförfarandet (med andra ord, författarna till standarden är överens med varandra innan de ger svaret).

Således kräver översättningen av även ett så känt ord som standardord "standard" kommentarer.

Ordens semantik "måste", "inte specificeras", "inte definierad", "bestämd av genomförandet"

Avsnitt 2 i standarden kallas "terminologi och allmänna krav". Den innehåller definitionerna av inte bara speciella termer (t.ex. "process" eller "semafor"), men också sådana, det verkar som om de självklara ord, som "måste" eller "maj". Eftersom POSIX.1 är en standard på gränssnittet är dess krav relaterade till både operativsystemet och applikationsprogrammet. Explicit krav uttrycks av ordet "måste" (ska till exempel: "Vid framgångsrik slutförande måste funktionen länk () returnera nollvärdet." I det här exemplet talar vi om kravet på operativsystemet: Funktionen Link () måste genomföras så att nollvärdet vid en lyckad slutförd är.

Villkoren "Ej specificerade" och "Ej definierade" uttrycker samma idé att standarden medger valfrihet, men betydelsen av dessa termer är varierad. Termen "Ej specificerad" innebär att vi pratar om några korrekta (handlingar, programstrukturer etc.) och termen "ej definierad" - om felaktig (felaktig). Den informativa delen av standarden ger följande förklaring.

Uttrycket "ej specificerat" betyder att många alternativ (resultat, resultaten av funktionsamtalet etc.) antas vara känt, och standarden tillåter någon av dem; I ett specifikt genomförande av operativsystemet kan vem som helst väljas, och ett sådant system anses vara den relevanta standarden. Tillämpningsprogram (strängt relevant standard) måste skrivas på ett sådant sätt att det fungerade korrekt i någon variant. I huvudsak uttryckte denna term implicit ett krav på ett applikationsprogram.

Låt oss ge ett exempel: "ReadDir () -funktionen måste returnera en pekare till strukturen som hänför sig till nästa katalogelement. Huruvida objekten i katalogen returneras med "dot" och "Point-Point" -namnen är standarden inte specificerad. " I det här exemplet är fyra resultat möjligt, och kravet på ett applikationsprogram är att det måste utformas för någon av dem.

Ett annat exempel: "Om funktionen Sigwait (), som föreskriver väntar på signalen med det angivna numret, orsakas i flera styrströmmar, då när signalen är mottagen, bör inte mer än en av dem återvända från Sigwait (). I vilken typ av kontrollflöde kommer det att hända, är standarden inte specificerad. " I det här exemplet kan många möjliga resultat vara mer, men de är också kända, och kravet på ett applikationsprogram är att det ska fungera korrekt vid något resultat.

Uttrycket "ej definierad" innebär att även många resultat är inte kända, vilket utfall är möjligt, även beklagligt (till exempel kollaps av systemet, dataförlust etc.). I huvudsak uttryckte denna term implicit kravet på att ansökningsprogrammet inte kunde använda lämpliga uppgifter eller konstruktioner. Till exempel: "Om Dirp Argument-funktionen ReadDir () inte hänvisar till den aktuella öppna katalogen, är resultatet inte definierat."

Detta exempel innehåller en begäran att appliceras som ett argument-readdir () -funktion endast länk till en öppen katalog. Överträdelse av detta krav kan leda till katastrofala konsekvenser, och ansvar för det tilldelas en applikationsprogrammerare.

Här är ett annat exempel: "Vid framgångsrik slutförande måste funktionen läsa () returnera ett heltal som anger antalet praktiskt taget läsa byte. Annars måste funktionen tilldela en felkod till errno och retur -1, och innehållet i bufferten som BUF-argumentet specificeras är inte definierat. "

Använd i ett applikationsprogram från en buffert vid ett fel i läsfelet (), förbjuder standarden, och konsekvenserna av överträdelsen av detta krav ställer in ansökningsprogrammeraren.

Betydelsen av termen "bestäms av genomförandet" skiljer sig från intuitivt. Självklart, i ett specifikt operativsystem, kan det inte finnas något "icke-råd" eller "osäker" resultat, kommer ett visst resultat att erhållas. Termen "bestämd genom genomförandet" uttrycker kravet på standarden till dokumentationen för operativsystemet: resultatet inte bara bör klargöras (utvecklaren av operativsystemet måste ändå), men också uttryckligen återspeglar dokumentationen för systemet.

Semantics standard

Inget regleringsdokument kan täcka hela det olika fall som kan mötas i praktiken, så det är oundvikligt om något tyst3. Till exempel, i beskrivningen av funktionen kan det sägas att dess argument kan ta värden från ett visst område, men ingenting säger att det kommer att bli resultatet om argumentet inte faller i detta sortiment. Självklart, för att undvika missförstånd, är det nödvändigt att ha en enda standard semantik. I den informativa delen av standarden finns det en nyfiken fras: "Den allmänt accepterade semantiken för standard är förbjuden." Detta uttalande strider mot den välkända slogan för ett decennium sedan "Allt som är klart inte förbjudet är tillåtet. Tydligen var han så rotad i medvetenheten om medborgare att många, till och med programmerare, inte håller med det anställda uttalandet av standarden. Under tiden, om användningen av någon design helt klart inte är tillåten och inte följer av beskrivningen, inser någon utövare programmerare att dess användning är riskabel, och om den inte fungerar, uppstår det inte på ett krav.

Processer och kontrollflöden

Båda dessa termer uttrycker tanken på implementeringen. UNIX-operativsystemet var ursprungligen tänkt som ett multiplayer, och program som lanseras av olika användare måste vara ordentligt isolerade från varandra för att oavsiktligt förvränga "andra" data. Denna isolering tillhandahålls av det faktum att användarprogrammet exekveras inom en viss process som utvecklas i sitt eget virtuella adressutrymme. Även om programmet har globala data, när det startar det i olika processer, kommer de automatiskt att skiljas "av olika adressutrymmen.

Emellertid är processernas mekanism inte helt tillfredsställande vid programmering av realtidsuppgifter. Realtidsprogrammet (agerar på uppdrag av samma användare) kan ofta vara naturligt representerade så parallellt med de körbara delarna, som kallas "kontrollflöden" (tråd). Den viktigaste skillnaden från processer är att alla kontrollflöden utvecklas i ett enda adressutrymme; Detta säkerställer snabb tillgång till globala data, men samtidigt är risken för oavsiktlig snedvridning av deras förvrängning och att detta inte uppstår, det är nödvändigt att följa en viss disciplinprogrammering. De relevanta rekommendationerna finns i den informativa delen av standarden.

Det bör betonas att tanken på multithreading implementeras i många realtidssystem, och implementeras annorlunda i den meningen att olika uppsättningar av attribut och gränssnittsfunktioner motsvarar varje styrström; Ibland använder istället för termen "kontrollflöde" (tråd) termen "uppgift" (uppgift). För att undvika missförstånd betonar standarden att den kommer uteslutande om POSIX-styrströmmar, och namnen på motsvarande gränssnittsfunktioner har Pthread_ prefixet (till exempel pthread_create (), pthread_join (), etc.).

Överensstämmelse med standard. Ordets semantik "motsvarar"

Det är intuitivt att om två ämnen är gjorda i enlighet med samma standard, är de garanterade att "matcha" med varandra och kommer att arbeta tillsammans i ett par; Det är i detta att syftet med införandet av standarden för konjugationen (gränssnittet) är. Eftersom POSIX är en standard på gränssnittet kan du prata om överensstämmelse med standarden på både operativsystemet och applikationsprogram.

POSIX.1 Standard innehåller flera hundra (om inte tusentals) krav; Det anses vara självklart att om minst en av dem inte är uppfylld, uppfyller systemet (eller applikationsprogrammet) inte standarden. Samtidigt skrivs ett sådant antal UNIX-operativsystem och applikationsprogram för dem hittills, vilket är osannolikt att det är rimligen att kräva fullständig korrespondens i den angivna bemärkelsen. Svårigheterna att utveckla en internationell standard av detta slag förvärras av förekomsten av olika nationella språk. Även om du glömmer applikationsprogram som är utformade för att behandla texter på nationella språk, måste nästan alla applikationer utfärda vissa diagnostiska meddelanden och / eller uppfatta de texter som operatören har angett.

strikt överensstämmelse med posix.1-standarden;
överensstämmelse med den internationella versionen av posix.1;
Överensstämmelse med den nationella versionen POSIX.1;
compliance Posix.1 med tillägg.

För det andra förklaras många gränssnittsfonder valfria (valfritt). Standarden kräver att de valfria gränssnittsfunktionerna antingen utarbetas som ordinerat av standarden, eller har alltid returnerat en speciell felkod, Enosys (vilket betyder att funktionen inte är implementerad). Valfria medel är uppdelade i flera grupper, vilka var och en motsvarar en viss konfigurationskonstant, som deklareras (#definesoperatör) i motsvarande huvudfil; Detta säkerställer möjligheten att ta reda på huruvida funktionen är implementerad på kompileringsfasen.

Den beskrivna upptagningen av rörlighet uppfanns inte av författarna till POSIX och för länge sedan tillämpad i praktiken; I många operativsystem tillämpas konfigurationskonstanter för att identifiera själva systemet eller dess version. Och här erbjuder standarden inte något fundamentalt nytt, men systematiserar bara den befintliga praxisen.

Standardiseringsobjekt och standardstruktur

För att tala kort, är föremålen för standardisering posix.1 namn och semantik. Mer specifikt talar vi om följande.

Gränssnittsfunktioner. 357 Funktioner är standardiserade, och 107 funktioner tas från standard Si-bibliotek (matematisk, radbehandling, ingång / utgång, etc.); Dessa funktioner anses vara en del av POSIX.1-standarden, men deras fullständiga beskrivning finns i standardprogrammeringsspråket.
Namn på systemdatatyper. Dessa namn har ett suffix _t.
Namnen på rubrikfilerna, liksom minsta sammansättning av dessa filer.
Namn på systemövergripande globala variabler (till exempel errno).
Symboliska namn för felkoder som kan installeras när du tränar funktioner. Dessa namn börjar med bokstaven E (eperm, enotempty, etc.).
Konstanta konfigurationsnamn. Dessa namn har prefix _posix_.
Symboliska namn på signaler; Dessa namn har ett SIG-prefix. Förutom 20 "traditionella" signaler (SIGABRT, SIGALRM, etc.) är realtidssignaler standardiserade, vars antal bör uppta ett fasta intervall från Sigrtmin till Sigrtmax-inkluderande, innehållande inte mindre RTSIG_MAX-nummer.
Symboliska namn som motsvarar värdena för enskilda argument av vissa funktioner (till exempel CMD-argumentfunktionen FCNTL () kan ta F_DUPFD, F_GETFD, F_GETLK-värden etc.).
Namn på makron, konstanter, bitflaggor, miljövariabler.

I allmänhet består standarden av två stora delar av ungefär samma volym. Den första halvan är den lagstiftande delen - innehåller kraven och rekommendationerna från standarden (18 avsnitt), den andra informativa delen - innehåller ansökningar som tillhandahåller en lista över referenser, kommentarer och förklaringar till regelverket, samarbetet av rubrikfilerna , ett exempel på en profil ("projicering") av standarden (för Danmark), egenskaper och metoder för att mäta prestanda för de viktigaste funktionerna, liksom en beskrivning av ytterligare gränssnittsfunktioner för att fungera med realtidsfiler. Det förväntas att i följande utgåvor av standarden kommer dessa funktioner att ingå i regelverket.

Tanken med vilka typer av tjänster i operativsystemet omfattas av standarden, ger summan av "sammanfattningen av standardavsnittet".

Slutsats

Den huvudsakliga innehållet i POSIX-standarden är semantiken för gränssnittsfunktioner. Standardisering av semantik - I själva verket är det inte lätt (alla vet hur svårt det är att komma överens om två personer), och svårigheter förvärras av många människor är för närvarande inblandade i programmeringsaktiviteter. Till exempel uttrycks parallell exekveringsparadigm av sådana termer som "process", "uppgiften" och "hanteringsflöde", men från synvinkel av praktisk programmering "uppgift" i operativsystemet IBM OS / 360 och i Realtids operativsystem VXWorks är inte ett och också. Ett annat exempel är semapores. Semaforer är binära, heltal ("med en mätare") och ett ömsesidigt undantag (som förresten, programmerare kallas "mutexes", som sökte på att undvika missförstånd). Och heltalssemaphores, till exempel i VXWorks operativsystem, är inte alls samma som posix semaperna.

Författarna till POSIX-standarden, perfekt inser hur svårt det är att få människor att överge sina vanor (som de kallar den "etablerade praxis"), förklara att de gjorde ett logiskt anslutet och minimalt system för gränssnittsfunktioner som täcker de flesta av de tjänster som traditionellt tillhandahålls Av operativsystemet beskriver i detalj den exakta semantiken för dessa funktioner och erbjuda alla att använda dem i sin utveckling4.

När du läser standarden uppstår intrycket att vissa formuleringar hade ett enda mål: att inte dra tillbaka några applikationsprogram eller operativsystem från kategorin. Ett sådant mål var faktiskt set och tydligt formulerat i introduktionen: standarden bör ta hänsyn till den nuvarande praxisen för att maximera omfattningen. Det främsta målet är dock att säkerställa rörligheten i ansökningsprogrammen.

Om äkta

Sergey Romanyuk - seniorforskare av forskningsinstitutet för systemforskning, chef för POSIX Standard Translations Group. Du kan kontakta honom e-post av adressen: [E-post skyddad]

1 Det bör läggas till att arbetet med standarden fortsätter i många år. Nya frågor identifieras, och de ingår antingen i en av de befintliga delarna, eller görs i form av en separat del, som senare kan avbrytas. Detta hände till exempel med gränssnittsmedlet av realtid, som först tillkännages som posix.4 och därefter inkluderade i POSIX.1.

2 IEEE är en organisation där POSIX-standarden har utvecklats.

3 Här betyder "Mistor" tyst, inte standard; Det handlar inte om några underförstådda värden som faktiskt förklaras, men om valdeklarationen alls.

4 Översättningen av standarden till ryska kommer att publiceras i början av 2000.

Litteratur

Internationell standard ISO / IEC 9945-1 (ANSI / IEEE STD 1003.1) andra upplagan. 1996-07-12. Informationsteknik - Bärbart operativsystemgränssnitt (POSIX) - Del 1: Systemprogramgränssnitt (API).

M.i. Belyakov, Yu.i. Wereruve, A.l.fridman. Mobilt operativsystem. Katalog. Moskva, radio och kommunikation, 1991.

ISO / IEC 9899: 1990, programmeringsspråk - C.

Sektion 1	- Inledning
Sektion 2.	- Terminologi och definitioner
Avsnitt 3.	- Processhanteringsfunktioner (skapa, byta ut bilder, slutförda) och signaler (maskhantering, signalrespons)
Avsnitt 4.	- Identifiering (processer, användare, system, terminal), en undersökning av tider som spenderas på processen, undersökningen av miljövariabel.
Avsnitt 5.	- Hantera filer och kataloger
Avsnitt 6.	- Inmatnings- och utmatningsfunktioner
Avsnitt 7.	- Terminalhanteringsfunktioner
Avsnitt 8.	- Funktioner som lånas från standarden
Avsnitt 9.	- Tillgång till användardatabaser och användargrupper
Avsnitt 10.	- Dataformat för arkivering och utbyte (TAR och CPIO)
Avsnitt 11.	- Synkroniseringsverktyg: Semaphores, mutexes och variabla förhållanden
Avsnitt 12.	- Minneshanteringsfunktioner: Fixerings- och oenighetsprocessadressutrymme, visar minnesfiler, minnesskydd, delat minne
Avsnitt 13.	- Funktioner relaterade till planeringsprocesser och kontrollflöden
Avsnitt 14.	- Hantera klockor och timers
Avsnitt 15.	- Report Queues Management
Avsnitt 16.	- Grundläggande funktioner relaterade till kontrollflöden
Avsnitt 17.	- Individuell styrströmdata (trådspecifik data)
Avsnitt 18.	- Medel för att förstöra kontrollflödena

Normer

Sergey Zolotarev,

Syftet med denna artikel är att försöka göra en viss klarhet i POSIX-standardernas utvecklingshistoria i förhållande till operativsystem i realtid (OS RV).

Som en introduktion: Varför behöver du en programmeringsgränssnittsstandardisering?

En av de viktigaste egenskaperna hos POSIX-standarden är att den definierar ett "standardiserat programmeringsgränssnitt", som utvecklarna av komplexa mjukvaru- och hårdvarusystem ska hålla sig till utvecklarna. Skaparna av dessa system är tvungna att möta sådana krav som en kort stund att komma in på marknaden (på grund av styv konkurrens), minimera kostnader och accelererande avkastningar. Samtidigt är lejonens andel av kostnader som orsakas av avmattningen i utvecklingsprocessen relaterad till det faktum att programmerare måste "uppfinna en cykel", om och om igen genomföra funktionalitet, som länge varit tillgänglig. Men det kan undvikas av:

Återanvänd kod från tidigare och parallella projekt;

Överföring av kod från andra operativsystem;

Att locka utvecklare från andra projekt (inklusive användning av andra operativsystem).

Allt detta är möjligt på grund av användningen av operativsystemet med en standardiserad API. Dessutom, om i det första fallet organisationen är tillräcklig för att ha en viss intern standard (som är särskilt karakteristisk för märkesvaror), kräver det andra två fallen bara tillgången på allmänt accepterade standarder - till exempel POSIX.

Med hjälp av ett POSIX-kompatibelt OS-projekt som en plattform får utvecklaren möjlighet att överföra färdig kod På nivån på källtexten, både från sina tidigare eller parallella projekt och från projekt av tredje företag. Detta minskar inte bara tidpunkten för mjukvaruutveckling, men förbättrar också sin kvalitet, eftersom den beprövade koden alltid innehåller mindre fel.

Vem är vem i utvecklingen av posix

Och låt oss börja med den mycket vanliga posixen, men för att beställa rollen som organisationer som är inblandade i att arbeta på den.

Den första deltagaren är IEEE. Institutet för elektriska och elektronikingenjörer, institut för elektriker ingenjörer och elektronik), offentliga ideella organisationer. IEEE leder sin historia sedan 1884 (formellt - sedan 1963), kombinerar 380 000 enskilda medlemmar från 150 länder, publicerar den tredje delen av den tekniska litteraturen om användningen av datorer, hantering, elektrisk och informationsteknik samt mer än 100 tidskrifter, Populär i miljön av proffs; Dessutom är föreningen per år över 300 stora konferenser. IEEE deltog i utvecklingen av mer än 900 befintliga standarder (www.ieee.ru/ieeee.htm). Idag är detta institut engagerat med att förbereda, godkännande, godkännande, förlag, men i sin formella status har inte befogenhet att acceptera sådana handlingar som internationella eller nationella standarder. Därför betyder termen "standard" i förståelsen av IEEe ganska "specifikation", vilket mer motsvarar statusen för de handlingar som tagits av föreningen. I enlighet med IEEE deltar i programmen för ett antal internationella och regionala organisationer - IEC, ISO, ITU (European Telecommunications Standards Institute for ElectRotechnical Standartization) och i nationella program, såsom programmet för en sådan organisation som ANSI.

IEEE omfattar PASK (Portable Application Standards Committee, www.pasc.org/) - Föreningsskommittén, som utvecklar en posixfamilj. Tidigare var PASCC känt som tekniska kommittén för verksamhet.

Den andra arbetsdeltagaren - ANSI (American National Standards Institute, American National Standards Institute; www.ansi.org) - En privat ideell organisation som administrerar och koordinerar i Förenta staterna om standardiseringsfrågor. Det sysselsätter endast 75 personer, men medlemmarna i ANSI är mer än 1000 företag, organisationer, myndigheter och institutioner. ANSI representerar Förenta staterna i två huvudsakliga internationella organisationer för standardisering - ISO och IEC.

Tredje deltagare - Iso. Internationell organisation för standardisering, internationell organisation vid standardisering, www.iso.org). Det skapades 1946 genom beslut att samordna standarder och FN: s generalförsamling och officiellt började arbeta den 23 februari 1947. ISO är ett nätverk av nationella standardiseringsinstitut från 146 länder (ett land - en ISO-medlem) med det centrala sekretariatet i Genève (Schweiz). ISO-standarder är utvecklade i tekniska kommittéer, vars första resultat är ett utkast till internationellt standarddokument (DIS), som vänder sig efter flera matchande i slutliga utkast till internationell standard (FDI). Därefter görs frågan om godkännande av detta dokument till en omröstning. Med ett positivt resultat blir det en internationell standard.

Till sist, - IEC. Internationell elektroteknisk kommission, den internationella elektrotekniska kommissionen - IEC; www.iec.ch/), grundad 1906, förbereder IEC och publicerar internationella standarder för all elektronisk, elektronisk och relaterad teknik. Från och med den 1 november 2004 var de nationella kommittéerna i 64 länder de giltiga medlemmarna i denna kommission. IEC publicerar också rekommendationer som kommer ut på engelska och franska och utföra statusen för internationella standarder. De är baserade på regionala och nationella standarder. Tekniska kommittéer (TC) ansvarar för utarbetandet av standarder på olika områden av IEC-verksamhet, och nationella kommittéer som är intresserade av en TC: s verksamhet är också inblandade.

IEC. - Key Organization vid utarbetandet av internationella standarder för informationsteknik. Detta område har en gemensam teknisk kommitté för informationsteknik - JTC 1 som bildades 1987 i enlighet med avtalet mellan IEC och ISO. JTC1 har 17 underkommittéer som övervakar all utveckling - från programvara för att programmera språk, datorgrafik och redigering av bilder, sammankoppling av utrustning och säkerhetsmetoder.

Förberedelse av nya IEC-standarder omfattar flera steg (preliminärt, leveransstadium, förberedande, stadium av den tekniska kommittén, förfrågan, godkännande, offentliggörande). Om det är planerat att IEC-dokumentet bara kommer att vara en teknisk specifikation, och inte en internationell standard, skickas den reviderade versionen av dokumentet till centrala kontoret för offentliggörande. För utvecklingen av det slutliga projektet av den internationella standarden (FDI) ges fyra månader. Om alla medlemmar i den tekniska kommittén godkänns går det till centralkontoret för publicering utan FDI-godkännandestadiet. Därefter faller FDI i nationella kommittéer för att godkänna det inom två månader. FDI anses vara godkänd om mer än två tredjedelar av de nationella kommittéerna röstade för honom, och antalet negativa röster överstiger inte 25%. Om dokumentet inte är godkänt, skickas det för att revidera tekniska kommittéer och underkommittéer. Standarden måste publiceras senast två månader efter godkännande av FDI.

Några fler organisationer är relaterade till utveckling och antagande av POSIX-standarder.

Öppen grupp. - Internationell organisation för programvarusstandardisering, som kombinerar nästan 200 tillverkare och användargrupper som arbetar inom informationsteknik (www.opengroup.org/) .Opengroup skapades 1995 genom att slå samman de två föregångarna: X / Open och Open Software Foundation ( OSF). Open Group är specialiserat på utveckling av programvarucertifieringsmetoder och testning för överensstämmelse med vissa krav. I synnerhet är Open Group certifierad för områden som COE-plattform, Corba, LDAP, Linux-standardbas, skolans driftskompatibilitet (SIF), S / Mime Gateway, Single UNIX-specifikation, trådlös appl(WAP) och slutligen familj av posix standarder (www.opengroup.org/certification/).

AustinCommonStardSrevisionGroup (CSRG) - Den unga tekniska arbetsgruppen som bildades 2002 ISO, IEC och Open Group för att skapa och behålla de senaste versionerna av standarden 1003.1, som kommer att bildas baserat på ISO / IEC 9945-1-1996, ISE / IEC 9945-2-1993 , IEEE STD 1003.1-1996, IEEE STD 1003.2-1992 och enstaka UNIX-specifikation (www.opengroup.org/press/14nov02.htm).

National Institute of Standards and Technology (NIST) - Federal byrå följde Commerce Departments teknikadministration (www.nist.gov/public_affarna/general2.htm), grundad i USA 1901. NIST: s uppgift är utveckling och propaganda av standarder och teknik för att förbättra produktkvaliteten. NIST inkluderar informationsteknologi laboratorium. Informationsteknik Laboratory - ITL)Ett av resultaten är federala i(federala i- fips, www.opengroup.org/testing/fips/general_info.html).nist/itl erbjuds 1991 den första uppsättningen test för POSIX-certifiering 1991 Inom FIPS PUB 151-1 1990.

Vad är posix?

Formellt term Posix. föreslagna av Richard Stallman (Richard Stallman) som en förkortning för P.ortable. O.omvandling S.ystem gränssnitt för un Ix (Bärbart gränssnitt för operativsystem för UNIX). POSIX utvecklades för Unix-liknande operativsystem (deras första versioner räknas från början av 1970-talet) för att säkerställa portabiliteten hos applikationer på källkodsnivå.

Den ursprungliga beskrivningen av gränssnittet publicerades 1986, då kallades IEEE-IX (IEEE: s version av UNIX). Namnet ändrades dock snabbt och vände sig till POSIX, och redan i nästa publikation (tillbaka 1986) användes denna nya version. För en tid under POSIX förstod referensen (eller synonym) som en grupp IEEE 1003.1-1988-relaterade dokument och en del av ISO / IEC 9945, och som en fullständig och godkänd internationell ISO / IEC-standard 9945.1: 1990 antogs POSIX i 1990. POSIX-specifikationer definierar standard mekanismen för interaktion mellan applikationsprogrammet och OS och innehåller för närvarande mer än 30 standarder under ledning av IEEE, ISO, IEC och ANSI.

Under sin historia har POSIX passerat ett stort sätt, medan många gånger förändrade beteckningarna för specifikationer, deras specifika innehåll, förfaranden och logistik för deras verifiering. Under den senaste tiden utfärdades flera utgåvor av POSIX-standarden i olika internationella organisationer.

POSIX Standard Development History

Den första versionen av IEEE STD 1003.1-specifikationen publicerades 1988. Därefter antogs många utgåvor av IEEE STD 1003.1 som internationella standarder. POSIX Development Stages:

- 1990 Redaktionskontoret som släpptes 1988 omdesignades och blev grunden för ytterligare utgåvor och tillägg. Den godkändes som en internationell standard ISO / IEC 9945-1: 1990.

- 1993 Redaktionskontoret på 1003,1B-1993 kommer.

- 1996 IEEE STD 1003.1B-1993, IEEE STD 1003.1c-1995 och 1003.1i-1995 gjordes, men huvuddelen av dokumentet var oförändrad. År 1996 godkändes även utgåvan av IEEE STD 1003.1 som en internationell standard ISO / IEC 9945-1: 1996.

- 1998 Det finns en första standard för "Real-Time" - IEEE STD 1003.13-1998. Detta är expansionen av POSIX-standarden för inbäddade realtidsansökningar.

- 1999 Det beslutades att göra betydande förändringar i huvudtexten i standarden under de senaste 10 åren, inklusive förening med standarden 1003.2 (Shell and Utilities), eftersom dessa i det ögonblicket var separata standarder. PSC bestämde sig för att slutföra byte av grundtexten efter avslutad standarder för IEEE 1003.1a, 1003,1d, 1003,1 g, 1003,1j, 1003,1Q och 1003.2b.

- 2004 Senast idag publicerades redaktionen på 1003,1 den 30 april och släpptes under Austin Common Standards Revisionsgrupp. Det gjorde ändringar avseende redaktionskommittén 2001. Formellt är redaktionskontoret 2004 känt som IEEE STD 1003.1, 2004-utgåvan, den öppna gruppens tekniska standardbasspecifikationer, utgåva 6 och innehåller IEEE STD 1003.1-2001, IEEE STD 1003.1-2001 / Cor 1-2002 och IEEE STD 1003.1-2001 / COR 2-2004.

De viktigaste standarderna för POSIX för RV OS

För realtidsoperativsystem är sju standardspecifikationer viktigast, men endast tre stöddes i stor utsträckning i det kommersiella OS:

1003.1a (OS-definition) Definierar OS: s grundläggande gränssnitt, jobbhantering, signaler, funktioner filsystem och arbeta med enheter, användargrupper, transportörer, FIFO buffertar;

1003.1b (Realtime Extensions) beskriver realtidsförlängningar, såsom realtidssignalering, prioriterad sändning, timers, synkron och asynkron ingång, semaforer, delat minne, meddelanden. Ursprungligen (fram till 1993) indikerades denna standard som posix.4;

1003.1c (trådar) Definierar strömstödfunktioner (trådar) - Flödesreglering, strömattribut, mutex, sändning. Ursprungligen betecknad som posix.4a.

Utöver dessa standarder är följande standarder viktiga för RV, som genomfördes som en del av STD-projektet 1003.1-2001:

IEEE 1003.1D-1999. Ytterligare expansioner av realtid. Ursprungligen betecknad som posix.4b;

IEEE 1003,1J-2000. Förbättrad (avancerad) realtids expansion;

IEEE 1003.1Q-2000. Spårning.

Certifieringsförfarande

För att uppfylla POSIX-standarden måste operativsystemet vara certifierat enligt resultaten av motsvarande testuppsättning. Sedan utseendet på POSIX har testuppsättningen genomgått formella och faktiska förändringar.

År 1991 har NIST utvecklat ett POSIX-testprogram inom FIPS 151-1 (http://standards.ieee.org/regauth/posix/posix-a.fm5.pdf). Detta testalternativ var baserat på IEEE 1003.3 "standard för testmetoder för att mäta överensstämmelse med POSIX" utkast 10, maj 3, 1989. År 1993 har NIl examen från testprogrammet för FIPS 151-1 och började ett program för FIPS 151 -2 (www.itl.nist.gov/fipspubs/fip151-2.htm ).fips 151-2 Anpassad "Informationsteknik - Bärbart operativsystemgränssnitt (POSIX) - Del 1: Systemprogramgränssnitt (API)," ISO / IEC 9945-1: 1990-standarden. Testuppsättningar för FIPS 151-2 var baserade på IEEE 2003.1-1992 "standard för testmetoder för mätning av överensstämmelse med posix".

NIST skiljer två certifieringsmetoder: självcertifiering (självcertifiering) och certifiering ackrediterad i IEEE-testlaboratorier (Accredited Posix Testing Laboratories - APTL). I det första fallet driver företaget självständigt, men enligt planen godkänd i NIST. I det andra fallet utförs testning av ett oberoende laboratorium med automatiserade testuppsättningar. Två APTL-laboratorier var ackrediterade: Mindcraft (www.mindcraft.com) och fleråriga (www.peren.com).

År 1997 tillkännagav NIST / ITL sin avsikt att säga upp certifieringen för FIPS 151-2 i slutet av det aktuella året (officiellt - 31 december 1997), tillkännagav i samma tidpunkt att det skulle ta den 1 oktober Året av certifieringstjänst i enlighet med FIPS 151-2, baserat på NIST / ITL-programmet. Samma funktioner från 1 januari 1998 antog IEEE-standardiseringsföreningen (IEEE-SA), och även baserat på FIPS 151-2.

År 2003 tillkännagav IEEE-SA och Open Group början på ett nytt gemensamt program för certifiering av de senaste posixversionerna, som började med IEEE 1003.1 (TM) 2001. Nu har Open Group flera tester som täcker IEEE STD 1003.1-1996, IEEE STD 1003.

2-1992, IEEE STD 1003.1-2003 och IEEE STD 1003.13-1998 (www.opengroup.org/testing/testsuites/posix.html). Produkten anses vara certifierad av POSIX om den passerade hela certifieringsförfarandet, enligt testresultat, uppfyller de alla presenterade kraven och är noterat i det officiella registret över certifierade produkter.

Testuppsättningar inkluderar:

VSX-PCTS1990 (www.opengroup.org/testing/testsuites/vsxpcts1990.htm) - En uppsättning av överensstämmelsesprov för systemgränssnitt IEEE STD 1003.1-1990;

Vspse54 (www.opengroup.org/testing/testsuites/vspse54.htm) - En uppsättning av överensstämmelseprov för IEEE STD 1003.13-1998 Profil PSE54 (multipurpose realtid);

VSX-PCTS2003 (www.opengroup.org/testing/testsuites/vsxpcts2003.htm) - En uppsättning av överensstämmelseprov för IEEE STD-systemgränssnitt 1003.1-2003 (endast obligatoriska delar);

VSC-PCTS2003 (www.opengroup.org/testing/testsuites/vcpppcts2003.htm) - En uppsättning av överensstämmelseprov för IEEE STD 1003.1-2003 (Shell and Utilities - Endast obligatoriska delar).

Dessutom har Open Group utvecklat test för Posix Realtime Standards och Embedded Posix Standards Profile. En uppsättning test för Posix RealTime (www.opengroup.org/testing/testsuites/realtime.html) innehåller följande test:

IEEE POSIX 1003.1B-1993 / 1003.1i-1995 Realtime Extension och IEEE POSIX 1003.1.2003 Edition;

IEEE STD POSIX 1003.1C-1995 Trådar (PTHREADS) Extension och IEEE POSIX 1003.1.2003 Edition;

IEEE POSIX 1003.1D-1999 Ytterligare Realtime Extension och IEEE POSIX 1003.1.2003 Edition;

IEEE POSIX 1003,1J-2000 Avancerad Realtim Extension och IEEE POSIX 1003.1.2003 Edition;

IEEE POSIX 1003.1Q-2000 Trace och IEEE POSIX 1003.1.2003 Edition och IEEE POSIX 1003.1.2003 Edition;

Embedded POSIX Standards Profile Test Set (www.opengroup.org/testing/testsuites/embedded.html) innehåller följande test:

IEEE POSIX 1003.1-1990 (5310 test);

IEEE POSIX 1003.1B-1993 / 1003.1i-1995 Realtime Extension (1430 test);

IEEE STD POSIX 1003.1C-1995 Tråd (PthREADS) förlängning (1232 test);

IEEE POSIX 1003.13-1998 Profil 52.

Lite om förvirring i terminologi

I förhållande till gruppen av standarder Posix på engelska, inte en, men så många som tre villkor. Tyvärr är de liknande i värde och översätts ofta lika, vilket ger en viss förvirring. Villkor Dessa är:

Kompatibilitet (bokstavligen "kompatibilitet");

Överensstämmelse (bokstavligen "överensstämmelse");

Sonformance (bokstavligen "konsistens").

Den första termen som tillämpas på POSIX är inte formellt definierad. Det andra innebär att organisationen är en mjukvaruproducent självständigt förklarar att denna produkt (helt eller delvis) uppfyller följande NIST-PCTS-standarder. Den tredje termen innebär att programvaran har gått installerat system Testar antingen med ett ackrediterat laboratorium eller inom den öppna gruppen och det har en dokumentärbekräftelse (det så kallade konformeringsutlåtandet). Vidare i texten i artikeln överallt kommer det att finnas original för att utesluta tvetydighet.

Certified OS RV.

Om du följer strikta regler som kräver att uppgifterna om det certifierade OS RV publiceras i det officiella registret och testet genomfördes på nivå ÖverensstämmelseDu har för närvarande bara två certifierade OS RV (data ges i kronologisk ordning):

- Lynxos v.3. (Produkt av företaget Lynx Real-Time-system, som nu heter Lynuxworks, Inc., www.lynuxworks.com) är avsedd för utveckling på inbyggda system som är verksamma inom hårda realtidstillverkare, tillverkare av komplett och telekommunikationsutrustning, i synnerhet tillverkare av ombordssystem av militär användning. Utvecklingen kan utföras både på målsystemet (självhärdat) och på verktygsdatorn (värd), redo att vara konstruerad för att fungera på målsystemet (mål). Lynxos V.3 är certifierad för konsistens (Överensstämmelse)pOSIX-standarden på Intel och PowerPC-plattformen. Information om detta finns på IEEE-webbplatsen http://standards.ieeee.org/regauth/posix/posix2.html.lynxos Certified av POSIX 1003.1-1996 Mindcraft, som är IEEE POSIX Accredited Posix Testing Laboratory for NIST Fips 151 Test 2 Conformance Test Suite. Dokumentnummer Bekräfta certifiering: Referensfil: IP-2LYX002, referensfil: IP-2LYX001.

- Integritet v.5 (Produkten av företaget Green Hills-programvara, www.ghs.com) är certifierad för konsistens (Överensstämmelse) Av POSIX 1003.1-2003, systemgränssnitt för PowerPC-arkitekturen i juli 2004 (http://get.posixcertified.ieee.org/select_product.tpl). Sats av test VSX-PCTS 2003.

POSIX och QNX operativsystem

Qnx v.4.20(Utvecklare - fasta QNX-programvaran, www.qnx.com) certifierad för överensstämmelse (Överensstämmelse) POSIX 1003.1-1988 för plattformen Intel-företag Datafocus inkorporerat. Testning genomfördes den 13 september 1993, dagen för utfärdandet av dokumentet - 1 november 1993. Sats av test NIST PCT 151-1, version 1.1.

QNX NeutRino (version 6.3) uppfyller (uppfyller) nästa standarder för Posix-familjen (www.qnx.com/download/download/8660/portability.pdf):

Posix.1 (IEEE 1003.1);

Posix.1a (IEEE 1003.1A);

Posix.2 (IEEE 1003.2);

Posix.4 (IEEE 1003.1b);

Posix.4a (IEEE 1003.1c);

Posix.1b (IEEE 1003.1D), IEEE 1003,1J;

POSIX.12 (IEEE 1003,1g).

QNX-programvaran, skaparen av QNX Neutrino, planerar också att certifiera (överensstämmelse) QNX Neutrino enligt vissa av dessa standarder; Arbeten är planerade till 2005 (www.qnx.com/news/pr_959_1.html).

Litteratur

1. IEEE Standards Association Operation Manual. IEEE, oktober 2004.

2. Kevin M. Obeland.. POSIX i realtid, inbäddad systemprogrammering, 2001.

3. IEEE / ANSI Standard 1003.1: Informationsteknik - (POSIX) - Part1: Systemansökan: Programgränssnitt (API).

4. Gallmeister B. O. Programmering för den verkliga världen, posix.4 Sebastopol, CA: O'Reilly & Associates, 1995.

5. National Institute of Standards and Technology, PCT: 151-2, Posix Test Suite.

6. POSIX: Certifierad av IEEE och Open Group. Certifierad policy. Den öppna gruppen, 21 oktober 2003, Revision 1.1.

Programvara) - uppgiften av exceptionell betydelse och komplexitet Nuförtiden behöver denna omständighet knappast omfattande motiveringar. Ett av de allmänt accepterade sätten att förbättra programvaran för programvara är att standardisera programmens miljö: Programmeringsgränssnitt, verktyg, etc. På nivån systemtjänster En liknande miljö beskriver POSIX-standarden (bärbart operativsystemgränssnitt - mobil operativsystemgränssnitt); Namnet föreslås av en välkänd specialist, grundaren av Free Software Foundation Richard Tornen.

Vi kommer att överväga de mest moderna av de tillgängliga versionerna av POSIX-standarden, ändrad senast 2003, som kan kallas "Standard Triple", nämligen: IEEE STD 1003.1 Standard, Teknisk standard Open Group och (se [6]), som är viktigast för oss, den internationella standarden ISO / IEC 9945 (se [1], [2], [3], [4]).

Historien om att skapa den här versionen är sådan. I början av 1998, företrädare för tre organisationer - utskottet för mobila applikationsstandarder för elektrotekniska ingenjörer och elektronikinstitut, öppen grupp och arbetsgrupp 15 i underkommittén 22 i det gemensamma tekniska kommittén 1 (JTC1 / SC22 / WG15) av den internationella Organisation för standardisering - började samråda med fusion och utveckling av gränssnittstandarder som övervakas av dem till systemtjänster: IEEE STD 1003.1, IEEE STD 1003.2, Grundläggande specifikationer från Open Group, ISO / IEC 9945-1, ISO / IEC 9945-2. I september samma år i staden Austin, Texas, ett organisationsmöte i gruppen bildades för att uppnå målet (se http://www.opengroup.org/austin) ägde rum på IBM-kontoret.

Det grundläggande dokumentet för den reviderade standarden, vars första projekt presenterades i juli 1999, var de grundläggande specifikationerna från den öppna koncernen, eftersom de innehöll bestämmelserna i IEEE och ISO / IEC-standarder. Under 2001 innehöll standarden efter det att det förberedande arbetet innehöll följande fyra delar:

huvuddefinitioner (villkor, koncept och gränssnitt som är gemensamma för alla delar);
beskrivning ansökan C-gränssnitt till systemtjänster;
beskrivning av gränssnittet till systemtjänster på nivån kommandorskap och serviceprogram ;
en detaljerad förklaring av standardbestämmelserna, motiveringen för de beslut som fattas.

Vidare i ISO har IEEE och Open Group med en större eller mindre hastighet (2001-2002) ett formellt godkännande av den nya POSIX-standarden gått. Under tiden ackumulerades relativt mindre korrigeringar, beaktades under 2003-talet.

Med utvecklingen av standarden expanderade tolkningen av termen "POSIX". Ursprungligen hänvisade han till IEEE STD 1003.1-1988, som beskrivs ansökningsprogramgränssnitt OS-klass UNIX. Efter att ha standardiserat gränssnittet på kommandoreginivå och serviceprogram, är det mer korrekt förstått under ordet "POSIX" -standard i allmänhet, som anger del 2 och 3 som anges ovan via posix .1 och posix .2 i enlighet med numreringen av IEEE och ISO / IEC-dokument.

De viktigaste idéerna i POSIX-standarden

POSIX-standarden beskriver ett flertal grundläggande systemtjänster som krävs för att applikationerna fungerar. Tillgång till dem tillhandahålls av ett gränssnitt som anges för C, Command Language och Common Service-program.

Varje gränssnitt har två sidor: orsakar och kallas. POSIX-standarden är främst inriktad på uppringningen. Hans mål är att göra applikationer mobil på källspråksnivå. Detta innebär i synnerhet att när man överför C-program till en annan operativplattform, kommer omkompilering att krävas. Om rörligheten för exekverbara program och / eller objektfiler spelar ingen roll.

POSIX-standarden är inte begränsad till UNIX-miljöramen. Det finns operativsystem (OS) "Oberoende ursprung" (till exempel, realtidssystem), tillhandahålla de nödvändiga tjänsterna och därigenom stödja utförandet av posix-kap-applikationer. Det kan hävdas att följande POSIX-standarden underlättar överföringen av applikationer till nästan alla vanliga operativplattform. Ytterligare ansträngningar för att förbättra rörligheten som bifogas under utvecklingsfasen kommer definitivt att betala.

Bestämning av gränssnittet till systemtjänster lämnar POSIX ramverket för deras genomförande. I synnerhet skiljer du inte systemsamtal och biblioteksfunktioner. Är inte ett föremål för standardiseringsorgan administrering, hårdvarubegränsningar och funktioner som är nödvändiga super efterträdareVad betonar återigen fokusen på standarden

Idag försöker vi ta reda på vad POSIX-standarden beskriver. Standarder är avsedda att se till att min dator kan interagera med din. Tack vare dem kommer på två liknande webbsidor eller sändningsvideo i realtid att se lika ut.

Standarden är dock avsedd för större uppgifter än en enkel utbyte av data mellan användare. Vissa standarder definierar en speciell modell, tack vare vilka funktioner som är betydligt överlägsna i deras värdekompatibilitet med filer eller nätverk. POSIX-standarden hänvisar till deras nummer.

Vad är posix?

Posix (uttalad "posiks") är ett bärbart operativsystemgränssnitt. Men vad betyder det? Först måste du ange området för begreppet "portabilitet", i detta betongfodraloch bestämma om begreppet "gränssnitt". För att ta reda på detta är det nödvändigt att avvärja det faktum att båda koncepten är oupplösligt kopplade.

"Portability", i samband med POSIX-standarden, hänvisar till källkod (Inte till det binära som samlas in från dessa mycket källor). Ta reda på vad "gränssnittet" är. I programmering är "gränssnittet" interaktionen mellan din kod med resten av koden. Gränssnittet väntar på att tillhandahålla specifik information från din kod. Din kod innebär i sin tur att få viss information från gränssnittet. Bra exempel - Fopen () Funktion i SI. Det förväntar sig information från två delar: sökvägen till filen och det läge där det öppnas. Med hjälp av dessa data returnerar operativsystemet en annan typ av information som heter "File descriptor". Filhandtaget kan användas för att läsa filen eller skriv till filen. Detta är gränssnittet. Av allt detta följer att en posix-kompatibel kod kan sammanställas under något posix-kompatibelt operativsystem utan stora förändringar, vilket innebär att det kommer att vara bärbart.

Listan över gränssnitt som hänför sig till POSIX-standarden är emellertid även trots sin stora längd, det är möjligt att han är bristfällig. POSIX är inte begränsat till systemutmaningar, det definierar också standarder för skal av operativsystem (hyllor, annars - gränssnitt kommandorad), systemverktyg, som "AWK" eller "ECHO", systembibliotek och många andra saker.

POSIX-standarden uppträdde i form av ett projekt av Richard Pokalman 1985 och var ytterligare dekorerad som IEEE STD 1003.-1998. Som framgår av namnet var 1998 året för officiell publikation. Sedan dess har ett stort antal tillägg och förlängningar för Posix släppts, vilket gradvis blir en hel familj av standarder, formellt känd som IEEE 1003, erkänd som internationell, med beteckningen av SO / IEC 9945, som helt enkelt kallas POSIX Familjstandard.

Operativsystemet är inte allt nödvändigt för att vara posix-kompatibelt eller ännu mer, så att du har ett POSIX-certifikat, men det gör det möjligt för utvecklare att skapa applikationer, verktyg och plattformar, utan omskrivningskod en gång i tiden, men kompletterar bara och ansluts till färdiga -Avsluta. Det är inte heller nödvändigt att skriva en posix-kompatibel kod alls, men det förbättrar signifikant produktens bärbarhet mellan operativsystem. Det innebär att förmågan att skriva en kod som är kompatibel med POSIX-standarden är värdefull i sig, och säkert mycket användbar för en karriär. Stora projekt, som GNOME eller KDE, följer POSIX-standarden, vilket garanterar sitt arbete på olika operativsystem. POSIX-delsystemet implementeras även i nya problem Fönster. Linux, som du vet, stöder de flesta systemsamtal som är relaterade till POSIX-standarden, liksom stor förlängning till den, kallad "Standard Linux Base", som är utformad för att kombinera Linux-distributioner när det gäller att stödja källkod och binär data .

Jag hoppas vi kasta ljuset på frågan "Vad är posix." Har du intressant information om ämnet? Vänligen dela den i kommentarerna.

POSIX och OS RV: Försök att systematisera

Sergey Zolotarev, Nikolai Gorbunov

Syftet med denna artikel är att försöka göra en viss klarhet i POSIX-standardernas utvecklingshistoria i förhållande till operativsystem i realtid (OS RV).

Som en introduktion: Varför behöver du en programmeringsgränssnittsstandardisering?

Återanvänd kod från tidigare och parallella projekt;
Överföring av kod från andra operativsystem;
att locka utvecklare från andra projekt (inklusive användning av andra operativsystem).

Med hjälp av ett POSIX-kompatibelt OS som en plattform för sina projekt kan utvecklaren överföra den färdiga koden på källkodsnivån från sitt förflutna eller parallella projekt och från tredje parts projekt. Detta minskar inte bara tidpunkten för mjukvaruutveckling, men förbättrar också sin kvalitet, eftersom den beprövade koden alltid innehåller mindre fel.

Vem är vem i utvecklingen av posix

Och låt oss börja med den mycket vanliga posixen, men för att beställa rollen som organisationer som är inblandade i att arbeta på den.

Den första deltagaren är IEEE. Institutet för elektriska och elektronikingenjörer, institut för elektriker ingenjörer och elektronik), offentliga ideella organisationer. IEEE leder sin historia sedan 1884 (formellt - sedan 1963), kombinerar 380 000 enskilda medlemmar från 150 länder, publicerar den tredje delen av den tekniska litteraturen om användningen av datorer, hantering, elektrisk och informationsteknik samt mer än 100 tidskrifter, Populär i miljön av proffs; Dessutom är föreningen per år över 300 stora konferenser. IEEE deltog i utvecklingen av mer än 900 befintliga standarder (www.ieee.ru/ieeee.htm). Idag är detta institut engagerat med att förbereda, godkännande, godkännande, förlag, men i sin formella status har inte befogenhet att acceptera sådana handlingar som internationella eller nationella standarder. Därför bör termen "standard" i förståelsen av IEE hellre förstås som "specifikation", vilket är mer ansvarsfullt för statusen för de handlingar som tagits av föreningen. I enlighet med IEEE deltar i programmen för ett antal internationella och regionala organisationer - IEC, ISO, ITU (European Telecommunications Standards Institute for ElectRotechnical Standartization) och i nationella program, såsom programmet för en sådan organisation som ANSI.

IEEE inkluderar PASK (Portable Application Standards Committee) - Föreningskommittén, som utvecklar en familj av standarder Posix (www.pasc.org/). Tidigare var PASCC känt som tekniska kommittén för verksamhet.

Den andra deltagaren av arbete - ANSI. (American National Standards Institute, American National Standards Institute) - en privat ideell organisation som administrerar och koordinater i Förenta staterna om standardiseringsfrågor. Det sysselsätter endast 75 personer, men medlemmar av ANSI är mer än 1000 företag, organisationer, myndigheter och institutioner (www.ansi.org). ANSI representerar Förenta staterna i två huvudsakliga internationella organisationer för standardisering - ISO och IEC.

Tredje deltagare - Iso. Internationell organisation för standardisering, internationell organisation för standardisering). Det skapades 1946 genom beslut av kommittén för samordning av standarder och FN: s generalförsamling och började officiellt arbeta den 23 februari 1947 (www.iso.org). ISO är ett nätverk av nationella standardiseringsinstitut från 146 länder (ett land är ett ISO-medlem) med det centrala sekretariatet i Genève (Schweiz). ISO-standarder är utvecklade i tekniska kommittéer, vars första resultat är ett utkast till internationellt standarddokument (DIS), som vänder sig efter flera matchande i slutliga utkast till internationell standard (FDI). Därefter görs frågan om godkännande av detta dokument till en omröstning. Med ett positivt resultat blir det en internationell standard.

Till sist, - IEC. Internationell elektroteknisk kommission, internationell elektroteknisk kommission - IEC), grundad 1906, förbereder IEC och publicerar internationella standarder för all elektronisk, elektronisk och relaterad teknik (www.iec.ch/). Från och med den 1 november 2004 var de nationella kommittéerna i 64 länder de giltiga medlemmarna i denna kommission. IEC publicerar också rekommendationer som kommer ut på engelska och franska och utföra statusen för internationella standarder. De är baserade på regionala och nationella standarder. Tekniska kommittéer (TC) ansvarar för utarbetandet av standarder på olika områden av IEC-verksamhet, och nationella kommittéer som är intresserade av en TC: s verksamhet är också inblandade.

IEC är en nyckelorganisation vid utarbetandet av internationella standarder för informationsteknik. Detta område har en gemensam teknisk kommitté för informationsteknik - JTC 1 som bildades 1987 i enlighet med avtalet mellan IEC och ISO. JTC1 har 17 underkommittéer som övervakar all utveckling - från programvara för att programmera språk, datorgrafik och redigering av bilder, sammankoppling av utrustning och säkerhetsmetoder.

Några fler organisationer är relaterade till utveckling och antagande av POSIX-standarder.

Öppen grupp. - Internationell organisation för programvarustandardisering, som samlar nästan 200 tillverkare och användargrupper som arbetar inom informationsteknik (www.opengroup.org/). Open Group skapades 1995 genom att slå samman de två föregångarna: X / Open och Open Software Foundation (OSF). Open Group är specialiserat på utveckling av programvarucertifieringsmetoder och testning för överensstämmelse med vissa krav. I synnerhet är Open Group certifierad för områden som COE-plattform, Corba, LDAP, Linux-standardbas, skolans driftskompatibilitet (SIF), S / Mime Gateway, Single UNIX-specifikation, trådlös appl(WAP) och slutligen familj av posix standarder (www.opengroup.org/certification/).

Austin Common Standards Revisionsgrupp (CSRG) - Den unga tekniska arbetsgruppen som bildades 2002 ISO, IEC och Open Group för att skapa och behålla de senaste versionerna av standarden 1003.1, som kommer att bildas baserat på ISO / IEC 9945-1-1996, ISE / IEC 9945-2-1993 , IEEE STD 1003.1-1996, IEEE STD 1003.2-1992 och enstaka UNIX-specifikation (www.opengroup.org/press/14nov02.htm).

National Institute of Standards and Technology (NIST) - Federal byrå följde Commerce Departments teknikadministration (www.nist.gov/public_affarna/general2.htm), grundad i USA 1901. NIST: s uppgift är utveckling och propaganda av standarder och teknik för att förbättra produktkvaliteten. NIST inkluderar ett informationsteknologi laboratorium (ITL), ett av resultaten av aktiviteter som är federala i(federala i- fips, www.opengroup.org/testing/fips/general_info.html). NIST / ITL Erbjuder 1991 den första uppsättningen test för POSIX-certifiering under FIPS PUB 151-1 1990.

Vad är posix?

Formellt term Posix. föreslagna av Richard Stallman (Richard Stallman) som en förkortning för P.ortable. O.omvandling S.ystem gränssnitt för un Ix (Bärbart gränssnitt för operativsystem för UNIX). POSIX utvecklades för Unix-liknande operativsystem (deras första versioner räknas från början av 1970-talet) för att säkerställa portabiliteten hos applikationer på källkodsnivå.

Den ursprungliga beskrivningen av gränssnittet publicerades 1986, då kallades han IEEE-IX (IEEE: s version av UNIX). Men namnet har förändrats snabbt, vänder sig till Posix, och den här nya versionen har använts i följande publikation (tillbaka 1986). För en tid under POSIX, referens (eller synonym) förstods som en grupp av IEEE 1003.1-1988 relaterade dokument och en del av ISE / IEC 9945, och som en komplett och godkänd internationell ISO / IEC-standard 9945.1: 1990 POSIX antogs 1990. POSIX-specifikationer definierar standardmekanismen för interaktion mellan applikationsprogrammet och OS och innehåller för närvarande mer än 30 standarder under IEEE, ISO, IEC och ANSI.

POSIX Standard Development History

Den första versionen av IEEE STD 1003.1-specifikationen publicerades 1988. Därefter antogs många utgåvor av IEEE STD 1003.1 som internationella standarder.

POSIX Development Stages:

1990

Redaktionskontoret som utfärdades 1988 återvinns och blev grunden för ytterligare redaktörer och tillägg. Den godkändes som en internationell standard ISO / IEC 9945-1: 1990.

1993

Redaktionskontoret på 1003,1B-1993 kommer.

1996

IEEE STD 1003.1B-1993, IEEE STD 1003.1c-1995 och 1003.1i-1995 gjordes, men huvuddelen av dokumentet var oförändrad. År 1996 godkändes även utgåvan av IEEE STD 1003.1 som en internationell standard ISO / IEC 9945-1: 1996.

1998

Det finns en första standard för "Real-Time" - IEEE STD 1003.13-1998. Detta är expansionen av POSIX-standarden för inbäddade realtidsansökningar.

1999

Det beslutades att göra betydande förändringar i standardtexten i standarden under de senaste 10 åren, inklusive fackföreningen med standarden 1003.2 (skal och verktyg), sedan det var separata standarder. PSC bestämde sig för att slutföra byte av grundtexten efter avslutad standarder för IEEE 1003.1a, 1003,1d, 1003,1 g, 1003,1j, 1003,1Q och 1003.2b.

2004

Senast idag publicerades redaktionen på 1003,1 den 30 april och släpptes under Austin Common Standards Revisionsgrupp. Det gjorde ändringar avseende redaktionskommittén 2001. Formellt är redaktionskontoret 2004 känt som IEEE STD 1003.1, 2004-utgåvan, den öppna gruppens tekniska standardbasspecifikationer, utgåva 6 och innehåller IEEE STD 1003.1-2001, IEEE STD 1003.1-2001 / Cor 1-2002 och IEEE STD 1003.1-2001 / COR 2-2004.

De viktigaste standarderna för POSIX för RV OS

För operativsystem i realtid är sju standardspecifikationer viktigast (1003,1a, 1003,1j, 1003,1c, 1003,1d, 1003,1j, 1003,21), men endast tre stöddes i stor utsträckning i det kommersiella OS:

1003.1a (OS-definition) Anger de grundläggande gränssnitten i operativsystemet, jobbhantering, signaler, filsystemfunktioner och enheter, användargrupper, transportörer, FIFO-buffertar;
1003.1b (Realtime Extensions) Beskriver realtidsförlängningar, såsom realtidssignalering, prioritetsdispatcher, timers, synkron och asynkron ingång, semaforer, delat minne, meddelanden. Ursprungligen (fram till 1993) betecknades denna standard som posix.4.
1003,1c (trådar) Definierar strömstödfunktioner (trådar) - Flödesstyrning, strömtillbehör, mutexer, sändning. Ursprungligen betecknad som posix.4a.

Utöver dessa standarder är följande standarder viktiga för RV, som genomfördes som en del av STD-projektet 1003.1-2001:

IEEE 1003.1D-1999. Ytterligare expansioner av realtid. Ursprungligen betecknad som posix.4b;
IEEE 1003,1J-2000. Förbättrad (avancerad) realtids expansion;
IEEE 1003.1Q-2000. Spårning.

Certifieringsförfarande

År 1991 har NIST utvecklat ett POSIX-testprogram inom FIPS 151-1 (http://standards.ieee.org/regauth/posix/posix-a.fm5.pdf). Detta testalternativ var baserat på IEEE 1003.3 "standard för testmetoder för att mäta överensstämmelse med POSIX" utkast 10, maj 3, 1989. År 1993 har NIl examen från testprogrammet för FIPS 151-1 och började ett program för FIPS 151 -2 (www.itl.nist.gov/fipspubs/fip151-2.htm). FIPS 151-2 Anpassad "Informationsteknik - Bärbart operativsystemgränssnitt (POSIX) - Del 1: Systemprogramgränssnitt (API)," ISO / IEC 9945-1: 1990-standarden. Testuppsättningar för FIPS 151-2 var baserade på IEEE 2003.1-1992 "standard för testmetoder för mätning av överensstämmelse med posix".

År 2003 tillkännagav IEEE-SA och Open Group början på ett nytt gemensamt program för certifiering av sista versioner av POSIX, som börjar med IEEE 1003.1 ™ 2001. Nu har den öppna gruppen flera test som täcker IEEE STD 1003.1-1996, IEEE STD 1003.2-1992, IEEE STD 1003.1-2003 och IEEE STD 1003.13-1998 (www.opengroup.org/testing/testsuites/posix.html). Produkten anses vara certifierad av POSIX om den passerade hela certifieringsförfarandet, enligt testresultat, uppfyller de alla presenterade kraven och är noterat i det officiella registret över certifierade produkter.

Testuppsättningar inkluderar:

VSX-PCTS1990 (www.opengroup.org/testing/testsuites/vsxpcts1990.htm) - En uppsättning av överensstämmelsesprov för systemgränssnitt IEEE STD 1003.1-1990;
Vspse54 (www.opengroup.org/testing/testsuites/vspse54.htm) - En uppsättning av överensstämmelseprov för IEEE STD 1003.13-1998 Profil PSE54 (multipurpose realtid);
VSX-PCTS2003 (www.opengroup.org/testing/testsuites/vsxpcts2003.htm) - En uppsättning av överensstämmelseprov för IEEE STD-systemgränssnitt 1003.1-2003 (endast obligatoriska delar);
VSC-PCTS2003 (www.opengroup.org/testing/testsuites/vcpppcts2003.htm) - En uppsättning av överensstämmelseprov för IEEE STD 1003.1-2003 (Shell and Utilities - Endast obligatoriska delar).

IEEE POSIX 1003.1B-1993 / 1003.1i-1995 Realtime Extension och IEEE POSIX 1003.1.2003 Edition;
IEEE STD POSIX 1003.1C-1995 Trådar (PTHREADS) Extension och IEEE POSIX 1003.1.2003 Edition;
IEEE POSIX 1003.1D-1999 Ytterligare Realtime Extension och IEEE POSIX 1003.1.2003 Edition;
IEEE POSIX 1003,1J-2000 Avancerad Realtim Extension och IEEE POSIX 1003.1.2003 Edition;
IEEE POSIX 1003.1Q-2000 Trace och IEEE POSIX 1003.1.2003 Edition och IEEE POSIX 1003.1.2003 Edition;

Embedded POSIX Standards Profile Test Set (www.opengroup.org/testing/testsuites/embedded.html) innehåller följande test:

IEEE POSIX 1003.1-1990 (5310 test);
IEEE POSIX 1003.1B-1993 / 1003.1i-1995 Realtime Extension (1430 test);
IEEE STD POSIX 1003.1C-1995 Tråd (PthREADS) förlängning (1232 test);
IEEE POSIX 1003.13-1998 Profil 52.

Lite om förvirring i terminologi

kompatibilitet (bokstavligen "kompatibilitet");
överensstämmelse (bokstavligen "överensstämmelse");
sonformance (bokstavligen "konsistens").

Den första termen som tillämpas på POSIX är inte formellt definierad. Det andra innebär att organisationen är en mjukvaruproducent självständigt förklarar att denna produkt (helt eller delvis) uppfyller följande NIST-PCTS-standarder. Den tredje termen innebär att mjukvaruprodukten har godkänt det inställda testsystemet eller med ett ackrediterat laboratorium eller inom den öppna gruppen och det har en dokumentärbekräftelse (det så kallade konformeringsutlåtandet). Vidare i texten i artikeln överallt kommer det att finnas original för att utesluta tvetydighet.

Certified OS RV.

Om du följer strikta regler som kräver att uppgifterna om certifierad OS RV offentliggörs i det officiella registret och testningen genomfördes när det gäller överensstämmelse, nu finns det bara två certifierade OS RV (data ges i kronologisk ordning):

Lynxos v.3. (Produkt av företaget Lynx Real-Time-system, som nu heter Lynuxworks, Inc., www.lynuxworks.com) är avsedd för utveckling på inbyggda system som är verksamma inom hårda realtidstillverkare, tillverkare av komplett och telekommunikationsutrustning, i synnerhet tillverkare av ombordssystem av militär användning. Utvecklingen kan utföras både på målsystemet (självhärdat) och på verktygsdatorn (värd), redo att vara konstruerad för att fungera på målsystemet (mål). Lynxos V.3 är certifierad av konsistens (överensstämmelse) Posix-standard på Intel och PowerPC-plattformen. Denna information finns på IEEE-webbplatsen http://standards.ieeeee.org/regauth/posix/posix2.html. Lynxos är certifierad av POSIX 1003.1-1996 av Mindcraft, som är IEEE POSIX Accredited Posix Testing Laboratory för NIST FIPS 151-2 Conformant Test Suite Test. Dokumentnummer Bekräfta certifiering: Referensfil: IP-2LYX002, referensfil: IP-2LYX001.

Integritet v.5 (Produkten av företaget Green Hills-programvaran, www.ghs.com) är certifierad för konsekvens (överensstämmelse) av POSIX 1003.1-2003, systemgränssnitt för PowerPC-arkitekturen i juli 2004 (http://get.posixcertified.ieee.org/ select_product. TPL). Sats av test VSX-PCTS 2003.

POSIX och QNX operativsystem

QNX V.4.20 (Developer-Firm QNX Software Systems, www.qnx.com) Certifierad för överensstämmelse (överensstämmelse) av POSIX 1003.1-1988 för Intel-plattformen genom DataFocus inkorporerad. Testning genomfördes den 13 september 1993, dagen för utfärdandet av dokumentet - 1 november 1993. Sats av test NIST PCT 151-1, version 1.1.

QNX NeutRino (version 6.3) uppfyller (uppfyller) nästa standarder för Posix-familjen (www.qnx.com/download/download/8660/portability.pdf):

Posix.1 (IEEE 1003.1);
Posix.1a (IEEE 1003.1A);
Posix.2 (IEEE 1003.2);
Posix.4 (IEEE 1003.1b);
Posix.4a (IEEE 1003.1c);
Posix.1b (IEEE 1003.1D), IEEE 1003,1J;
POSIX.12 (IEEE 1003,1g).

Litteratur

IEEE Standards Association Operation Manual. IEEE, oktober 2004.
Kevin M. Obeland. POSIX i realtid, inbäddad systemprogrammering, 2001.
IEEE / ANSI Standard 1003.1: Informationsteknik - (POSIX) - Part1: Systemansökan: Programgränssnitt (API).
Gallmeister, B. O. Programmering för den verkliga världen, posix.4 Sebastopol, CA: O'Reilly & Associates, 1995.
National Institute of Standards and Technology, PCT: 151-2, Posix Test Suite.
POSIX: Certifierad av IEEE och Open Group. Certifierad policy. Den öppna gruppen, 21 oktober 2003, Revision 1.1.

UNIX-standardisering av operativsystem och posix. Standarder för operativsystem i realtid

Om standarder i allmänhet

Utnämning och "Superbate" av standardposixen

Om semantik

Överensstämmelse med standard. Ordets semantik "motsvarar"

Standardiseringsobjekt och standardstruktur

Slutsats

Om äkta

Litteratur

De viktigaste idéerna i POSIX-standarden

Vad är posix?

POSIX och OS RV: Försök att systematisera

Som en introduktion: Varför behöver du en programmeringsgränssnittsstandardisering?

Vem är vem i utvecklingen av posix

Vad är posix?

POSIX Standard Development History

De viktigaste standarderna för POSIX för RV OS

Certifieringsförfarande

Lite om förvirring i terminologi

Certified OS RV.

POSIX och QNX operativsystem

Återställning av lösenord