Geschiedenis van softwareontwikkeling. Basisconcepten van de posix-standaard

NORMEN

Sergej Zolotarev,

Het doel van dit artikel is een poging om enige duidelijkheid te brengen in de geschiedenis van de ontwikkeling van de POSIX-standaard in relatie tot real-time besturingssystemen (RTOS).

Ter introductie: waarom is standaardisatie van software-interfaces noodzakelijk?

Een van de belangrijkste eigenschappen van de POSIX-standaard is dat deze een ‘gestandaardiseerde programmeerinterface’ definieert waaraan ontwikkelaars van complexe hardware- en softwaresystemen zich moeten houden. De makers van deze systemen worden gedwongen om te gaan met vereisten zoals een korte time-to-market (vanwege de hevige concurrentie), het minimaliseren van de kosten en het versnellen van het rendement op investeringen. Tegelijkertijd is het leeuwendeel van de kosten die worden veroorzaakt door de vertraging in het ontwikkelingsproces te wijten aan het feit dat programmeurs “het wiel opnieuw moeten uitvinden”, waarbij ze steeds opnieuw functionaliteit moeten implementeren die al lang beschikbaar is. Maar dit had voorkomen kunnen worden door:

Hergebruik van code uit eerdere en parallelle projecten;

Code overbrengen van andere besturingssystemen;

Het aantrekken van ontwikkelaars uit andere projecten (inclusief het gebruik van andere besturingssystemen).

Dit alles is mogelijk dankzij het gebruik van een besturingssysteem met een gestandaardiseerde API. Bovendien, als het in het eerste geval voldoende is dat een organisatie een soort interne standaard heeft (wat vooral typerend is voor propriëtaire besturingssystemen), dan vereisen de tweede twee gevallen de aanwezigheid van algemeen erkende standaarden, bijvoorbeeld POSIX.

Door een POSIX-compatibel besturingssysteem als platform voor zijn projecten te gebruiken, heeft de ontwikkelaar dus de mogelijkheid om kant-en-klare code op bronniveau over te dragen, zowel uit zijn eerdere of parallelle projecten, als uit projecten van derden. Dit verkort niet alleen de softwareontwikkelingstijd aanzienlijk, maar verbetert ook de kwaliteit ervan, omdat geteste code altijd minder fouten bevat.

Wie is wie bij POSIX-ontwikkeling

En we beginnen niet met de POSIX-standaard zelf, maar met het stroomlijnen van de rol van organisaties die eraan werken.

De eerste deelnemer is IEEE(Institute of Electrical and Electronics Engineers), publieke non-profitorganisatie van professionals. IEEE gaat terug tot 1884 (formeel sinds 1963), verenigt 380.000 individuele leden uit 150 landen, publiceert een derde van de technische literatuur met betrekking tot de toepassing van computers, besturings-, elektrische en informatietechnologie, evenals meer dan 100 tijdschriften, populair onder professionals; Daarnaast organiseert de vereniging jaarlijks meer dan 300 grote conferenties. IEEE heeft deelgenomen aan de ontwikkeling van meer dan 900 huidige standaarden (www.ieee.ru/ieee.htm). Tegenwoordig houdt dit instituut zich bezig met de voorbereiding, coördinatie, goedkeuring en publicatie van standaarden, maar vanwege zijn formele status heeft het niet de bevoegdheid om documenten zoals internationale of nationale standaarden over te nemen. Daarom betekent de term 'standaard' in de zin van IEEE eerder 'specificatie', wat meer consistent is met de status van documenten die door de vereniging zijn aangenomen. Neemt in overeenstemming met IEEE deel aan de programma's van een aantal internationale en regionale organisaties - IEC, ISO, ITU (International Telecommunication Union), ETSI (European Telecommunications Standards Institute), CENELEC (European Committee for Electrotechnical Standardization) en aan nationale programma's, bijvoorbeeld in het programma van een organisatie als ANSI.

IEEE omvat PASC (Portable Application Standards Committee; www.pasc.org/), een associatiecomité dat de POSIX-standaardfamilie ontwikkelt. PASC was voorheen bekend als de Technische Commissie voor besturingssystemen.

De tweede deelnemer aan het werk is ANSI (American National Standards Institute, American National Standards Institute; www.ansi.org) - een particuliere non-profitorganisatie die standaardisatieactiviteiten in de Verenigde Staten beheert en coördineert. Er werken slechts 75 mensen, maar tot de ANSI-leden behoren meer dan 1.000 bedrijven, organisaties, overheidsinstanties en instellingen. ANSI vertegenwoordigt de Verenigde Staten in de twee grote internationale standaardorganisaties, ISO en IEC.

Derde deelnemer - ISO(Internationale Organisatie voor Standaardisatie, Internationale Organisatie voor Standaardisatie; www.iso.org). Het werd in 1946 opgericht bij besluit van het Comité voor de Coördinatie van Normen en de Algemene Vergadering van de VN en ging officieel van start op 23 februari 1947. ISO is een netwerk van nationale normalisatie-instituten uit 146 landen (één land – één ISO-lid) met een centraal secretariaat in Genève (Zwitserland). ISO-normen worden ontwikkeld in technische commissies, waarvan het eerste resultaat de Draft International Standard (DIS) is, die na verschillende goedkeuringen verandert in de Final Draft International Standard (FDIS). Hierna wordt er over de goedkeuring van dit document gestemd; als het resultaat positief is, wordt het een internationale standaard.

En tenslotte - IEC(International Electrotechnical Commission, International Electrotechnical Commission - IEC; www.iec.ch/), opgericht in 1906, bereidt en publiceert de IEC internationale normen voor alle elektrische, elektronische en aanverwante technologieën. Vanaf 1 november 2004 waren nationale commissies van 64 landen actieve leden van deze commissie. De IEC brengt ook aanbevelingen uit, die in het Engels en het Frans worden gepubliceerd en de status van internationale standaarden hebben. Op basis daarvan worden regionale en nationale normen ontwikkeld. Technische commissies (TC's) zijn verantwoordelijk voor het opstellen van normen op verschillende gebieden van IEC-activiteiten, aan wier werk ook nationale commissies deelnemen die geïnteresseerd zijn in de activiteiten van een bepaalde TC.

IEC- een sleutelorganisatie bij de voorbereiding van internationale normen voor informatietechnologie. Op dit gebied bestaat er een gezamenlijke technische commissie voor informatietechnologie, JTC 1, die in 1987 werd opgericht in overeenstemming met een overeenkomst tussen IEC en ISO. JTC1 heeft 17 subcommissies die toezicht houden op alles, van software tot programmeertalen, computergraphics en beeldbewerking, hardware-interconnecties en beveiligingstechnieken.

De voorbereiding van nieuwe IEC-normen omvat verschillende fasen (voorontwerp, voorstel, voorbereiding, technisch comité, verzoek, goedkeuring, publicatie). Als het de bedoeling is dat een IEC-document slechts een technische specificatie wordt en geen internationale standaard, wordt een herziene versie van het document ter publicatie naar het centrale bureau gestuurd. Er zijn vier maanden uitgetrokken voor de ontwikkeling van het definitieve ontwerp van de internationale standaard (FDIS). Als het door alle leden van de technische commissie wordt goedgekeurd, wordt het zonder de FDIS-goedkeuringsfase naar het hoofdkantoor gestuurd voor publicatie. De FDIS gaat vervolgens naar nationale commissies, die deze binnen twee maanden moeten goedkeuren. De FDIS wordt als goedgekeurd beschouwd als meer dan tweederde van de nationale commissies ervoor stemt en het aantal negatieve stemmen niet groter is dan 25%. Als een document niet wordt goedgekeurd, wordt het ter beoordeling naar technische commissies en subcommissies gestuurd. De standaard moet uiterlijk twee maanden na goedkeuring door de FDIS worden gepubliceerd.

Verschillende andere organisaties zijn betrokken bij de ontwikkeling en acceptatie van POSIX-standaarden.

Groep openen is een internationale organisatie voor softwarestandaarden die bijna 200 leveranciers en gebruikersgemeenschappen samenbrengt die werkzaam zijn op het gebied van informatietechnologie (www.opengroup.org/).OpenGroup werd in 1995 opgericht door de twee voorgangers samen te voegen: X/Open en de Open Software Foundation (OSF). Open Group is gespecialiseerd in het ontwikkelen van sen het testen op naleving van specifieke eisen. In het bijzonder houdt de Open Group zich bezig met certificering voor gebieden als COE Platform, CORBA, LDAP, Linux Standard Base, Schools Interoperability Framework (SIF), S/MIME Gateway, Single UNIX Specification, Wireless Application Protocol Specifications (WAP) en, tenslotte de POSIX-standaardfamilie (www.opengroup.org/certification/).

AustinCommonStandardsRevisionGroup (CSRG)- een gezamenlijke technische werkgroep die in 2002 werd opgericht door ISO, IEC en Open Group om de nieuwste versies van de 1003.1-standaard te creëren en te onderhouden, die zal worden gevormd op basis van ISO/IEC 9945-1-1996, ISO/IEC 9945- 2-1993, IEEE Std 1003.1-1996, IEEE Std 1003.2-1992 en Single UNIX-specificatie (www.opengroup.org/press/14nov02.htm).

Nationaal Instituut voor Standaarden en Technologie (NIST) is een federaal agentschap binnen de Technology Administration van het Commerce Department (www.nist.gov/public_affairs/general2.htm), opgericht in de VS in 1901. De missie van NIST is het ontwikkelen en promoten van standaarden en technologieën om de productkwaliteit te verbeteren. NIST omvat een laboratorium voor informatietechnologie (I- ITL), een van de resultaten hiervan is de Federal Information Processing Standards (FIPS, www.opengroup.org/testing/fips/general_info.html). NIST/ITL stelde in 1991 de eerste reeks tests voor POSIX-certificering voor onder FIPS PUB 151-. 1 1990.

Wat is POSIX?

Formeel de term POSIX voorgesteld door Richard Stallman als afkorting voor P ortabel O perating S systeeminterface voor un IX(draagbare besturingssysteeminterface voor Unix). POSIX is ontwikkeld voor UNIX-achtige besturingssystemen (de eerste versies dateren uit het begin van de jaren zeventig) met als doel de portabiliteit van applicaties op bronniveau te garanderen.

De eerste beschrijving van de interface werd gepubliceerd in 1986 en heette toen IEEE-IX (IEEE's versie van UNIX). De naam veranderde echter snel in POSIX en de volgende publicatie (in 1986) gebruikte deze nieuwe variant. POSIX werd enige tijd opgevat als een verwijzing (of synoniem) naar de groep gerelateerde documenten IEEE 1003.1-1988 en delen van ISO/IEC 9945, en als een volledige en goedgekeurde internationale norm werd ISO/IEC 9945.1:1990 POSIX aangenomen. in 1990. De POSIX-specificaties definiëren het standaardmechanisme voor interactie tussen een applicatieprogramma en het besturingssysteem en omvatten momenteel meer dan 30 standaarden onder auspiciën van IEEE, ISO, IEC en ANSI.

POSIX heeft in de loop van zijn geschiedenis een lange weg afgelegd, met talloze veranderingen in de aanduiding van specificaties, hun specifieke inhoud, de procedures en de logistiek voor het testen ervan. In de loop van de tijd zijn er binnen verschillende internationale organisaties verschillende edities van de POSIX-standaard uitgebracht.

Geschiedenis van de ontwikkeling van de POSIX-standaard

De eerste versie van de IEEE Std 1003.1-specificatie werd gepubliceerd in 1988. Vervolgens zijn talloze edities van IEEE Std 1003.1 aangenomen als internationale standaarden. POSIX-ontwikkelingsfasen:

- 1990 De in 1988 uitgebrachte editie werd herzien en werd de basis voor verdere edities en toevoegingen. Het is goedgekeurd als internationale norm door ISO/IEC 9945-1:1990.

- 1993 Revisie 1003.1b-1993 is uitgebracht.

- 1996 IEEE Std 1003.1b-1993, IEEE Std 1003.1c-1995 en 1003.1i-1995 zijn gewijzigd, maar de hoofdtekst van het document blijft ongewijzigd. De editie uit 1996 van IEEE Std 1003.1 werd ook als internationale norm aangenomen door ISO/IEC 9945-1:1996.

- 1998 De eerste standaard voor "real time" verscheen - IEEE Std 1003.13-1998. Het is een uitbreiding van de POSIX-standaard voor embedded real-time toepassingen.

- 1999 Er werd besloten om de eerste significante wijzigingen in de afgelopen 10 jaar aan te brengen in de hoofdtekst van de standaard, inclusief fusie met standaard 1003.2 (Shell en nutsvoorzieningen), aangezien dit destijds afzonderlijke standaarden waren. PASC besloot de wijzigingen in de basistekst af te ronden nadat de IEEE 1003.1a, 1003.1d, 1003.1g, 1003.1j, 1003.1q en 1003.2b standaarden waren voltooid.

- 2004 De laatste herziening van de 1003.1-standaard tot nu toe werd op 30 april gepubliceerd en uitgebracht onder auspiciën van de Austin Common Standards Revision Group. Het is gewijzigd door de editie van 2001 van de standaard. Formeel staat de editie van 2004 bekend als IEEE Std 1003.1, 2004 Edition, The Open Group Technical Standard Base Specifications, Issue 6 en omvat IEEE Std 1003.1-2001, IEEE Std 1003.1-2001/. Cor 1-2002 en IEEE Std 1003.1-2001/Cor 2-2004.

De belangrijkste POSIX-standaarden voor RT OS

Voor real-time besturingssystemen zijn zeven standaardspecificaties het belangrijkst, maar slechts drie ervan hebben brede steun gekregen in commerciële besturingssystemen:

1003.1a (OS-definitie) definieert de belangrijkste OS-interfaces, taakcontrole, signalen, bestandssysteem- en apparaatfuncties, gebruikersgroepen, pijplijnen, FIFO-buffers;

1003.1b (Realtime Extensions) beschrijft real-time uitbreidingen zoals real-time signalen, prioriteitsplanning, timers, synchrone en asynchrone I/O, semaforen, gedeeld geheugen, berichten. Deze standaard heette oorspronkelijk (tot 1993) POSIX.4;

1003.1c (Threads) definieert ondersteunende functies voor threads (threads) - threadbeheer, threadattributen, mutexen, verzending. Oorspronkelijk aangeduid als POSIX.4a.

Naast deze standaarden zijn de volgende standaarden belangrijk voor het RT OS, die zijn geïmplementeerd als onderdeel van het werk aan het Std 1003.1-2001-project:

IEEE 1003.1d-1999. Extra realtime uitbreidingen. Oorspronkelijk aangeduid als POSIX.4b;

IEEE 1003.1j-2000. Verbeterde (geavanceerde) real-time extensies;

IEEE 1003.1q-2000. Spoor.

Certificatieprocedure

Om aan de POSIX-standaard te voldoen, moet het besturingssysteem worden gecertificeerd volgens de resultaten van de juiste testsuite. Sinds de introductie van POSIX heeft de testsuite formele en feitelijke veranderingen ondergaan.

In 1991 ontwikkelde NIST het POSIX-testprogramma als onderdeel van FIPS 151-1 (http://standards.ieee.org/regauth/posix/POSIX-A.FM5.pdf). Deze testoptie was gebaseerd op IEEE 1003.3 "Standaard voor testmethoden voor het meten van conformiteit met POSIX" Draft 10, 3 mei 1989. In 1993 voltooide NIST het POSIX-testprogramma voor FIPS 151-1 en begon het programma voor FIPS 151 -2 (www.itl.nist.gov/fipspubs/fip151-2.htm).FIPS 151-2 heeft "Informatietechnologie - Portable Operating System Interface (POSIX) - Deel 1: System Application Program Interface (API)" aangepast, welke ISO/ IEC 9945-1:1990-norm. Testsuites voor FIPS 151-2 waren gebaseerd op IEEE 2003.1-1992 "Standaard voor testmethoden voor het meten van conformiteit met POSIX".

NIST maakt onderscheid tussen twee certificeringsmethodieken: zelfcertificering en certificering door IEEE geaccrediteerde POSIX Testing Laboratories (APTL). In het eerste geval voert het bedrijf de tests onafhankelijk uit, maar volgens een door NIST goedgekeurd plan. In het tweede geval worden de tests uitgevoerd door een onafhankelijk laboratorium met behulp van geautomatiseerde testkits. In totaal zijn er twee APTL-laboratoria geaccrediteerd: Mindcraft (www.mindcraft.com) en Perennial (www.peren.com).

In 1997 kondigde NIST/ITL het voornemen aan om de FIPS 151-2-certificering aan het einde van het lopende jaar (officieel 31 december 1997) stop te zetten, terwijl de Open Group aankondigde dat het van plan was de certificering per 1 oktober 1997 over te nemen. hetzelfde jaar certificeringsdienst conform FIPS 151-2, gebaseerd op het NIST/ITL-programma. Dezelfde functies werden op 1 januari 1998 overgenomen door de IEEE Standards Association (IEEE-SA), eveneens gebaseerd op FIPS 151-2.

In 2003 kondigden IEEE-SA en de Open Group de start aan van een nieuw gezamenlijk programma om de nieuwste versies van POSIX te certificeren, te beginnen met IEEE 1003.1 (tm) 2001. De Open Group beschikt nu over verschillende testsuites die IEEE Std 1003.1-1996 dekken. , IEEE-standaard 1003.

2-1992, IEEE Std 1003.1-2003 en IEEE Std 1003.13-1998 (www.opengroup.org/testing/testsuites/posix.html). Een product wordt als POSIX-gecertificeerd beschouwd als het de volledige certificeringsprocedure heeft doorlopen, aan alle eisen op basis van testresultaten voldoet en is opgenomen in het officiële register van gecertificeerde producten.

Testsuites omvatten:

VSX-PCTS1990 (www.opengroup.org/testing/testsuites/vsxpcts1990.htm) - een reeks conformiteitstests voor systeeminterfaces IEEE Std 1003.1-1990;

VSPSE54 (www.opengroup.org/testing/testsuites/VSPSE54.htm) - een reeks conformiteitstests voor IEEE Std 1003.13-1998 Profiel PSE54 (multifunctioneel realtime);

VSX-PCTS2003 (www.opengroup.org/testing/testsuites/vsxpcts2003.htm) - een reeks conformiteitstests voor systeeminterfaces IEEE Std 1003.1-2003 (alleen verplichte onderdelen);

VSC-PCTS2003 (www.opengroup.org/testing/testsuites/vscpcts2003.htm) - een reeks conformiteitstests voor IEEE Std 1003.1-2003 (shell en hulpprogramma's - alleen verplichte onderdelen).

Daarnaast heeft de Open Group tests ontwikkeld voor de POSIX Realtime standaarden en het Embedded POSIX standaardenprofiel. De POSIX Realtime-testsuite (www.opengroup.org/testing/testsuites/realtime.html) bevat de volgende tests:

IEEE POSIX 1003.1b-1993/1003.1i-1995 Realtime-extensie en IEEE POSIX 1003.1,2003 editie;

IEEE Std POSIX 1003.1c-1995 Threads (pthreads) -extensie en IEEE POSIX 1003.1,2003 editie;

IEEE POSIX 1003.1d-1999 aanvullende realtime-extensie en IEEE POSIX 1003.1,2003 editie;

IEEE POSIX 1003.1j-2000 Advanced Realtime Extension en IEEE POSIX 1003.1,2003 editie;

IEEE POSIX 1003.1q-2000 Trace en IEEE POSIX 1003.1,2003 editie en IEEE POSIX 1003.1,2003 editie;

De Embedded POSIX-standaardprofieltestsuite (www.opengroup.org/testing/testsuites/embedded.html) bevat de volgende tests:

IEEE POSIX 1003.1-1990 (5310 tests);

IEEE POSIX 1003.1b-1993/1003.1i-1995 Realtime-extensie (1430 tests);

IEEE Std POSIX 1003.1c-1995 Threads (pthreads)-extensie (1232 tests);

IEEE POSIX 1003.13-1998 Profiel 52.

Een beetje over verwarring in terminologie

Met betrekking tot de POSIX-standaardgroep worden in het Engels vaak niet één, maar drie termen gebruikt. Helaas hebben ze dezelfde betekenis en worden ze vaak op dezelfde manier vertaald, wat voor enige verwarring zorgt. Deze voorwaarden zijn:

Compatibiliteit (letterlijk - "compatibiliteit");

Сompliance (letterlijk - “compliance”);

Сonformance (letterlijk “consistentie”).

De eerste term, zoals toegepast op POSIX, is niet formeel gedefinieerd. De tweede houdt in dat de organisatie die het softwareproduct produceert, onafhankelijk verklaart dat dit product (geheel of gedeeltelijk) voldoet aan de genoemde NIST-PCTS-standaarden. De derde term houdt in dat het softwareproduct een vastgesteld testsysteem heeft doorstaan, hetzij met de hulp van een geaccrediteerd laboratorium, hetzij binnen de Open Group, en dat daar schriftelijk bewijs van is (de zogenaamde conformiteitsverklaring). Verderop in de tekst van het artikel zullen overal de originele termen worden vermeld om dubbelzinnigheid weg te nemen.

Gecertificeerde OS RV

Als u zich houdt aan strikte regels die vereisen dat gegevens over een gecertificeerd RT-besturingssysteem worden gepubliceerd in het officiële register en dat tests worden uitgevoerd op basis van het niveau conformiteit, dan zijn er momenteel slechts twee gecertificeerde RT-besturingssystemen (gegevens worden in chronologische volgorde gegeven):

- LynxOS v.3(een product van Lynx Real-Time Systems, nu LynuxWorks, Inc., www.lynuxworks.com genoemd) is bedoeld voor de ontwikkeling van harde realtime ingebedde systeemsoftware door OEM's en fabrikanten van telecommunicatieapparatuur, met name fabrikanten van militaire luchtlandingssystemen. Ontwikkeling kan zowel op het doelsysteem zelf (self-hosted) als op een instrumentele computer (host) worden uitgevoerd, er wordt kant-en-klare software ontworpen om op het doelsysteem (target) te werken. LynxOS v.3 is gecertificeerd voor consistentie (conformiteit) POSIX-standaard op Intel- en PowerPC-platforms. Informatie hierover kunt u vinden op de IEEE-website http://standards.ieee.org/regauth/posix/posix2.html LynxOS is gecertificeerd volgens POSIX 1003.1-1996 door Mindcraft, een IEEE POSIX geaccrediteerd POSIX-testlaboratorium voor de NIST FIPS. 151-testsuite 2 Conformiteitstestsuite. Certificeringsdocumentnummer: Referentiebestand: IP-2LYX002, Referentiebestand: IP-2LYX001.

- INTEGRITEIT v.5(product van Green Hills Software, www.ghs.com) gecertificeerd voor consistentie (conformiteit) naar POSIX 1003.1-2003, Systeeminterfaces voor de PowerPC-architectuur in juli 2004 (http://get.posixcertified.ieee.org/select_product.tpl). VSX-PCTS 2003-testsuite.

POSIX en het QNX-besturingssysteem

QNX v.4.20(ontwikkeld door QNX Software Systems, www.qnx.com) gecertificeerd voor naleving (naleving) naar POSIX 1003.1-1988 voor het Intel-platform van DataFocus Incorporated. De tests werden uitgevoerd op 13 september 1993 en het document werd uitgegeven op 1 november 1993. NIST PCTS 151-1 Test Suite, versie 1.1.

QNX Neutrino (versie 6.3) voldoet aan de volgende POSIX-familiestandaarden (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 Software Systems, de maker van QNX Neutrino, is ook van plan om QNX Neutrino aan een aantal van deze standaarden te conformeren; de werkzaamheden zijn gepland voor 2005 (www.qnx.com/news/pr_959_1.html).

Literatuur

1. Bedieningshandleiding van de IEEE Standards Association. IEEE, oktober 2004.

2. Kevin M.Obeland. POSIX in realtime, ingebedde systeemprogrammering, 2001.

3. IEEE/ANSI-standaard 1003.1: Informatietechnologie - (POSIX) - Deel 1: Systeemtoepassing: Programma-interface (API).

4. Gallmeister B.O. Programmeren voor de echte wereld, POSIX.4 Sebastopol, CA: O'Reilly & Associates, 1995.

5. Nationaal Instituut voor Standaarden en Technologie, PCTS:151-2, POSIX Test Suite.

6. POSIX: Gecertificeerd door IEEE en The Open Group. Gecertificeerd beleid. The Open Group, 21 oktober 2003, herziening 1.1.

De naam werd voorgesteld door de beroemde specialist, oprichter van de Free Software Foundation, Richard Stallman.

De geschiedenis van de creatie van deze versie is als volgt. Begin 1998 hebben vertegenwoordigers van drie organisaties – het Mobile Application Standards Committee van het Institute of Electrical and Electronics Engineers, de Open Group en het Joint Technical Committee 1 Subcommittee 22 Working Group 15 (JTC1/SC22/WG15) van de International Standards Organization – begon overleg over de fusie en de ontwikkeling van interfacestandaarden voor systeemdiensten onder toezicht van hen: IEEE Std 1003.1, IEEE Std 1003.2, basisspecificaties van de Open Group, ISO / IEC 9945-1, ISO / IEC 9945-2. In september van hetzelfde jaar werd in Austin, Texas, een organisatorische bijeenkomst gehouden van de groep die was gevormd om dit doel te bereiken, op het kantoor van IBM Corporation (zie http://www.opengroup.org/austin).

Het basisdocument voor de herziene norm, waarvan het eerste ontwerp in juli 1999 werd ingediend, waren de kernspecificaties van de Open Group, aangezien deze bepalingen uit de IEEE- en ISO/IEC-normen bevatten. In 2001, na voltooiing van het voorbereidende werk, bestond de standaard uit de volgende vier delen:

1. basisdefinities (termen, concepten en interfaces die voor alle onderdelen gelden);
2. beschrijving C-applicatieprogrammeerinterface naar systeemdiensten;
3. beschrijving van de interface met systeemdiensten op niveau commando taal En nutsvoorzieningen ;
4. gedetailleerde uitleg van de bepalingen van de norm, motivering voor genomen beslissingen.

Verder hebben ISO, IEEE en de Open Group, met grotere of kleinere snelheid (in 2001-2002), de nieuwe POSIX-standaard formeel goedgekeurd. Intussen stapelden zich relatief kleine correcties op, waarmee in de editie van 2003 rekening werd gehouden.

Naarmate de standaard zich ontwikkelde, breidde de interpretatie van de term "POSIX" zich uit. Oorspronkelijk verwees het naar IEEE Std 1003.1-1988, waarin wordt beschreven applicatie-programmeerinterface Unix-klasse besturingssysteem. Na standaardisatie van de interface op het niveau van de commandotaal en hulpprogramma's, is het juister om het woord "POSIX" als een standaard als geheel te begrijpen, waarbij de bovenstaande delen 2 en 3 tot en met POSIX.1 en POSIX.2 worden aangeduid in overeenstemming met de nummering van IEEE- en ISO/IEC-documenten.

Basisideeën van de POSIX-standaard

De POSIX-standaard beschrijft veel basissysteemdiensten die nodig zijn voor het functioneren van applicatieprogramma's. Ze zijn toegankelijk via een interface die is gespecificeerd voor de C-taal, een opdrachttaal en algemene hulpprogramma's.

Elke interface heeft twee kanten: de beller en de gebelde. De POSIX-standaard is bellergericht. Het doel is om aanvragen te doen mobiel op brontaalniveau. Dit betekent met name dat bij het verplaatsen van C-programma's naar een ander besturingssysteem hercompilatie nodig zal zijn. Er wordt niet gesproken over de mobiliteit van uitvoerbare programma's en/of objectbestanden.

De POSIX-standaard is geenszins beperkt tot de Unix-omgeving. Er zijn besturingssystemen (OS) van "onafhankelijke oorsprong" (bijvoorbeeld realtime systemen), het leveren van de nodige diensten en het ondersteunen van de uitvoering van POSIX-compatibele applicaties. Er kan worden gesteld dat het volgen van de POSIX-standaard het gemakkelijker maakt om applicaties over te zetten naar vrijwel elk veelgebruikt besturingssysteem. De extra inspanning die tijdens de ontwikkelingsfase wordt gestoken in het verbeteren van de mobiliteit zal zeker vruchten afwerpen.

Door de interface met systeemdiensten te definiëren, laat POSIX de implementatie ervan buiten beschouwing. In het bijzonder verschillen ze niet systeemoproepen En bibliotheek functies. Producten zijn niet onderworpen aan standaardisatie administratie , hardwarebeperkingen en alleen vereiste functies supergebruiker

, wat nogmaals de focus van de standaard benadrukt
Onderwerp: besturingssystemen.

—————————————————————

Vraag: Nr. 8

1.) Ontwerpprincipes van het besturingssysteem: Modulariteitsprincipe

– in het algemeen wordt een module opgevat als een functioneel compleet element van het systeem, gemaakt in overeenstemming met geaccepteerde intermodulaire interfaces. Per definitie gaat een module ervan uit dat deze gemakkelijk door een andere kan worden vervangen als de gespecificeerde interfaces beschikbaar zijn. De indeling van het systeem in modules wordt voor een groot deel bepaald door de gebruikte OS-ontwerpmethode (bottom-up of andersom).

Van bijzonder belang bij het bouwen van een besturingssysteem zijn geprivilegieerde, herintredende en herintredende modules (reentrant - letterlijk herintredend; een speciale term om de bruikbaarheid van een programma aan te duiden; de eigenschap van een programma dat correct moet worden uitgevoerd wanneer het recursief wordt aangeroepen (teruggestuurd) vanuit een interrupt) .

2.) Het grootste effect van het gebruik van dit principe is haalbaar als dit principe gelijktijdig wordt gedistribueerd naar het besturingssysteem, applicatieprogramma's en hardware.– het besturingssysteem wijst een bepaald deel van belangrijke modules toe die permanent in het RAM moeten worden geplaatst voor een efficiëntere organisatie van het computerproces. Dit deel van het besturingssysteem wordt de kernel genoemd, omdat het de basis van het systeem vormt. Bij het vormen van de samenstelling van de kern moet rekening worden gehouden met twee tegenstrijdige eisen. Enerzijds moet de kernel de meest gebruikte systeemmodules bevatten, anderzijds moet het aantal modules zodanig zijn dat de hoeveelheid geheugen die door de kernel wordt ingenomen niet te groot is. Naast de programmamodules die deel uitmaken van de kernel en zich permanent in het RAM bevinden, kunnen er nog vele andere systeemprogrammamodules zijn, die worden genoemd doorvoer. Transit-programmamodules worden alleen in het RAM geladen als dat nodig is en kunnen, als er geen vrije ruimte is, worden vervangen door andere transitmodules.

3.) Principe voor het genereren van besturingssystemen: De essentie van het principe is het organiseren (selecteren) van een dergelijke methode voor de initiële weergave van het centrale systeembesturingsprogramma van het besturingssysteem (de kernel en de hoofdcomponenten die zich permanent in RAM bevinden), waardoor het mogelijk werd dit systeemtoezichtgedeelte te configureren gebaseerd op de specifieke configuratie van een bepaald computercomplex en het scala aan taken dat moet worden opgelost. Deze procedure wordt zelden uitgevoerd vóór een vrij lange periode van gebruik van het besturingssysteem. Het generatieproces wordt uitgevoerd met behulp van een speciaal generatorprogramma en de bijbehorende invoertaal voor dit programma, waarmee u de softwaremogelijkheden van het systeem en de configuratie van de machine kunt beschrijven. Als resultaat van de generatie wordt een volledige versie van het besturingssysteem verkregen. De gegenereerde besturingssysteemversie is een verzameling systeemsets met modules en gegevens.

4.) Het principe van functionele redundantie: Dit principe houdt rekening met de mogelijkheid om hetzelfde werk met verschillende middelen uit te voeren. Het besturingssysteem kan verschillende soorten monitoren bevatten (supervisormodules die een of ander type bron beheren), verschillende manieren om de communicatie tussen computerprocessen te organiseren. De aanwezigheid van verschillende soorten monitoren en verschillende bestandsbeheersystemen stelt gebruikers in staat het besturingssysteem snel en adequaat aan te passen aan een specifieke computersysteemconfiguratie, te zorgen voor de meest efficiënte belasting van hardware bij het oplossen van een specifieke klasse van problemen, en maximale prestaties te verkrijgen bij het oplossen van problemen. een bepaalde klasse van problemen.

5.) Principe van virtualisatie: de constructie van virtuele bronnen, hun distributie en gebruik wordt momenteel in vrijwel elk besturingssysteem gebruikt. Met dit principe kunt u de structuur van het systeem presenteren in de vorm van een bepaalde reeks procesplanners en resourcetoewijzers (monitors) en één enkel gecentraliseerd schema gebruiken voor de distributie van resources.

De meest natuurlijke en volledige manifestatie van het concept van virtualiteit is het concept virtuele machine. De virtuele machine die aan de gebruiker wordt aangeboden, reproduceert de architectuur van de echte machine, maar de architectonische elementen in deze weergave verschijnen met nieuwe of verbeterde kenmerken, waardoor het werken met het systeem doorgaans wordt vereenvoudigd. De kenmerken kunnen willekeurig zijn, maar meestal willen gebruikers hun eigen “ideale” machine hebben in termen van architectonische kenmerken, bestaande uit het volgende:

— virtueel geheugen met vrijwel onbeperkte capaciteit, uniform in bedieningslogica.

— een willekeurig aantal virtuele processors die tijdens bedrijf parallel kunnen werken en met elkaar kunnen communiceren.

— een willekeurig aantal externe virtuele apparaten die parallel of sequentieel, asynchroon of synchroon met het geheugen van een virtuele machine kunnen werken met betrekking tot de werking van een bepaalde virtuele processor die de werking van deze apparaten initieert.

Een van de aspecten van virtualisatie is de organisatie van de mogelijkheid om applicaties op een bepaald besturingssysteem uit te voeren die voor andere besturingssystemen zijn ontwikkeld. Met andere woorden, we hebben het over het organiseren van verschillende besturingsomgevingen.

6.) Het principe van programma-onafhankelijkheid van externe apparaten: Dit principe wordt nu geïmplementeerd in de overgrote meerderheid van algemene besturingssystemen. Voor het eerst werd dit principe het meest consistent geïmplementeerd in het UNIX-besturingssysteem. Het is ook geïmplementeerd in de meeste moderne pc-besturingssystemen. Dit principe ligt in het feit dat de verbinding van programma's met specifieke apparaten niet wordt uitgevoerd op het niveau van programmavertaling, maar tijdens de planningsperiode voor de uitvoering ervan. Als gevolg hiervan is hercompilatie niet vereist wanneer het programma wordt uitgevoerd op een nieuw apparaat waarop de gegevens zich bevinden.

7.) Compatibiliteitsprincipe: Eén aspect van compatibiliteit is de mogelijkheid van een besturingssysteem om programma's uit te voeren die zijn geschreven voor andere besturingssystemen of voor eerdere versies van een bepaald besturingssysteem, maar ook voor een ander hardwareplatform. Het is noodzakelijk om de vragen te scheiden binaire compatibiliteit En compatibiliteit op bronniveau toepassingen.

Binaire compatibiliteit wordt bereikt wanneer u een uitvoerbaar programma kunt gebruiken en dit op een ander besturingssysteem kunt uitvoeren. Dit vereist compatibiliteit op het niveau van de processorinstructie, en compatibiliteit op het niveau van de systeemaanroep, en zelfs op het niveau van de bibliotheekaanroep als ze dynamisch gekoppeld zijn.

Compatibiliteit op bronniveau vereist de aanwezigheid van een geschikte vertaler als onderdeel van de systeemsoftware, evenals compatibiliteit op het niveau van bibliotheken en systeemaanroepen. In dit geval is het noodzakelijk om de bestaande bronteksten opnieuw te compileren in een nieuwe uitvoerbare module.

Het is veel moeilijker om binaire compatibiliteit te bereiken tussen processors op basis van verschillende architecturen. Om ervoor te zorgen dat de ene computer de programma's van een andere computer kan uitvoeren (het is bijvoorbeeld raadzaam om een ​​programma voor een pc zoals een IBM-pc uit te voeren op een pc zoals een Apple Macintosh), moet deze computer werken met machine-instructies die in eerste instantie zijn onbegrijpelijk voor. In dit geval moet een 680x0-processor (of PowerPC) binaire code uitvoeren die is ontworpen voor een i80x86-processor. De 80x86 processor heeft zijn eigen instructiedecoder, registers en interne architectuur. Een 680x0-processor begrijpt de binaire code 80x86 niet, dus moet hij elke instructie ophalen en decoderen om te bepalen welke

waarvoor het bedoeld is, en voer vervolgens de equivalente routine uit die is geschreven voor 680x0.

Een van de manieren om de compatibiliteit van programma- en gebruikersinterfaces te garanderen, is naleving van POSIX-standaarden, waarvan u gebruik kunt maken van UNIX-achtige programma's die gemakkelijk van het ene systeem naar het andere kunnen worden overgedragen.

8.) Het principe van openheid en schaalbaarheid: Er is een open besturingssysteem beschikbaar voor analyse door zowel gebruikers als systeemspecialisten die het computersysteem onderhouden. Met een uitbreidbaar (aangepast, ontwikkeld) besturingssysteem kunt u niet alleen generatiemogelijkheden gebruiken, maar ook nieuwe modules in de samenstelling introduceren, bestaande verbeteren, enz. Met andere woorden: het moet mogelijk zijn om eenvoudig toevoegingen en wijzigingen aan te brengen wanneer dat nodig is, zonder de integriteit van het systeem in gevaar te brengen. Uitstekende uitbreidingsmogelijkheden worden geboden door de client-server-benadering voor het structureren van het besturingssysteem met behulp van microkerneltechnologie. In overeenstemming met deze benadering is het besturingssysteem gebouwd als een reeks bevoorrechte besturingsprogramma's en een reeks niet-bevoorrechte services (servers). Het grootste deel van het besturingssysteem blijft ongewijzigd, terwijl er nieuwe servers kunnen worden toegevoegd of oude kunnen worden verbeterd. Dit principe wordt soms geïnterpreteerd als uitbreidbaarheid van het systeem.

9.) Mobiliteitsprincipe: het besturingssysteem zou relatief eenvoudig te porten moeten zijn

overdracht van een processor van het ene type naar een processor van een ander type en van een hardwareplatform van het ene type, dat, naast het type processor, de methode omvat voor het organiseren van alle computerhardware (computersysteemarchitectuur), naar een hardwareplatform van een ander soort. Merk op dat het beginsel van draagbaarheid zeer dicht bij het beginsel van compatibiliteit ligt, ook al zijn ze niet hetzelfde. Het maken van een draagbaar besturingssysteem is vergelijkbaar met het schrijven van draagbare code, maar u moet er enkele volgen regels:

— het grootste deel van het besturingssysteem moet worden uitgevoerd in een taal die beschikbaar is op alle systemen waarnaar het in de toekomst zal worden overgebracht. Dit betekent in de eerste plaats dat het besturingssysteem in een taal op hoog niveau moet worden geschreven, bij voorkeur een gestandaardiseerde taal, zoals C. Een programma dat in assembleertaal is geschreven, is over het algemeen niet overdraagbaar.

- Het is belangrijk om die delen van de code die rechtstreeks in wisselwerking staan ​​met de hardware te minimaliseren of, indien mogelijk, te elimineren. Hardwareafhankelijkheid kan vele vormen aannemen. Enkele voor de hand liggende vormen van afhankelijkheid omvatten directe manipulatie van registers en andere hardware. Als ten slotte hardware-afhankelijke code niet volledig kan worden geëlimineerd, moet deze worden geïsoleerd in verschillende goed gelokaliseerde modules. Hardware-afhankelijke code mag niet door het hele systeem worden verspreid. U kunt bijvoorbeeld een apparaatafhankelijke structuur verbergen in programmagedefinieerde gegevens van een abstract type.

De introductie van POSIX-standaarden was bedoeld om de draagbaarheid van de software die werd gemaakt te garanderen.

10.) Computerbeveiligingsprincipe: Het garanderen van veiligheid bij het uitvoeren van berekeningen is een wenselijke eigenschap voor elk multi-user systeem. Beveiligingsregels definiëren eigenschappen zoals het beschermen van de bronnen van een gebruiker tegen anderen en het instellen van resourcequota om te voorkomen dat één gebruiker alle systeembronnen, zoals geheugen, overneemt.

Het waarborgen van de bescherming van informatie tegen ongeoorloofde toegang is een verplichte functie van netwerkbesturingssystemen.

—————————————————————

Wat is er gebeurdPOSIX: platformonafhankelijke systeeminterface voor computeromgevingen POSIX (Portable Operating System Interface for Computer Environments) is een IEEE-standaard (Institute of Electrical and Electronics Engineers) die systeeminterfaces beschrijft voor open besturingssystemen, inclusief shells, hulpprogramma's en toolkits. Bovendien zijn volgens POSIX beveiligingstaken, realtime taken, administratieve processen, netwerkfuncties en transactieverwerking gestandaardiseerd. De standaard is gebaseerd op UNIX-systemen, maar kan ook in andere besturingssystemen worden geïmplementeerd. POSIX is ontstaan ​​als een poging van het wereldberoemde IEEE om de portabiliteit van applicaties in UNIX-omgevingen te bevorderen door een abstracte, platformonafhankelijke standaard te ontwikkelen. Zo voldoet het bekende QNX real-time OS aan de specificaties van deze standaard.

Deze standaard beschrijft in detail het virtuele geheugensysteem VMS (Virtual Memory System), multitasking MPE (Multi-Process Executing) en technologie voor het overbrengen van besturingssystemen CTOS (Een besturingssysteem geproduceerde Convergent Technology ...). POSIX is dus eigenlijk een reeks standaarden genaamd POSIX.I tot en met POSIX.12. Er moet ook vooral worden opgemerkt dat POSIX.1 C als de hoofdtaal aanneemt

taal voor het beschrijven van systeem-API-functies.

Programma's die volgens deze standaarden zijn geschreven, zullen dus hetzelfde draaien op alle POSIX-compatibele systemen. In sommige gevallen heeft de norm echter slechts een adviserend karakter. Sommige normen zijn zeer strikt beschreven, terwijl andere slechts oppervlakkig de basisvereisten onthullen.

Implementaties van de POSIX API op besturingssysteemniveau variëren. Hoewel de overgrote meerderheid van UNIX-systemen aanvankelijk voldoet aan de IEEE Standard 1003.1-1990-specificaties, is WinAPI niet POSIX-compatibel. Om deze standaard te ondersteunen heeft het MS Windows NT-besturingssysteem echter een speciale POSIX API-ondersteuningsmodule geïntroduceerd die werkt op het privilegeniveau van gebruikersprocessen.

Deze module biedt conversie en overdracht van oproepen van een gebruikersprogramma naar de systeemkernel en terug, waarbij met de kernel wordt gewerkt via de Win API. Andere applicaties die met WinAPI zijn gebouwd, kunnen informatie doorgeven aan POSIX-applicaties via standaard I/O-streammechanismen (stdin, stdout).

Er zijn geen soortgelijke berichten...

POSIX (portable operating system interface) is een standaard die de interface beschrijft tussen een besturingssysteem en een applicatieprogramma. Het doel van het creëren van deze standaard is om de compatibiliteit van Unix-achtige besturingssystemen te garanderen, evenals de portabiliteit van programma's op broncodeniveau. De POSIX-standaard kan echter niet alleen door Unix-systemen worden gebruikt. De naam POSIX werd voorgesteld door Richard Stallman. Uitgesproken als "poix" is de interface voor draagbare Unix-besturingssystemen.

Een beetje geschiedenis

De eerste versie van de POSIX-standaard was IEEE Std 1003. Deze werd uitgebracht in 1988 en definieerde de interface tussen de programmeertaal C en de kernelshell van Unix-achtige systemen.

In 1990 werd een nieuwe versie van IEEE Std 1003.2 uitgebracht. In het nieuwe document zijn ten opzichte van de eerste versie kleine wijzigingen aangebracht.

In 1992 werd de tweedelige IEEE Std 1003.2-standaard uitgebracht. Het document beschreef een opdrachttolk en meer dan honderd hulpprogramma's.

De volgende versie, uitgebracht in 1993, werd een kleine toevoeging aan eerdere versies: er verscheen informatie over bestandssynchronisatie, semaforen, tijdinstellingen, timer, berichtenwachtrij, asynchrone I/O.

In 1995 werd een andere standaard voor streams uitgebracht, en het versiedocument uit 1996 was een soort aanvulling op eerdere versies.

De POSIX-standaard uit 1999 beschreef aanvullende realtime-uitbreidingen.

In 2001 werd een standaard uitgebracht die alle voorgaande versies verenigde. Er werd besloten om het als basis te gebruiken voor de adoptie van standaarden in de toekomst.

Er wordt gebruik gemaakt van de huidige versie van POSIX.1, goedgekeurd in 2008.

Basisideeën van de POSIX-standaard

Volgens gedocumenteerde bepalingen moet het besturingssysteem voor een correcte interactie met applicaties de volgende componenten hebben:

• netwerkhulpmiddelen;
• ontwikkelingshulpmiddelen;
• controlestromen;
• realtime hulpmiddelen;
• pakketdiensten;
• header-bestanden;
• wiskundige interfaces;
• oudere interfaces.

Kenmerken van besturingssystemen die voldoen aan POSIX-standaarden

• differentiatie van de rechten van gebruikers en groepen, evenals de superuser-root met bevoorrechte rechten;
• de aanwezigheid van een boomachtig bestandssysteem met een enkele root /;
• de systeem- en softwarepakketten worden geleverd als tekstbestanden - dat wil zeggen dat bestandsconfiguraties kunnen worden gewijzigd door eenvoudige bewerking;
• Unified C-programmeer-API;
• één enkele standaard voor consolehulpprogramma's en -opdrachten (POSIX 2).

Besturingssystemen die zijn gecertificeerd volgens de POSIX-standaard zijn onder meer: ​​IBM AIX, UnixWare, Solaris, IRIX, QNX, LynxOS, Mac OS X. Besturingssystemen zoals Minix, verschillende uitlopers van BSD, OpenSolaris, VxWorks en OpenWMS zijn volledig compatibel met een van de versies van de POSIX-standaard. Wat Linux-distributies betreft, voldoen de meeste aan de LSB-standaard (Linux Standard Base), die op zijn beurt is gebaseerd op POSIX.

De grote verschillen in RTOS-specificaties en het enorme aantal bestaande microcontrollers brengen het probleem van standaardisatie op het gebied van real-time systemen naar voren.

De vroegste en meest wijdverbreide RTOS-standaard is de POSIX-standaard (IEEE Portable Operating System Interface for Computer Environments, IEEE 1003.1). De originele versie van de POSIX-standaard verscheen in 1990 en was bedoeld voor UNIX-systemen, waarvan de eerste versies in de jaren 70 van de vorige eeuw verschenen. De POSIX-specificaties definiëren een standaardmechanisme voor interactie tussen een applicatieprogramma en het besturingssysteem en omvatten momenteel een reeks van meer dan 30 standaarden. Voor RTOS zijn er zeven de belangrijkste (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21, 1003.2h), maar alleen de eerste drie kregen brede steun in commerciële besturingssystemen.

Ondanks de duidelijk verouderde bepalingen van de POSIX-standaard en de grote vraag naar standaardisatie-updates voor RTOS, is er geen merkbare vooruitgang in deze richting.

De POSIX-standaard is gemaakt als standaardinterface voor besturingssysteemservices. Deze standaard maakt het mogelijk om draagbare applicaties te creëren. Deze standaard werd vervolgens uitgebreid met realtime functies.

De POSIX-specificaties definiëren een standaardmechanisme voor interactie tussen een applicatie en het besturingssysteem. Opgemerkt moet worden dat de POSIX-standaard nauw verwant is aan het Unix-besturingssysteem, maar de ontwikkelaars van veel RTOS's proberen aan deze standaard te voldoen.

Naleving van de POSIX-standaard voor het besturingssysteem en hardwareplatform moet worden gecertificeerd door er testcases op uit te voeren. Als het besturingssysteem echter niet Unix-achtig is, wordt het voldoen aan deze vereiste een uitdaging. Testsuites bestaan ​​alleen voor POSIX 1003.1a. Omdat het POSIX-framework een verzameling optionele functies is, kunnen leveranciers van besturingssystemen slechts een deel van de standaardinterface implementeren en toch beweren dat hun systeem POSIX-compatibel is.

Hoewel de POSIX-standaard uit Unix is ​​voortgekomen, behandelt deze de fundamentele abstracties van besturingssystemen, en zijn de real-time uitbreidingen van toepassing op alle RTOS's.