Курсът разглежда стандарта за интерфейс на мобилната операционна система (POSIX), както и техники и методи за програмиране на приложения, базирани на този стандарт, илюстрирани с множество примери. Засегнати са въпросите за програмиране на многопроцесови системи, взаимодействие на приложения в рамките на разпределени конфигурации. Осигуряване на мобилност (преносимост, преносимост) софтуер(PO) - задача от изключително значение и сложност; В днешно време това обстоятелство едва ли се нуждае от задълбочено обосновка. На ниво системни услуги такава среда е описана от стандарта POSIX (Portable Operating System Interface); името е предложено от известния специалист, основател на Фондацията за свободен софтуер Ричард Столман.

Курсът разглежда най -модерната му версия в изданието от 2003 г., която може да се нарече „троен стандарт“, а именно: стандартът IEEE Std 1003.1, техническият стандарт на Open Group и най -важното за нас международният ISO / IEC 9945 стандарт. на този курс е за разбиране на техниките и методите за използване на стандартизирани помощни програми и функции. Целта не беше да се преразкаже стандарта, като се подчертаят всички тънкости на внедряването на ОС, всички възможни кодове за грешки и т.н. Основното, според нас, е да усетите духа на стандарта, да се научите да използвате присъщите му възможности по мобилен начин. Ако приемем, че читателят владее C, ние не сме разгледали нито неговия синтаксис, нито библиотечните функции на учебниците. Що се отнася до стандартния команден език и неговия интерпретатор, тази тема е описана доста подробно, въпреки че много практикуващи програмисти предпочитат да използват други интерпретатори. Значително място - както по обем, така и по роля - се отделя на примери за програми. Много разпоредби на стандарта (свързани, например, с обработката на ситуации на грешка) са посочени не в основния текст, а в съответните примери. Последните, когато е възможно, са компилирани и изпълнени на няколко хардуерни и софтуерни платформи, в една степен или друга претенция за съответствие със стандарта POSIX. Със сигурност обаче са възможни пропуски. Ще бъдем благодарни за всички коментари и предложения, свързани както с курса като цяло, така и с отделни примери за програми.

Историята на създаването и текущото състояние на стандарта POSIX.

Осигуряването на мобилност (преносимост, преносимост) на софтуера (SW) е задача от изключително значение и сложност; в наше време това обстоятелство едва ли се нуждае от задълбочено оправдание. Един от общоприетите начини за увеличаване на преносимостта на софтуера е да се стандартизира приложната среда: предоставени API, помощни програми и т.н. На ниво системни услуги такава среда е описана от стандарта POSIX (Portable Operating System Interface); името е предложено от известния експерт, основател на Фондацията за свободен софтуер, Ричард Столман.

Заглавна страница.
Изход.
Лекция 1. Основни концепции и идеи на стандарта POSIX.
Лекция 2. Езикът на черупката.
Лекция 3. Помощни програми и функции, обслужващи понятието "потребител".
Лекция 4. Организация на файловата система.
Лекция 5. Файлов вход / изход.
Лекция 6. Инструменти за обработка на структурирани данни.
Лекция 7. Процеси.
Лекция 8. Средства за междупроцесна комуникация.
Лекция 9. Общ терминален интерфейс.
Лекция 10. Разпит на характеристиките на хоста и тяхното използване в приложения.
Лекция 11. Съоръжения на мрежата.
Лекция 12. Време и работа с него.
Лекция 13. Езикова и културна среда.
Лекция 14. Заключение.
Библиография.

Безплатно сваляне електронна книгав удобен формат, гледайте и четете:
Изтеглете книгата Програмиране в стандарта POSIX, част 1, Галатенко В.А., 2016 - fileskachat.com, бързо и безплатно изтегляне.

POSIX и RV OS: опит за систематизация

Сергей Золотарев, Николай Горбунов

Целта на тази статия е опит да се внесе известна яснота в историята на разработването на стандарта POSIX, приложен към операционни системи в реално време (RT OS).

Като въведение: защо е необходима стандартизация на софтуерния интерфейс?

Една от най -важните характеристики на стандарта POSIX е, че той определя „стандартизиран интерфейс за програмиране“, към който трябва да се придържат разработчиците на сложни софтуерни и хардуерни системи. Създателите на тези системи са принудени да се изправят пред такива изисквания като ограничено време за пускане на пазара (поради ожесточена конкуренция), минимизиране на разходите и ускоряване на възвръщаемостта на инвестициите. В същото време лъвският дял от разходите поради забавянето на процеса на разработка се дължи на факта, че програмистите трябва да „преоткрият колелото“, като отново и отново внедряват функционалност, която е налична от дълго време. Но това можеше да бъде избегнато чрез:

• повторно използване на код от минали и паралелни проекти;
• пренасяне на код от други операционни системи;
• привличане на разработчици от други проекти (включително тези, които използват други операционни системи).

Всичко това е възможно благодарение на използването на ОС със стандартизиран API. Освен това, ако в първия случай е достатъчно една организация да има определен вътрешен стандарт (което е особено характерно за патентованите операционни системи), то вторите два случая просто изискват наличието на общоприети стандарти - например POSIX.

По този начин, използвайки POSIX-съвместима ОС като платформа за своите проекти, разработчикът получава възможността да прехвърли готовия код на ниво изходен код както от своите минали или паралелни проекти, така и от проекти на трети страни. Това не само значително намалява времето за разработка на софтуера, но и подобрява неговото качество, тъй като тестваният код винаги съдържа по -малко грешки.

Кой е кой в ​​POSIX Development

И няма да започнем със самия стандарт POSIX, а с подреждането на ролята на организациите, участващи в работата по него.

Първият участник е IEEE(Институт по инженери по електротехника и електроника, Институт по инженери по електротехника и електроника), обществено сдружение с нестопанска цел от професионалисти. IEEE датира от 1884 г. (официално - от 1963 г.), обединява 380 000 отделни членове от 150 държави, публикува трета част от техническата литература, свързана с използването на компютри, управление, електрически и информационни технологии, както и повече от 100 списания. популярен сред професионалистите; освен това асоциацията провежда над 300 големи конференции годишно. IEEE е участвал в разработването на над 900 съществуващи стандарта (www.ieee.ru/ieee.htm). Днес този институт се занимава с подготовка, координация, одобряване, публикуване на стандарти, но поради официалния си статут няма правомощия да приема такива документи като международни или национални стандарти. Следователно терминът "стандарт" в разбирането на IEEE трябва по -скоро да се разбира като "спецификация", която е по -съгласувана със статута на документите, приети от асоциацията. В съответствие с IEEE, той участва в програмите на редица международни и регионални организации - IEC, ISO, ITU (Международен телекомуникационен съюз), ETSI (Европейски институт по телекомуникационни стандарти), CENELEC (Европейски комитет по стандартизация на електротехниката) и в национални програми, например, в програмата на такава организация като ANSI.

IEEE включва PASC (Portable Application Standards Committee), асоциационен комитет, който разработва семейството на стандартите POSIX (www.pasc.org/). PASC е известен преди като Технически комитет за операционни системи.

Вторият участник в работата - ANSI(American National Standards Institute, American National Standards Institute) - частна организация с нестопанска цел, която администрира и координира в Съединените щати дейности по стандартизация. В него работят само 75 души, но ANSI има над 1000 членове, компании, организации, държавни агенции и институции (www.ansi.org). ANSI представлява Съединените щати в два големи международни стандарта, ISO и IEC.

Трети участник - ISO(Международна Организация по Стандартизация). Той е създаден през 1946 г. с решение на Комитета за координация на стандартите и Общото събрание на ООН и официално започва работа на 23 февруари 1947 г. (www.iso.org). ISO е мрежа от национални институти по стандарти от 146 държави (една държава - един член на ISO) с централен секретариат в Женева (Швейцария). Стандартите ISO се разработват в технически комитети, първият изход от които е проектът на международен стандарт (DIS), който след няколко одобрения става окончателният проект на международен стандарт (FDIS). След това въпросът за одобрение на този документ се поставя на гласуване; ако успее, става международен стандарт.

И накрая - IEC(Международна електротехническа комисия, Международна електротехническа комисия - IEC), основана през 1906 г., IEC подготвя и публикува международни стандарти за всички електрически, електронни и сродни технологии (www.iec.ch/). Към 1 ноември 2004 г. националните комитети на 64 държави бяха активни членове на тази комисия. IEC публикува и препоръки, които са публикувани на английски и френски и имат статут на международни стандарти. На тяхна основа се разработват регионални и национални стандарти. Техническите комитети (ТК) са отговорни за изготвянето на стандарти в различни области на дейностите на IEC, в които участват национални комитети, заинтересовани от дейностите на конкретен ТС.

IEC е ключова организация при подготовката на международни стандарти за информационни технологии. В тази област съществува съвместен технически комитет по информационни технологии - JTC 1, сформиран през 1987 г. в съответствие със споразумение между IEC и ISO. JTC1 има 17 подкомисии, които контролират всичко - от софтуер до езици за програмиране, компютърна графика и редактиране на изображения, взаимосвързване на оборудването и практики за безопасност.

Изготвянето на нови стандарти на IEC включва няколко етапа (предварителен, етап на предложение, подготвителен етап, етап на технически комитет, етап на заявка, етап на одобрение, публикуване). Ако документът на IEC е предназначен да стане само техническа спецификация, а не международен стандарт, преработената версия на документа се изпраща в централата за публикуване. Окончателният проект на международния стандарт (FDIS) ще отнеме четири месеца, за да бъде завършен. Ако бъде одобрен от всички членове на техническия комитет, той се изпраща в централния офис за публикуване без етапа на одобрение на FDIS. След това FDIS отива при националните комитети, които трябва да го одобрят в рамките на два месеца. FDIS се счита за одобрен, ако повече от две трети от националните комитети са гласували за него, а броят на отрицателните гласове не надвишава 25%. Ако документът не е одобрен, той се изпраща за преразглеждане до техническите комитети и подкомитетите. Стандартът трябва да бъде публикуван не по -късно от два месеца след одобрението на FDIS.

Няколко други организации участват в разработването и приемането на стандартите POSIX.

Отворена групаЕ международна организация за стандартизация на софтуера, която обединява близо 200 производители и потребителски общности, работещи в областта на информационните технологии (www.opengroup.org/). Open Group е създадена през 1995 г. чрез сливането на двата й предшественика: X / Open и Open Software Foundation (OSF). Open Group е специализирана в разработването на методологии за сертифициране на софтуер и тестване за съответствие. По -специално, Open Group предоставя сертификати за области като COE Platform, CORBA, LDAP, Linux Standard Base, Schools Interoperability Framework (SIF), S / MIME Gateway, Single UNIX Specification, Wireless Application Protocol Specifications (WAP) и накрая POSIX семейство стандарти (www.opengroup.org/certification/).

Група за ревизия на общите стандарти в Остин (CSRG)- съвместни технически работна групасъздадена през 2002 г. от ISO, IEC и Open Group за създаване и поддържане най -новите версиистандарт 1003.1, който ще бъде формиран въз основа на ISO / IEC 9945-1-1996, ISO / IEC 9945-2-1993, IEEE Std 1003.1-1996, IEEE Std 1003.2-1992 и Единична UNIX спецификация (www.opengroup.org / press/ 14nov02.htm).

Национален институт по стандарти и технологии (NIST)- федерална агенция в рамките на Технологичната администрация на Министерството на търговията (www.nist.gov/public_a Affairs/general2.htm), основана в САЩ през 1901 г. Мисията на NIST е да разработва и популяризира стандарти и технологии за подобряване на качеството на продуктите. NIST включва Лаборатория за информационни технологии (ITL), един от резултатите от която са Федералните стандарти за обработка на информация (FIPS, www.opengroup.org/testing/fips/general_info.html). NIST / ITL предлага първоначален набор от тестове за POSIX сертифициране по FIPS PUB 151-1 1990 през 1991 г.

Какво е POSIX?

Формално терминът POSIXпредложен от Ричард Столман като съкращение за P ortable Опертинг С ystem интерфейс за un IX(портативен интерфейс на операционната система за Unix). POSIX е разработен за UNIX-подобни операционни системи (най-ранните им версии датират от началото на 70-те години) с цел осигуряване на преносимост на източника на приложенията.

Първоначалното описание на интерфейса е публикувано през 1986 г., когато се нарича IEEE-IX (версия на UNIX на IEEE). Името обаче бързо се променя, превръщайки се в POSIX, а вече в следващата публикация (през 1986 г.) тази нова версия беше използван за известно време POSIX се разбираше като препратка (или синоним) към група свързани документи IEEE 1003.1-1988 и части от ISO / IEC 9945, а като завършен и одобрен международен стандарт ISO / IEC 9945.1: 1990 POSIX беше приети през 1990 г. Спецификациите на POSIX определят стандартен механизъм за взаимодействие между приложна програма и ОС и понастоящем включват повече от 30 стандарта под егидата на IEEE, ISO, IEC и ANSI.

През цялата си история POSIX е извървял дълъг път, като определянето на спецификации, тяхното специфично съдържание, процедури и логистиката на тяхната проверка са се променяли многократно. Оттогава са издадени няколко издания на стандарта POSIX в рамките на различни международни организации.

Историята на развитието на стандарта POSIX

Първата версия на спецификацията IEEE Std 1003.1 е публикувана през 1988 г. Впоследствие множество издания на IEEE Std 1003.1 бяха приети като международни стандарти.

Етапи на разработка на POSIX:

1990 година

Изданието, издадено през 1988 г., беше преработено и стана основа за по -нататъшни преработки и допълнения. Той е одобрен като международен стандарт ISO / IEC 9945-1: 1990.

1993 година

Издание 1003.1b-1993 е публикувано.

1996 година

Направени са промени в IEEE Std 1003.1b-1993, IEEE Std 1003.1c-1995 и 1003.1i-1995, но по-голямата част от документа остава непроменен. През 1996 г. ревизията на IEEE Std 1003.1 също беше одобрена като международен стандарт ISO / IEC 9945-1: 1996.

1998 година

Появи се първият стандарт за „реално време“ - IEEE Std 1003.13-1998. Това е разширение на стандарта POSIX за вградени приложения в реално време.

1999 година

Беше решено да се направят значителни промени в основния текст на стандарта за първи път през последните 10 години, включително сливане със стандарта 1003.2 (Shell и комунални услуги), тъй като по това време това бяха отделни стандарти. PASC реши да финализира промените в основния текст, след като приключи работата по стандартите IEEE 1003.1a, 1003.1d, 1003.1g, 1003.1j, 1003.1q и 1003.2b.

2004 r.

Последната редакция на 1003.1 е публикувана на 30 април и пусната под егидата на Групата за ревизия на общите стандарти в Остин. Той е изменен за изданието на стандарта за 2001 г. Формално изданието за 2004 г. е известно като IEEE Std 1003.1, издание 2004, Технически стандартни базови спецификации на Отворената група, брой 6 и включва IEEE Std 1003.1-2001, IEEE Std 1003.1-2001 / Cor 1-2002 и IEEE Std 1003.1-2001 / Cor 2-2004.

Най -важните POSIX стандарти за RT OS

За операционните системи в реално време седем спецификации на стандарта са най-важни (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21), но само три са получили широка поддръжка в търговските операционни системи:

• 1003.1a (Определение на ОС)дефинира основните интерфейси на ОС, контрол на заданията, сигнали, функции на файловата система и работа с устройства, потребителски групи, конвейери, буфери FIFO;
• 1003.1b (разширения в реално време)описва разширения в реално време като сигнали в реално време, приоритетно планиране, таймери, синхронни и асинхронни I / O, семафори, споделена памет, съобщения. Първоначално (преди 1993 г.) този стандарт се нарича POSIX.4.
• 1003.1c (нишки)дефинира функции за поддръжка на нишки - контрол на нишки, атрибути на нишки, мутекси, изпращане. Първоначално обозначен като POSIX.4a.

В допълнение към тези стандарти, следните стандарти са важни за RT OS, които бяха внедрени като част от работата по проекта Std 1003.1-2001:

• IEEE 1003.1d-1999.Допълнителни разширения в реално време. Първоначално обозначен като POSIX.4b;
• IEEE 1003.1j-2000.Подобрени (разширени) разширения в реално време;
• IEEE 1003.1q-2000.Проследяване.

Процедура за сертифициране

За да бъде съвместима с POSIX, операционната система трябва да бъде сертифицирана по съответния набор от тестове. След въвеждането на POSIX, тестовият пакет е претърпял официални и де факто промени.

През 1991 г. NIST разработи програма за тестване на POSIX съгласно FIPS 151-1 (http://standards.ieee.org/regauth/posix/POSIX-A.FM5.pdf). Тази опция за тест се основава на IEEE 1003.3 "Стандарт за методи за изпитване за измерване на съответствие с POSIX" Проект 10, 3 май 1989 г. През 1993 г. NIST завършва програмата за тестване на POSIX за FIPS 151-1 и стартира програмата за FIPS 151 -2 (www.itl.nist.gov/fipspubs/fip151-2.htm). FIPS 151-2 е адаптирал „Информационни технологии - интерфейс на преносима операционна система (POSIX) - Част 1: Програмен интерфейс за системни приложения (API)“, който е стандарт ISO / IEC 9945-1: 1990. Тестовите пакети за FIPS 151-2 бяха базирани на IEEE 2003.1-1992 "Стандарт за методи за изпитване за измерване на съответствие с POSIX".

NIST прави разлика между две методологии за сертифициране: самосертифициране и сертифициране от акредитирани от IEEE лаборатории за изпитване (акредитирани лаборатории за тестване POSIX - APTL). В първия случай компанията провежда тестове сама, но съгласно план, одобрен от NIST. Във втория случай тестването се извършва от независима лаборатория, използваща автоматизирани тестови пакети. Общо две лаборатории на APTL са акредитирани: Mindcraft (www.mindcraft.com) и Perennial (www.peren.com).

През 1997 г. NIST / ITL обяви намерението си да прекрати сертифицирането по FIPS 151-2 в края на тази година (официално на 31 декември 1997 г.), докато Open Group обяви, че ще поеме от 1 октомври същата година. година FIPS 151-2 сертифицираща услуга, базирана на програма NIST / ITL. Същите функции са поети от Асоциацията по стандарти за IEEE (IEEE-SA) от 1 януари 1998 г., а също и въз основа на FIPS 151-2.

През 2003 г. IEEE-SA и Open Group обявиха нова съвместна програма за сертифициране за най-новите версии на POSIX, започвайки с IEEE 1003.1 ™ 2001. Отворената група вече има няколко тестови пакета, които покриват IEEE Std 1003.1-1996, IEEE Std 1003.2-1992 , IEEE Std 1003.1-2003 и IEEE Std 1003.13-1998 (www.opengroup.org/testing/testsuites/posix.html). Продуктът се счита за POSIX сертифициран, ако е преминал пълната процедура за сертифициране, според резултатите от теста отговаря на всички изисквания и е вписан в официалния регистър на сертифицираните продукти.

Тестовите пакети включват:

• VSX-PCTS1990 (www.opengroup.org/testing/testsuites/vsxpcts1990.htm)-набор от тестове за съответствие за системни интерфейси IEEE Std 1003.1-1990;
• VSPSE54 (www.opengroup.org/testing/testsuites/VSPSE54.htm) - набор от тестове за съответствие за IEEE Std 1003.13-1998 Профил PSE54 (многофункционален в реално време);
• VSX-PCTS2003 (www.opengroup.org/testing/testsuites/vsxpcts2003.htm)-набор от тестове за съответствие за системни интерфейси IEEE Std 1003.1-2003 (само задължителни части);
• VSC-PCTS2003 (www.opengroup.org/testing/testsuites/vscpcts2003.htm) е набор от тестове за съответствие за IEEE Std 1003.1-2003 (обвивка и помощни програми-необходими части само).

В допълнение, Open Group е разработила критерии за стандартите в реално време POSIX и вградения профил за стандарти POSIX. POSIX Test Suite в реално време (www.opengroup.org/testing/testsuites/realtime.html) включва следните тестове:

• IEEE POSIX 1003.1b-1993 / 1003.1i-1995 Разширение в реално време и IEEE POSIX 1003.1,2003 Edition;
• IEEE Std POSIX 1003.1c-1995 Threads (pthreads) разширение и IEEE POSIX 1003.1,2003 Edition;
• IEEE POSIX 1003.1d-1999 Допълнително разширение в реално време и IEEE POSIX 1003.1,2003 Edition;
• IEEE POSIX 1003.1j-2000 Разширено разширение в реално време и IEEE POSIX 1003.1,2003 издание;
• IEEE POSIX 1003.1q-2000 Trace и IEEE POSIX 1003.1,2003 Edition и IEEE POSIX 1003.1,2003 Edition;

Тестовият пакет за вградени POSIX стандарти (www.opengroup.org/testing/testsuites/embedded.html) включва следните тестове:

• IEEE POSIX 1003.1-1990 (5310 теста);
• IEEE POSIX 1003.1b-1993 / 1003.1i-1995 Разширение в реално време (1430 теста);
• IEEE Std POSIX 1003.1c-1995 Теми (pthreads) разширение (1232 теста);
• IEEE POSIX 1003.13-1998 Профил 52.

Малко за объркването в терминологията

По отношение на групата стандарти POSIX на английски език често се използват не един, а цели три термина. За съжаление, те са сходни по значение и често се превеждат по същия начин, което внася известно объркване. Тези условия са както следва:

• съвместимост (буквално - "съвместимост");
• съответствие (буквално - "съответствие");
• съответствие (буквално - „последователност“).

Първият термин, приложен към POSIX, не е официално дефиниран. Второто означава, че организацията - производител на софтуерния продукт независимо декларира, че този продукт (изцяло или частично) отговаря на изброените стандарти NIST -PCTS. Третият термин предполага това софтуерпреминал установената система за изпитване или с помощта на акредитирана лаборатория, или в рамките на Отворената група и има документални доказателства за това (т. нар. Декларация за съответствие). По -нататък в текста на статията, оригиналите на термините ще бъдат цитирани навсякъде, за да се премахне неяснотата.

Сертифициран OS RV

Ако се придържате към строги правила, изискващи данните за сертифицирана RT OS да бъдат публикувани в официалния регистър и тестването се извършва на ниво съответствие, в момента има само две сертифицирани RT OS (данните са дадени в хронологичен ред):

LynxOS v.3(продукт на Lynx Real-Time Systems, сега наричан LynuxWorks, Inc., www.lynuxworks.com) е предназначен за разработване на софтуер за вградени системи, работещи в трудно реално време, производители на OEM и телекомуникационно оборудване, по-специално производители на бордови системи за военни приложения ... Разработването може да се извърши както на самата целева система (самостоятелно хоствана), така и на инструменталния компютър (хост), готовият софтуер е проектиран да работи върху целевата система (цел). LynxOS v.3 е сертифицирано POSIX съответствие на платформи Intel и PowerPC. Информация за това може да бъде намерена на уебсайта на IEEE на адрес http://standards.ieee.org/regauth/posix/posix2.html. LynxOS е сертифициран по POSIX 1003.1-1996 от Mindcraft, акредитирана от IEEE POSIX лаборатория за тестване POSIX в NIST FIPS 151-2 Тестов пакет за съответствие. Номер на документа за сертифициране: Референтен файл: IP-2LYX002, Референтен файл: IP-2LYX001.

ИНТЕГРИТНОСТ v.5(продукт на софтуера Green Hills, www.ghs.com) е сертифициран в съответствие с POSIX 1003.1-2003, Системни интерфейси за архитектура PowerPC през юли 2004 г. (http://get.posixcertified.ieee.org/select_product. tpl). Тестов пакет VSX-PCTS 2003.

POSIX и операционната система QNX

QNX v.4.20 (разработен от QNX Software Systems, www.qnx.com) е POSIX 1003.1-1988 съответствие, сертифициран за платформата Intel от DataFocus Incorporated. Тестването е проведено на 13 септември 1993 г. и е издадено на 1 ноември 1993 г. NIST PCTS 151-1 Test Suite, Версия 1.1.

QNX Neutrino (версия 6.3) отговаря на следните стандарти на семейството POSIX (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, създателят на QNX Neutrino, също планира съответствие на QNX Neutrino с някои от тези стандарти; работата е планирана за 2005 г. (www.qnx.com/news/pr_959_1.html).

Литература

1. Ръководство за работа на IEEE Standards Association. IEEE, октомври 2004 г.
2. Кевин М. Обеланд. POSIX в програмиране за вградени системи в реално време, 2001 г.
3. Стандарт IEEE / ANSI 1003.1: Информационни технологии - (POSIX) - Част 1: Системно приложение: Програмен интерфейс (API).
4. Gallmeister, B. O. Програмиране за реалния свят, POSIX.4Севастопол, Калифорния: O'Reilly & Associates, 1995.
5. Национален институт по стандарти и технологии, PCTS: 151-2, POSIX Test Suite.
6. POSIX: Сертифициран от IEEE и The Open Group.Сертифицирана политика. Отворената група, 21 октомври 2003 г., редакция 1.1.

Алексей Федорчук
2005 година

Една от отличителните черти на логическата структура на файловата система на операционните системи от семейство POSIX е тяхната йерархична или дървовидна организация (въпреки че, както казах, дървото изглежда малко странно). Тоест, както в DOS или Windows от всякакъв вид, няма обозначение (например азбучно или друго) за отделни носители и техните дялове: всички те са включени в една структура като поддиректории на главната директория. наречен корен. Процес на свързване файлови системина независими физически носители (и техните дялове) до корена на файловото дърво се нарича монтиране, а поддиректориите, които съдържат, се наричат ​​точки за монтиране.

Исторически Unix е разработил специфична структура на директории, която е много сходна в цялото семейство като цяло, но малко по -различна в детайлите. По -специално, файловата йерархия в BSD системите е почти идентична, но различна от тази в Linux. И в последното се откриват значителни разлики между различните разпределения. До факта, че структурата на файловата йерархия е една от специфичните за дистрибуцията характеристики.

Това състояние на нещата затруднява писането на кросплатформени приложения. И затова съществува и се развива активно проект за стандартизиране на файловата йерархия - FHS (Стандарт за йерархия на файловата система).

Първоначално FHS е имал за цел да рационализира структурата на директориите на многобройни дистрибуции на Linux. По -късно е адаптиран за други Unix-подобни системи(включително клана BSD). И сега има активни (но не особено успешни) усилия да се превърне в стандарт за POSIX системи, не само по име, но и по същество.

Стандартът FHS се основава на два основни принципа - ясно разделение във файловата йерархия на директории, които са споделени и не споделяни, от една страна, и неизменни и променливи, от друга.

Контрастът между споделени и не-споделени директории се дължи на присъщата на Unix мрежова природа. Тоест данните, свързани с локална машина (например конфигурационни файлове за нейните устройства), трябва да се намират в директории, отделни от тези, чието съдържание е достъпно от други машини в мрежата, локални или глобални (пример за това не е само потребител данни, но и програми) ...

Същността на противопоставянето между неизменяеми и променящи се директории е лесно обяснима с пример. Така че същите програми за общ потребител по своята същност трябва да бъдат неизменни (или по -скоро, достъпни за промяна само на системния администратор, но не и на самия потребител, който ги използва в работата си). В същото време тези програми по време на работата си генерират не само файлове с данни, да речем, текстове или изображения (тяхната променлива природа е ясна без коментари), но и всякакъв вид служебна информация, като файлове с дневници, временни файлове и други подобни) . Които трябва да бъдат групирани в директории, отделени от действителните изпълними програмни файлове, библиотеки, конфигурационни файлове и т.н., необходими за тяхното изпълнение.

Въпреки това, въпреки активното популяризиране в много дистрибуции на Linux сред най -разпространените, FHS не е придобил статут на истински стандарт. Има доста дистрибуции на Linux, които не използват някои от неговите разпоредби. И само частично корелира с традиционната файлова йерархия на BSD системите.

Причината е, че FHS игнорира още едно противопоставяне, което е много важно за потребителя: противопоставянето на лесно възстановими части от файловата система и тези на нейните компоненти, които са трудни за възстановяване или изобщо не могат да бъдат възстановени.

Първото, колкото и да е странно, може да се припише на самата базова система: в края на краищата преинсталирането му от носителя за разпространение, в случай на фатален срив, не е толкова трудно. Трудно възстановимите части на файловата система очевидно включват потребителски данни: дори ако те се архивират редовно (и колко потребители са толкова внимателни?), Разгръщането им от архиви ще отнеме много време (и почти неизбежно) водят до някои загуби).

В допълнение, в BSD системите и дистрибуциите на Linux, базирани на източник, бих класифицирал всичко, свързано с управлението на пакети, като трудно възстановими директории-дървото на портовете на FreeBSD или pkgsrc в NetBSD (и системите, които го взеха назаем), техните партньори в дистрибуциите на Linux, действителния изходен код на пренесените програми и изходния код на системата също. Защото, дори ако всичко това е в комплекта за разпространение, тези компоненти на файловата система, като правило, се поддържат актуални от потребителя чрез синхронизиране със сървърите на проекта през мрежата (в противен случай използването им е безсмислено). Загубата им ще доведе както до временни (особено с модемна връзка), така и до финансови (малко хора са щастливи собственици на безплатен достъп до Интернет) загуби.

Стриктното спазване на концепцията за разделяне на споделени и не споделени, неизменни и неизменни, възстановими и невъзстановими директории един от друг позволява, в рамките на една дървесна йерархия на файлове, да отдели отделните му клонове физически-тоест във формата на независими файлови системи, разположени на изолирани устройства (дискове, раздели на дискове, парчета, дялове и т.н.). Има много причини за това - както увеличаване на производителността, така и повишаване на надеждността, и просто съображения за удобство - но няма да говорим за тях сега. Защото в този моментважното за нас е, че тези клонове на файловото дърво трябва да бъдат включени в общата файлова система.

Типичен набор от системни директории POSIX

Всъщност за функционирането е абсолютно необходимо да има само една файлова система - тази, която е монтирана в главната директория на файловото дърво (един вид аналог на световното дърво Yggdrassil). Основната директория и нейните незаменими клонове трябва да съставят една файлова система, разположена на един носител - диск, дисков дял, софтуерен или хардуерен RAID масив или логически том в разбирането на LVM. И трябва да съдържа всички компоненти, необходими за стартиране на системата и в идеалния случай нищо повече.

Можете да видите състава на основната директория с командата

$ ls -1 /

което на всяка система POSIX ще покаже някакъв минимален набор от директории за джентълменски:

Bin / boot / etc / root / sbin /

Именно в тях се събират всички файлове, без които системата не може да съществува. Други директории са нещо подобно:

Начало / mnt / opt / tmp / usr / var /

Те са а) не се изискват (поне на теория - практически е трудно да се направи без тях), б) не всяка от тях присъства във всички системи и разпределения и в) всяка от тях може да бъде (и често е - ако правите всичко според вашия ум) точката на монтиране на собствения й клон на файловото дърво.

Освен това в повечето случаи има още две поддиректории в корена на файловата система на POSIX-съвместими ОС:

Dev / proc /

Обикновено това са точките на монтиране на виртуални файлови системи - съответно устройства и процеси (въпреки че, ако файловата система от устройства не се използва, директорията / dev трябва да бъде компонент на основната файлова система. И накрая, в Linux системите, като правило, коренът на файловото дърво е и директория / lib за основните системни библиотеки, а с udev неизбежната директория / sys също е мястото, където е монтирана виртуалната файлова система sysfs.

Основна файлова система

Коренната файлова система е неделима (т.е. не е предназначена за споделяне от различни машини в мрежата) и неизменна (тоест само системният администратор може да прави промени в нея, но не и потребителските програми и освен това не потребителите). Освен това е силно обезкуражено създаването на поддиректории в него над тези, предвидени от стандарта (и изброени по -горе).

Попълването на основната файлова система е избрано така, че машината да може да стартира и запазва минимална функционалност дори по време на аварийно зареждане (или в режим за един потребител), когато всички други файлови системи не са монтирани (и съответно нейните клонове, като напр. / usr или / var може да не са налични.

Съответно, стартирането на машината се осигурява от директорийните файлове / boot и / и т.н. Първият съдържа ядрото на системата - изпълним файл със „специално предназначение“ - и всичко необходимо за зареждането му - в Linux, например системната карта (/etc/System.map), и във FreeBSD - зареждаемо ядро модули. Понякога обаче ядрото се намира директно в корена на файловата система и тогава директорията / boot може да липсва изцяло, а директорията / modules може да бъде запазена за модулите на ядрото.

Директорията / etc е за конфигурационни файлове в цялата система, които определят условията за нейното зареждане. Съдържанието му много зависи от системата (а в Linux - също и от комплекта за разпространение) и затова няма да го разглеждам тук - ще трябва да се връщам към тази тема повече от веднъж.

Минимално необходимата функционалност се осигурява от съдържанието на директориите / bin и / sbin - те съдържат изпълними файлове съответно на най -важните потребителски и системни програми, точно тези, които ще ви позволят да извършите комплекс от мерки за ремонт и спасяване и да доведе колата в човешка форма след повреда.

Разделянето на системни и потребителски програми на основни поддиректории е доста произволно. Нито една от тези команди не е предназначена за решаване на потребителски проблеми. Просто директорията / bin съдържа административни команди, които от време на време са достъпни (или могат да бъдат достъпни) от обикновен потребител, а директорията sbin е предназначена за команди, за които потребителят не трябва да знае. И които в повечето случаи той все още няма да може да използва поради липсата на подходящи правомощия (например необходимите права за достъп до файловете на устройството).

За да стартирате POSIX програми (включително тези, компилирани в директориите / bin и sbin), като правило се нуждаете от достъп до функциите на системните библиотеки (предимно основната библиотека glibc). И следователно (почти) незаменимият компонент на основната директория е поддиректорията / lib, в която те са сглобени.

В Linux директорията / lib служи на друга важна цел - нейната поддиректория ( / lib / modules) съдържа зареждащи се модули на ядрото (на FreeBSD тяхното място е / boot / kernel).

Във FreeBSD директорията / lib не се намира в основната файлова система - съответните компоненти се намират тук в / usr / lib (вижте по -долу). Това е така, защото исторически FreeBSD е изграждал важни общосистемни програми, така че библиотечните функции, от които се нуждаят, са вградени в техните изпълними файлове (наречени статично свързване, което ще бъде обсъдено в глава 14). Във FreeBSD програмите за 5 -ти клон от директориите / bin и / sbin са свързани динамично, тоест при липса на директорията / usr (а в Free това почти винаги е отделен клон на файловата система) те не функционират. За да компенсира това, има директория / restore, която надхвърля стандартите, съдържаща същите програми, но статично свързана (както подсказва името на директорията, единствената цел на нейното съдържание са спасителни операции).

И накрая, / root. Това е обичайната домашна директория на потребителя със същото име, тоест системния администратор. Тъй като не върши никаква практическа работа (или поне не би трябвало), съдържанието му са само собствените конфигурационни файлове на суперпотребителя (командната обвивка на потребителя, любимият редактор и т.н.).

Клонът / usr

Исторически директорията / usr е била предназначена за потребителски програми и данни. Тези функции вече са разделени между / usr / local и / home (въпреки че последното вече е символична връзка към / usr / home по подразбиране на FreeBSD). Директорията / usr - не променяща се, но споделена - служи като хранилище за по -голямата част от приложните програми и всичко свързано с тях - изходен код, конфигурационни файлове, споделени библиотеки, документация и други подобни.

Съставът на директорията / usr се различава значително между BSD системите и Linux. В първия той съдържа само неразделните части на операционната система (тази, която във FreeBSD е обединена от концепцията за дистрибуции). Приложенията, инсталирани от портове или пакети, имат своето място в поддиректория / usr / local, която може да представлява отделен клон на файловото дърво.

В Linux директорията / usr служи като хранилище за всички програми (и техните компоненти), включени в комплекта за разпространение. Поддиректорията / usr / local обикновено е предназначена за програми, които се компилират независимо от източника.

Във всеки случай обичайният състав на директорията / usr е следният (както се съобщава от командата ls -1):

X11R6 / bin / etc / include / lib / libexec / local / sbin / share / src /

Както вече споменахме, под -директорията / usr / local е отделен клон на файловото дърво и следователно ще се разглежда отделно. Целта на другите директории е следната:

• / usr / bin и / usr / sbin са предназначени за изпълними файлове на потребителски и системни програми (тук границата между тях е още по -произволна, отколкото в случая с основната директория), чиято цел надхвърля осигуряването на основното функциониране на системата;
• / usr / etc е за отделни конфигурационни файлове на приложения;
• / usr / include съдържа така наречените заглавни файлове, необходими за свързване изпълними файловес библиотечни компоненти;
• / usr / lib и / usr / libexec са директории за споделени библиотеки, от които зависят потребителските приложения;
• / usr / share - хранилище на най -разнообразните, т.нар. архитектурно независими компоненти: тук можете да видите документация в различни формати и примери за конфигурационни файлове и данни, използвани от програмите за управление на конзоли (шрифтове, подредби на клавиатурата), както и описание на часовите зони;
• / usr / src - директория с изходния код; в Linux тук се поставя само изходният код на ядрото (ядрата) на системата, в клонингите на BSD - пълният набор от изходни кодове на комплекса, който във FreeBSD се нарича Разпределения; По правило е нежелателно тук да се поставят източниците на самостоятелно сглобени програми;
• / usr / X11R6 - директория за компоненти на прозоречната система X - изпълними файлове ( / usr / X11R6 / bin), библиотеки ( / usr / X11R6 / lib), заглавки ( / usr / X11R6 / include), документация ( / usr / X11R6 / човек); X файловете с приложения не трябва да се поставят тук (освен, може би, за мениджъри на прозорци) - тяхното място е в / usr, / usr / local или / opt, в зависимост от системата.

В допълнение, директория / usr може да съдържа поддиректории / usr / var и / usr / tmp - обикновено символни връзки към съответните клонове на основната директория. А при някои дистрибуции на Linux основната общосистемна документация, man страници (в поддиректорията / usr / man), се поставя директно в / usr.

И накрая, в BSD системите и някои източници базирани Linux дистрибуции (например Gentoo), директория / usr съдържа поддиректория за системата за управление на пакети - портовете FreeBSD и OpenBSD ( / usr / портове), техните аналози в други системи ( / usr / portage в Gentoo). Въпреки че от гледна точка на придържането към буквата и духа на стандарта FHS (той самият не споменава и дума за портове и подобни системи), по -логично място за тях ще бъде директория / var (вижте по -долу) - и точно това се прави в дистрибуции като CRUX и Archlinux.

Клон / usr / местен

Както вече споменахме, / usr / local клон в Linux е предназначен за програми, които са компилирани независимо от източници (не са включени в този комплект за разпространение). А на FreeBSD той служи като хранилище за повечето приложения на потребителя - почти всичко извън дистрибуциите и инсталирано от пакети или портове. Съответно структурата на директориите като цяло следва тази на / usr клона (с разбираеми изключения):

Кошче / etc / include / lib / man / sbin / share /

Съдържанието на поддиректориите също е подобно: изпълними файлове на програмата ( / usr / local / bin и / usr / local / sbin), техните конфигурации ( / usr / local / etc), библиотеки, с които са свързани, и техните заглавни файлове ( / usr / local / lib и / usr / local / include, съответно), man страници ( / usr / local / man) и всички видове независими от архитектурата неща ( / usr / local / share), включително документация в други формати .

/ Опция клон

Директорията / opt се предоставя от стандарта FHS, но всъщност не се използва във всички дистрибуции на Linux, а в системите на BSD тя напълно липсва. Независимо от това, все повече програми се пишат с очакване на инсталация по подразбиране в него.

Исторически директория / opt е била използвана в Linux за търговски приложения и всякакъв вид несвободен софтуер. В днешно време целта му е да хоства големи самостоятелни софтуерни системи, като библиотеката Qt, KDE с всички нейни компоненти и приложения, OpenOffice.org и други подобни. Структурата на директорията трябва да бъде / opt / pkg_name. Ето как изглежда в моята система (Archlinux):

$ ls -1 / опция gnome / kde / OpenOffice.org1.1.2 / qt /

Всяка от поддиректориите има своя собствена вътрешна структура:

$ ls -1 / opt / * / opt / gnome: bin / lib / man / share / / opt / kde: bin / etc / include / lib / share / /opt/OpenOffice.org1.1.2: help / LICENSE LICENSE. html програма / README README.html [защитен имейл]дял / [защитен имейл] THIRDPARTYLICENSEREADME.html потребител / / opt / qt: bin / doc / include / lib / mkspecs / разговорници / плъгини / шаблони / преводи /

Целта на поддиректориите в / opt / pkg_name лесно се досеща по аналогия с / usr и / usr / local. Например / opt / kde / bin е за изпълними файлове на системата KDE и нейните приложения, / opt / kde / etc е за нейните конфигурационни файлове, / opt / kde / include е за заглавни файлове, / opt / kde / lib е за библиотеки и / opt / kde / share - за споделени файлове, включително документация. В KDE няма документация в man -формат, ако е така, тогава (както в случая с Gnome - не съм го инсталирал, това са приложенията на Gimp и подобни Gtk) можете да видите / opt / pkg_name / поддиректория man.

Можете да видите, че структурата на директория / opt се отклонява от исторически установената (и вътрешно обоснована традиция на POSIX за комбиниране на подобни компоненти в директории - изпълними файлове, библиотеки и т.н.) И с голям брой програми, инсталирани в нея, тя създава определени трудности : или трябва да претоварите променливата $ PATH, която осигурява бърз достъп до команди (което ще бъде обсъдено в глава 12), или да създадете специална директория / opt / bin и да поставите символни връзки към изпълними двоични файлове на програмата. Следователно в някои Linux дистрибуции (например в CRUX) / opt не се използва по принцип. Както, наистина, във всички BSD системи. Напълно възможно е по -добре по този начин ...

/ Var клон

Както подсказва името, директорията / var е предназначена за съхраняване на променливи файлове, генерирани по време на нормалния живот на различни програми - софтуерни (например браузър) кешове, лог файлове, спулингови системи за печат и пощенски системи. пощенски кутии, описания на работещи процеси и т.н. По -специално, в директорията / var се поставят т. Нар. Dumps - снимки на състоянието на RAM, генерирани при аварийно изключване, за да се идентифицират причините за това. Отличителна черта на всички тези компоненти е променливият им характер по време на работна сесия и фактът, че въпреки това те трябва да бъдат запазени при рестартиране на системата.

Вътрешната структура на / var варира значително в зависимост от системата и затова няма да се спирам на подробностите за нейната структура. Ще отбележа само, че тази директория е логично място за поставяне на компоненти от всякакви портови системи за управление на пакети, както се прави например в дистрибуцията Archlinux, където поддиректорията / var / abs (abs - Archlinux Building System ) е запазено за него.

Директория / mnt

Директорията / mnt е предназначена за монтиране на временно използвани файлови системи, обикновено разположени на сменяеми носители... В една всеобхватна система тя обикновено е празна и нейната структура не се регулира по никакъв начин. Потребителят е свободен да създава в него поддиректории за определени типове носители. Например в моята система това са / mnt / cd, / mnt / dvd, / mnt / usb и / mnt / hd - за компактдискове, DVD дискове, флаш устройства и сменяеми твърди дискове.

Във FreeBSD директориите по подразбиране за монтиране на компактдискове и дискети са / cdrom и / floppy директно в основната директория. Което не е съвсем съгласно със стандарта, но по свой начин е логично - точките за монтиране на съществуващи устройства (като CD ROM) или доскоро съществуващи (дискета) във всяка машина се извеждат в корена.

/ Домашен клон

Директорията / home е за хостване на домашните директории на потребителите. Съдържанието му не е регулирано по никакъв начин, но обикновено изглежда като /home/(username1,...,username#). Въпреки това, в големи системи с голям брой потребители, техните домашни директории могат да бъдат групирани заедно.

Директорията / home може да съдържа домашните директории не само на реални потребители, но и на някои виртуални потребители. Така че, ако машината се използва като уеб или ftp сървър, ще видите съответните поддиректории като / home / www или / home / ftp.

Клонът / tmp

Остава да говорим само за директорията за съхранение на временни файлове - / tmp. Подобно на / var компонентите, те се генерират от различни програми по време на нормалния им живот. Но, за разлика от / var, / tmp компонентите не се очаква да бъдат запазени извън текущата сесия. Освен това всички ръководства за системно администриране препоръчват редовно (например при рестартиране на машината) или периодично изчистване на тази директория. И затова, като / tmp, е препоръчително да монтирате файлови системи в RAM - tmpfs (в Linux) или mfs (във FreeBSD). В допълнение към факта, че това гарантира, че съдържанието му се изчиства при рестартиране, това също допринася за производителността, например при компилиране на програми, чиито временни продукти не се записват на диск, а се поставят във виртуална директория като / tmp / obj.

В много системи ще видите директории като / usr / tmp и / var / tmp. Обикновено това са символични връзки към / tmp.

Стратегия за разделяне на файлова система

В заключение на разговора за йерархията на файловете трябва да се подчертае, че само директориите, изброени в параграфа Основна файлова система... Всички други директории - / usr, / opt, / var, / tmp и, разбира се, / home могат да представляват точките на монтиране на независими файлови системи на отделни физически носители или техните дялове.

Нещо повече, в локална мрежатези директории може да се намират дори на различни машини. Например, един компютър, действащ като сървър на приложения, може да съдържа директориите / usr и / opt в мрежата, друг файлов сървър, който може да съдържа всички домашни директории на потребителите и т.н.

Единственото, което остава да направите, е да решите кои файлови системи да бъдат изолирани от общото файлово дърво и защо това трябва да се направи. Отговорът на тези въпроси много зависи от използваната операционна система, а в случая с Linux - и от нейното разпространение. Независимо от това, общите принципи на разделяне на файловите системи могат да бъдат очертани. Защо трябва да помним за противопоставянето, от една страна, на неизменните и променящите се директории, от друга, на лесно възстановимите, трудно възстановими и практически невъзстановими данни. Нека направим този опит във връзка с потребителски работен плот - в случай на сървър, изчисленията ще бъдат значително различни.

Очевидно кореновата файлова система в директориите / bin, / boot, / etc, / root, / sbin, съдържаща лесно възстановими от разпространителя носители и практически непроменени данни, трябва да лежи на изолиран дисков дял. В Linux директорията / lib също трябва да бъде добавена. От друга страна, когато използвате GRUB като зареждащо устройство (независимо от операционната система), се препоръчва да преместите директорията / boot в отделен дял.

В стари източници за Linux можете да прочетете за друга причина за разпределяне на дял за директорията / boot и в самото начало на диска: поради невъзможността да се зареди ядрото с Lilo от номер на цилиндър, по -голям от 1023. В съвременни версии на зареждащи устройства, няма такива ограничения. Ако обаче създавате дял за / boot, има смисъл да го направите първи на диска и да поставите раздела за размяна директно зад него: това ще добави пет копейки към скоростта при извършване на смяна.

А също и от сферата на историята: изискването root и boot дяловете непременно да са първични също е премахнато отдавна. И тези файлови системи могат да се поберат на логически дялове в разширен дял.

Също толкова ясно е, че променливите клонове на файловата система - / var и / tmp - трябва да бъдат преместени извън главния дял. Освен това последното, както беше казано много пъти по -рано, като цяло е препоръчително да го поставите във файловата система в RAM (tmpfs или mfs). В случай, че директорията / var съдържа поддиректории за системи за управление на пакети, подобни на порт, като / var / abs, / var / cache / pacman / src и / var / cache / pacman / pkg в Archlinux, те също трябва да образуват свой собствен файл системи.

Сега директорията / usr, която съдържа или компонентите на основната система (както в BSD), или по -голямата част от потребителските приложения (както в повечето дистрибуции на Linux). Той съдържа лесно възстановими данни и по уважителна причина трябва да бъде практически непроменим и следователно, разбира се, заслужава да бъде подчертан в независим раздел. Освен това е препоръчително да се изолират от неговия състав, от една страна, поддиректориите / usr / X11R6 и / usr / local, от друга, поддиректориите за системи за управление на пакети, подобни на порт: / usr / порти, / usr / pkgsrc и / usr / pkg в BSD системи, / usr / portages в Gentoo Linux и т.н. Нещо повече, поддиректориите за поставяне на източниците, изтеглени от мрежата при изграждане на портове, трябва да бъдат отделени от последните - / usr / портове / разфайлове, / usr / pkgsrc / disfiles, / usr / portages / distfiles и други подобни.

В BSD системите освен това има смисъл да се отделят от директорията / usr поддиректориите / usr / src и / usr / obj, които съдържат източниците на базовите компоненти (включително ядрото) и техните междинни продукти за компилация, които са генерирани от процедурите make buildworld и make buildkernel. ...

И накрая, директорията / home, която съдържа нестабилни и често невъзстановими данни, трябва да бъде премахната от корена на файловата йерархия непременно. И винаги се опитвам да го поставя или на отделна част (в BSD), или на първичния дял (в Linux).

Предложената схема за разделяне на файлова система може да изглежда прекалено сложна. Въпреки това, той гарантира изолирането на лесно възстановими, трудно възстановими и невъзстановими данни, което улеснява преинсталирането на системата в случай на спешност и дори мигриране от система в система.

Допълнителният му плюс е, че за отделни клонове на файловото дърво, в зависимост от естеството на данните, разположени на него, в Linux можете да изберете физически оптимална файлова система. Например, няма смисъл да се използва нищо друго освен Ext2fs за дяла под / boot. Обикновено се препоръчва да се форматира основния дял със защитен и все пак най -съвместим Ext3fs. За директории с огромен брой малки файлове, като / var / abs в Archlinux, / usr / portages в Gentoo, е препоръчително да използвате ReiserFS: все пак умелото боравене с малки файлове е неговият профил. И в директорията / home, където могат да се появят огромни мултимедийни файлове (и които обикновено са много големи сами по себе си), XFS може да дойде в съда (въпреки че, както показват измерванията, ReiserFS изглежда доста приличен тук). Такива мерки могат да подобрят както надеждността на съхранението на данни, така и скоростта на файловите операции.

Потребителите на операционни системи BSD са обвързани с файлови системи от тип FFS без никаква алтернатива. Те обаче имат и място за маневри. Първо, чрез промяна на размера на блока и фрагмента от отделни файлови системи, което допринася или за изпълнението на дискови операции, или за спестяване на дисково пространство. И второ, някои клонове на файловото дърво (като / tmp или / usr / obj, противно на препоръките, могат безстрашно да бъдат монтирани в чисто асинхронен режим, като по този начин получавате процент или друга производителност.

За стандартите като цяло

Сред практикуващите програмисти съществува мнение, че стандартите в програмирането изобщо не са необходими, защото:

(1) първоначално те са безсмислени, тъй като техните автори не пишат компютърни програми;

(2) те ограничават инициативата на програмистите;

(3) програмистите винаги ще се съгласят без стандарти.

Може би на това мнение не е трябвало да се обръща внимание, ако не при две обстоятелства:

(1) изразяват го практикуващите, тоест точно тези, които „издават софтуер“;

(2) Горното мотивиране е открито от автора на тази статия в една от публикациите в Интернет, посветена на стандарта за езика за програмиране C, от което става ясно, че подобно мнение е широко разпространено „в международен мащаб“, а не само сред арогантните руски „супер програмисти“.

Думата "стандарт" обикновено се свързва с нещо материално (стандартни размери, стандартно електрическо напрежение и т.н.), докато компютърната програма е нематериален обект ("Новото нематериално") и може би стандартите в нематериалната сфера наистина са безсмислени?

Има обаче опровергаващ пример. Наборът от правописни правила на руския език е по същество стандарт, въпреки че не е одобрен от органите по стандартизация. Освен това, в допълнение към правилата (или, ако искате, изискванията) на правописа, има синтактични правила и най -важното - семантика. Последното добре илюстрира „детския“ въпрос: защо котката се нарича котка? На този въпрос има точен отговор: защото нашите предци са се съгласили с това; предците на британците се съгласиха да наричат ​​същия звяр котка, предците на германците - коте и т.н. И като цяло значението, или семантиката, или правилата за тълкуване на всяка дума или комбинация от думи е въпрос на съгласие.

Предназначение и "супер задача" на стандарта POSIX

Както подсказва името, POSIX (Portable Operating System Interface) е стандарт за интерфейса (интерфейса) между операционна система и приложна програма. Дните, когато програмистите са писали програми за "гола" машина (внедрявайки свои собствени пакети от програми за вход / изход, тригонометрични функции и т.н.), са изчезнали завинаги. Текстът на POSIX многократно подчертава, че стандартът не налага никакви изисквания към подробностите за внедряване на операционната система; може да се разглежда като съвкупност от споразумения между програмисти на приложения и разработчици на операционни системи. По този начин (отново, противно на доста разпространеното мнение), POSIX представлява интерес не само за разработчиците на операционни системи, но предимно за много по -голяма категория програмисти - прилагана.

Необходимостта от стандарт от този вид беше призната още през 80 -те години на миналия век, когато операционните системи UNIX станаха широко разпространени. Оказа се, че въпреки че тази система е замислена като единна система, разликите между нейните специфични реализации доведоха до факта, че приложните програми, написани за една система, не винаги могат да се изпълняват в друга. POSIX има за цел да реши точно този проблем, известен като проблем с преносимостта на софтуера. Първото издание на стандарта е издадено през 1988 г. (има превод, виж), в което цялото разнообразие от въпроси, свързани с преносимостта на програмата, беше разделено на две части: (1) интерфейс на приложната програма, (2) интерпретатор на команди и помощни програми (потребителски интерфейс); тези части се наричат ​​съответно POSIX.1 и POSIX.2.

Нека уточним, че в тази статия ще говорим само за стандарта за интерфейс на приложни програми, POSIX.1, второто (и последно до момента) издание, което е одобрено на 12 юли 1996 г.

Информационната част на стандарта също подчертава, че POSIX не е описание на интерфейса на някаква „идеална“ операционна система, а резултат от обобщаване и систематизиране на опита, натрупан при разработването на операционни системи UNIX. Също така POSIX не може да служи като ръководство или учебно ръководствоотносно операционните системи, въпреки че информативната част съдържа препоръки за програмисти и програмни фрагменти.

Стандартът директно заявява, че е невъзможно да се създаде пълноценна операционна система, като се фокусира единствено върху описаните в него интерфейсни функции. (По -специално POSIX.1 не разглежда проблеми като работа в мрежа и свързаните интерфейсни функции или графичен интерфейс.) Въпреки това, финансовите разходи, свързани с неподвижността на програмите и произтичащата от това нужда от унификация на интерфейса, са толкова големи, че повечето доставчици предпочитат поне някакъв стандарт, отколкото да няма такъв. Поради тази причина много разработчици на софтуер са склонни да се фокусират върху POSIX. Това позволява, ако не да премахне напълно неподвижността на програмите, то поне значително да намали неподвижната част от програмата.

Относно семантиката

Както бе обсъдено по -рано, POSIX може да се разглежда като набор от споразумения между разработчика на операционната система и програмиста на приложения. „Споразумение“ означава преди всичко една и съща интерпретация (семантика) на думи и изрази. По -долу са дадени примери, които илюстрират трудността при постигането на „споразумение“.

Как да предадем смисъл в превода

На първо място, трябва да се припомни, че стандартът POSIX е написан на английски език, което по своята същност предизвиква двусмислие (например същата дума може да бъде съществително, прилагателно и глагол), а „семантични капани“ чакат почти всяка страница. Добра илюстрация на казаното е пример от художествената литература. Едно от най -известните произведения на Оскар Уайлд, който блестящо използва тази функция на английски език, - Важността да бъдеш сериозен - известен на руски като „Значението на това да бъдеш сериозен“. но английско имеима второ значение: Искрен (сериозен) е името на един от героите и името може да се преведе по различен начин: „Колко е важно да си Ернст“. Има руска фамилия Серебряни и ако имаше фамилия Сериозна, преводът би бил напълно точен, с прехвърляне на двете значения.

Подобна е ситуацията и със самото име на стандарта: Портативна интерфейсна операционна система. Прилагателното Преносим (мобилен) се отнася както за операционната система, така и за приложната програма, но не може да се изрази толкова кратко на руски, може да се преведе като „Интерфейс на мобилна операционна система“ или „Интерфейс на операционна система, която осигурява мобилност на приложни програми ”. Вторият вариант по -добре отразява намеренията на разработчиците на стандарта, но в същото време се губи първото значение (по време на превода се запазва по -познатата първа опция).

Семантика на думата "стандарт"

Основният текст на стандарта се предхожда от преамбюла, която обяснява значението на думите IEEE стандарти2. Както следва от тези обяснения, има най-малко три семантични разлики от термина GOST на руски език:

(1) Интуитивно се смята, че ГОСТ има силата на закон, чието нарушение се преследва; POSIX е набор от изисквания, спазването на които е напълно доброволно.

(2) GOST е валиден, докато не бъде отменен (мнозина вероятно са чували израза „GOST не е отменен“); в преамбюла на POSIX се казва, че ако даден стандарт не е преразглеждан в продължение на 5 години, това означава, че въпросите, обсъждани в него, вероятно са загубили своята актуалност и той може да се счита за отменен автоматично;

(3) GOST е анонимен; уводната част на POSIX предоставя списък на тези, които са участвали в разработването на този стандарт, а също така предоставя адрес, на който могат да се изпращат искания за тълкуване; също така се посочва, че отговорът на всяко искане подлежи на процедура за одобрение (с други думи, авторите на стандарта се договарят помежду си, преди да дадат отговор).

По този начин преводът дори на такава добре позната дума като Стандарт с думата „стандарт“ изисква коментари.

Семантиката на думите „трябва“, „не е посочено“, „не е дефинирано“, „определено от изпълнението“

Раздел 2 от стандарта се нарича терминология и общи изисквания. Той съдържа дефиниции не само на специални термини (като „процес“ или „семафор“), но и такива на пръв поглед очевидни думи като „трябва“ или „може“. Тъй като POSIX.1 е стандарт за интерфейс, неговите изисквания се отнасят както за операционната система, така и за приложната програма. Изрично изискване се изразява с думата "трябва", например: "Ако успее, функцията link () трябва да върне нула." В този пример говорим за изискване за операционна система: функцията link () трябва да бъде внедрена, така че да връща нула при успех.

Термините „не е посочено“ и „не е определено“ изразяват една и съща идея, че стандартът позволява свобода на избор, но значението на тези термини е различно. Терминът „не е посочено“ означава, че говорим за някакви правилни (действия, програмни конструкции и т.н.), а терминът „недефиниран“ - за неправилни (погрешни). Информационната част на стандарта дава следното обяснение.

Терминът "неуточнено" означава, че се предполага, че са известни различни опции (резултати, резултати от извикване на функция и т.н.) и стандартът позволява всяка от тях; при конкретно изпълнение на операционна система може да бъде избрана всяка и такава система се счита за съответстваща на стандарта. Приложната програма (строго отговаряща на стандарта) трябва да бъде написана по такъв начин, че да работи правилно във всеки вариант; като такъв, терминът имплицитно изразява изискване за приложна програма.

Нека дадем пример: „Функцията readdir () трябва да върне показалец към структура, която се отнася до следващия елемент от директорията. Дали каталожните елементи с име „точка“ и „точка-точка“ се връщат или не, не се определят от стандарта. “ В този пример има четири възможни резултата и изискването за приложението е, че то трябва да бъде проектирано за всеки от тях.

Друг пример: „Ако функцията sigwait (), която инструктира да изчака сигнал с посочения номер, е извикана в няколко контролни нишки, тогава когато сигнал пристигне в не повече от една от тях, sigwait () трябва да се върне. В какъв вид контролен поток това ще се случи, не е посочено в стандарта. " В този пример може да има много повече възможни резултати, но всички те също са известни и изискването за приложението е, че то трябва да работи правилно за всеки резултат.

Терминът "не е дефиниран" означава, че дори много резултати не са известни, всеки резултат е възможен, дори катастрофален (например срив на системата, загуба на данни и т.н.). По същество този термин имплицитно изразява изискване за приложение да не използва съответните данни или конструкции. Например: "Ако аргументът dirp към readdir () не се отнася до текущо отворената директория, резултатът е неопределен."

Този пример изисква приложението да замести само отворена справка в директорията за аргумента на функцията readdir (); нарушаването на това изискване може да доведе до катастрофални последици и отговорността за това се носи от програмиста на приложението.

Ето още един пример: „Ако успее, функцията read () трябва да върне цяло число, представляващо действително прочетените байтове. В противен случай функцията трябва да присвои кода на грешката на errno и да върне -1, а съдържанието на буфера, посочено от buf, е неопределено. "

Стандартът забранява използването на данни от буфера в приложната програма в случай на грешка във функцията read (), а последствията от нарушаването на това изискване се възлагат на програмиста на приложения.

Значението на термина "дефинирано от изпълнение" е различно от интуитивното. Очевидно е, че в конкретна операционна система не може да има "неуточнен" или "неопределен" резултат, някакъв специфичен резултат ще бъде получен непременно. Терминът "дефиниран от внедряването" изразява изискването на стандарта за документация на операционната система: резултатът трябва не само да бъде посочен (разработчикът на операционната система ще трябва да направи това така или иначе), но и изрично отразено в системната документация.

Семантика по подразбиране

Нито един регулаторен документ не може да обхване цялото разнообразие от случаи, които могат да възникнат на практика, така че той неизбежно мълчи за нещо3. Например, описанието на функция може да каже, че нейният аргумент може да приема стойности от определен диапазон, но не се казва какво ще бъде резултатът, ако аргументът не попадне в този диапазон. Очевидно, за да се избегнат недоразумения, е необходимо да има еднаква семантика по подразбиране. В информативната част на стандарта има интересна фраза: „общоприетата семантика на неизпълнението е забранена“. Това твърдение противоречи на добре познатия десетгодишен лозунг „всичко е позволено, което не е изрично забранено“. Очевидно е толкова вкоренено в съзнанието на гражданите, че много, дори програмисти, не са съгласни с цитираното твърдение на стандарта. Междувременно, ако използването на която и да е конструкция не е изрично разрешено и не следва от описанието, тогава всеки практикуващ програмист осъзнава, че използването му е рисковано и ако не работи, не му хрумва да предяви иск.

Процеси и потоци на контрол

И двата термина изразяват идеята за паралелно изпълнение. Операционната система UNIX първоначално е замислена като многопотребителска, а програмите, стартирани от различни потребители, трябва да бъдат сигурно изолирани една от друга, за да не изкривят случайно „чужди“ данни. Тази изолация се осигурява от факта, че потребителската програма се изпълнява в рамките на процес, който се развива в нейното собствено виртуално адресно пространство. Дори ако програмата съдържа глобални данни, когато се стартира в различни процеси, те автоматично ще бъдат „разведени“ в различни адресни пространства.

Процесният механизъм обаче не е напълно задоволителен при програмиране на задачи в реално време. Приложение в реално време (работещо от името на един и същ потребител) често може да бъде естествено представено като едновременно изпълняващи се части, наречени „нишки“. Тяхната най -съществена разлика от процесите е, че всички контролни потоци се развиват в едно адресно пространство; това осигурява бърз достъп до глобални данни, но в същото време съществува риск от тяхното неволно изкривяване и за да се предотврати това, е необходимо да се спазва някаква дисциплина по програмиране. Съответните препоръки се съдържат в информативната част на стандарта.

Трябва да се подчертае, че идеята за многопоточност е внедрена в много операционни системи в реално време и се реализира по различни начини в смисъл, че всяка контролна нишка има различен набор от атрибути и интерфейсни функции; понякога терминът задача се използва вместо нишка. За да се избегне объркване, стандартът подчертава, че се занимава изключително с нишки POSIX, а имената на съответните интерфейсни функции са с префикс с pthread_ (например pthread_create (), pthread_join () и т.н.).

Съответствие със стандарта. Семантика на думата "съвпадение"

Интуитивно се смята, че ако два елемента са направени в съответствие с един и същ стандарт, тогава те гарантирано ще се „чифтосват“ помежду си и ще работят заедно по двойки; точно това е целта на въвеждането на интерфейсен (интерфейсен) стандарт. Тъй като POSIX е стандарт за интерфейс, можем да говорим за съответствие със стандарта както на операционната система, така и на приложната програма.

Стандартът POSIX.1 съдържа няколкостотин (ако не и хиляди) изисквания; се смята за очевидно, че ако поне един от тях не е изпълнен, тогава системата (или приложната програма) не отговаря на стандарта. В същото време до момента са написани толкова много операционни системи и приложни програми от клас UNIX, че едва ли е разумно да се изисква пълно съответствие в посочения смисъл. Трудностите при разработването на международен стандарт от този вид се влошават от наличието на различни национални езици. Дори и да забравим за приложните програми, предназначени за обработка на текстове на национални езици, почти всяка приложна програма трябва да издава някакъв вид диагностични съобщения и / или да възприема текстове, въведени от оператора.

• стриктно спазване на стандарта POSIX.1;
• съответствие с международната версия POSIX.1;
• съответствие с националната версия на POSIX.1;
• POSIX.1 съответствие с разширения.

Второ, много от интерфейсните съоръжения са по избор; Стандартът изисква опционалните интерфейсни функции да се обработват, както е предписано от стандарта, или винаги да връщат специален код за грешка, ENOSYS (което означава, че функцията не е изпълнена). Незадължителните съоръжения са разделени на няколко групи, всяка от които съответства на някаква конфигурационна константа, която е декларирана (чрез оператора #define) в съответния заглавен файл; това дава възможност да се установи дали е изпълнена функция по време на фазата на компилиране.

Описаният метод за постигане на мобилност не е изобретен от авторите на POSIX, но отдавна се използва на практика; на много операционни системи константи за конфигурация се използват за идентифициране на самата система или нейната версия. И тук стандартът не предлага нищо принципно ново, а само систематизира съществуващата практика.

Обекти на стандартизация и структура на стандарта

Накратко, обектите за стандартизация на POSIX.1 са имена и семантика. По -конкретно, говорим за следното.

• Имената на интерфейсните функции. 357 функции са стандартизирани, като 107 функции са взети от стандартните библиотеки на C (математически, обработка на низ, вход / изход и т.н.); тези функции се считат за част от стандарта POSIX.1, но те са Пълно описаниесъдържа се в стандарта за езика за програмиране C.
• Имена на типове системни данни. Тези имена са с наставка с _t.
• Имената на заглавните файлове, както и минималния състав на тези файлове.
• Имена на глобални променливи в цялата система (например errno).
• Символични имена на кодове за грешки, които могат да бъдат зададени по време на изпълнение на функция. Тези имена започват с буквата E (EPERM, ENOTEMPTY и т.н.).
• Конфигурационни имена на константи. Тези имена са с префикс _POSIX_.
• Символни имена на номера на сигнала; тези имена са с префикс SIG. В допълнение към 20 "традиционни" сигнала (SIGABRT, SIGALRM и др.), Стандартизирани са сигналите в реално време, чиито номера трябва да заемат определен непрекъснат диапазон от SIGRTMIN до SIGRTMAX включително, съдържащ поне RTSIG_MAX числа.
• Символни имена, съответстващи на стойностите на отделни аргументи на някои функции (например аргументът cmd на функцията fcntl () може да приема стойностите F_DUPFD, F_GETFD, F_GETLK и т.н.).
• Имена на макроси, константи, битови флагове, променливи на средата.

Като цяло стандартът се състои от две големи части с приблизително еднакъв обем. Първата половина - нормативната част - съдържа изискванията и препоръките на стандарта (18 раздела), втората - информативната част - съдържа приложения, които предоставят списък с препратки, коментари и обяснения към нормативната част, състава на заглавието файлове, пример за профил („проекция“) на стандарта (за Дания), характеристики и методология за измерване на изпълнението на най -важните функции, както и описание на допълнителни интерфейсни функции за работа с файлове в реално време; се очаква в бъдещи издания на стандарта тези функции да бъдат включени в нормативната част.

Страничната лента „Обобщения на клаузите на стандарта“ дава представа кои видове услуги на операционната система са обхванати от стандарта.

Заключение

Основното съдържание на стандарта POSIX е семантиката на интерфейсните функции. Стандартизирането на семантиката не е лесен бизнес сам по себе си (всеки знае колко е трудно да се постигне споразумение дори за двама души), а трудностите се влошават от факта, че в момента много хора участват в програмирането. Например парадигмата на паралелност се изразява с термини като „процес“, „задача“ и „контролен поток“, но от практическа гледна точка на програмирането „задача“ в операционната система IBM OS / 360 и реалната време операционната система VxWorks не е същата. и също. Друг пример са семафорите. Семафорите са двоични, целочислени („с брояч“) и взаимно изключване (което, между другото, програмистите наричат ​​помежду си „мутекси“, спонтанно се опитват да избегнат недоразумения). И целочислените семафори, например в операционната система VxWorks, изобщо не са същите като POSIX семафорите.

Авторите на стандарта POSIX, добре наясно колко е трудно да накарат хората да изоставят навиците си (което те наричат ​​„утвърдена практика“), декларират, че са съставили съгласувана и минимална система от интерфейсни функции, обхващащи традиционно повечето услуги предоставени от операционната система, подробно описват точната семантика на тези функции и канят всички да ги използват в разработките си4.

При четене на стандарта понякога се създава впечатлението, че някои от формулировките имат една единствена цел: да не се премахват някои приложни програми или операционни системи от категорията, отговаряща на стандарта. Такава цел наистина е поставена и изрично формулирана във Въведението: стандартът трябва да отчита преобладаващата практика, доколкото е възможно. Основната цел обаче все още е да се осигури мобилността на приложните програми.

За автора

Сергей Романюк - старши изследовател в Изследователския институт за системни изследвания, ръководител на стандартната група преводачи POSIX. Той може да се свърже с него по имейл на адрес: [защитен имейл]

1 Трябва да се добави, че работата по стандарта продължава много години; се идентифицират нови проблеми и те или са включени в една от съществуващите части, или са формализирани като отделна част, която впоследствие може да бъде отменена. Това се случи например с интерфейси в реално време, които първоначално бяха декларирани като POSIX.4, а по-късно включени в POSIX.1.

2 IEEE е организацията, разработила стандарта POSIX.

3 Тук "по подразбиране" означава безшумен, а не по подразбиране; не говорим за някакви подразбиращи се стойности, които са действително декларирани, а за липсата на препратки изобщо.

4 Руски превод на стандарта ще бъде публикуван в началото на 2000 г.

Литература

Международен стандарт ISO / IEC 9945-1 (ANSI / IEEE Std 1003.1) Второ издание. 1996-07-12. Информационни технологии - Преносим интерфейс за операционна система (POSIX) - Част 1: Програмен интерфейс за системни приложения (API).

М. И. Беляков, Ю. И. Рабовер, А. Л. Фридман. Мобилна операционна система. Директория. Москва, "Радио и комуникация", 1991.

ISO / IEC 9899: 1990, Езици за програмиране- C.

Секция 1	- Въведение
Раздел 2	- Терминология и определения
Раздел 3	- Функции за управление на процеси (създаване, замяна на изображение, завършване) и сигнали (управление на маски, реагиране на сигнали)
Раздел 4	- Идентификация (процеси, потребители, система, терминал), анкетиране на времето, изразходвано за изпълнение на процеса, проучване на променливите на средата.
Раздел 5	- Управление на файлове и директории
Раздел 6	- Входни и изходни функции
Раздел 7	- Функции за управление на терминала
Раздел 8	- Функции, заимствани от езиковия стандарт C
Раздел 9	- Достъп до бази данни на потребители и потребителски групи
Раздел 10	- Формати на данни за архивиране и обмен (tar и cpio)
Раздел 11	- Устройства за синхронизация: семафори, мютекси и променливи на състоянието
Раздел 12	- Функции за управление на паметта: закрепване и освобождаване на адресното пространство на процеса, картографиране на файлове в паметта, защита на паметта, споделена памет
Раздел 13	- Функции, свързани с процесите на планиране и потоците за управление
Раздел 14	- Управление на часовника и таймера
Раздел 15	- Управление на опашката за съобщения
Раздел 16	- Основни функции, свързани с управляващите потоци
Раздел 17	- Данни, специфични за нишката
Раздел 18	- Средства за унищожаване на контролните потоци

Относно: Операционни системи.
Въпрос: Не 8

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

Принципи на изграждане на ОС:

1.) Принцип на модулност- модул обикновено се разбира като функционално завършен елемент на системата, направен в съответствие с приетите интермодуларни интерфейси. По своята дефиниция, модулът приема възможността лесно да го замени с друг, при условие че посочените интерфейси са налични. До голяма степен разделянето на системата на модули се определя от използвания метод за проектиране на ОС (отдолу нагоре или обратно).

Привилегированите модули, модулите за повторно влизане и повторното влизане са от особено значение при изграждането на операционна система (повторното право е буквално повторно получаване на право; специален термин, който обозначава здравето на програмата; свойството на програмата да се изпълнява правилно, когато възниква рекурсивно (върнато) повикване от прекъсване).

Най -големият ефект от използването на този принцип е постижим в случай на едновременно разширяване на този принцип до операционната система, приложните програми и хардуера.

2.) Принцип на функционална селективност- определена част от важни модули е разпределена в операционната система, която трябва да бъде постоянно в RAM за по -ефективна организация на изчислителния процес. Тази част се нарича ядрото в операционната система, тъй като е в основата на системата. При формирането на състава на ядрото трябва да се вземат предвид две противоречиви изисквания. От една страна, най -често използваните системни модули трябва да бъдат включени в ядрото, от друга, броят на модулите трябва да бъде такъв, че количеството памет, заето от ядрото, да не е твърде голямо. В допълнение към софтуерните модули, които са част от ядрото и са постоянно разположени в RAM, може да има много други модули на системния софтуер, които се наричат транзит. Транзит софтуерни модулизарежда се в RAM само когато е необходимо и при липса свободно пространствомогат да бъдат заменени с други транзитни модули.

3.) Принципът на генериране на ОС:Същността на принципа се състои в организирането (избора) на такъв метод за първоначално представяне на програмата за управление на централната система на операционната система (ядрото и основните компоненти постоянно в RAM), което направи възможно персонализирането на тази част от системата за надзор въз основа на специфичната конфигурация на конкретен изчислителен комплекс и обхвата на задачите, които трябва да бъдат решени. Тази процедура рядко се извършва преди достатъчно дълъг период на работа на операционната система. Процесът на генериране се осъществява с помощта на специална програма генератор и подходящ език за въвеждане на тази програма, който позволява да се опишат софтуерните възможности на системата и конфигурацията на машината. Резултатът от поколението е пълна версияОПЕРАЦИОННА СИСТЕМА. Генерираната версия на ОС е съвкупност от системни набори от модули и данни.

4.) Принцип на функционално съкращение:Този принцип взема предвид възможността за извършване на една и съща работа по различни начини. Операционната система може да включва няколко типа монитори (модули за надзор, които контролират един или друг тип ресурс), различни средства за организиране на комуникация между изчислителните процеси. Наличието на няколко типа монитори, няколко системи за управление на файлове позволява на потребителите бързо и най -адекватно да адаптират операционната система към конкретна конфигурация на изчислителна система, за да осигурят най -ефективното зареждане на хардуера при решаване на определен клас проблеми, за да получат максимално производителност при решаване на даден клас проблеми.

5.) Принцип на виртуализация:изграждането на виртуални ресурси, тяхното разпределение и използване в момента се използва в почти всяка ОС. Този принцип ви позволява да представите структурата на системата под формата на специфичен набор от планиращи процеси и разпределители на ресурси (монитори) и да използвате единна централизирана схема за разпределение на ресурси.

Най -естественото и цялостно проявление на концепцията за виртуалност е концепцията виртуална машина ... Виртуалната машина, предоставена на потребителя, възпроизвежда архитектурата на реална машина, но архитектурните елементи в това представяне излизат с нови или подобрени характеристики, които по правило опростяват работата със системата. Характеристиките могат да бъдат произволни, но най -често потребителите искат да имат своя „идеална“ машина по отношение на архитектурни характеристики, в следния състав:

- виртуална памет с практически неограничен обем, еднаква по отношение на логиката на работа.

- произволен брой виртуални процесори, способни да работят паралелно и да взаимодействат по време на работа.

- произволен брой външни виртуални устройства, способни да работят с паметта на виртуална машина паралелно или последователно, асинхронно или синхронно по отношение на работата на един или друг виртуален процесор, който инициира работата на тези устройства.

Един от аспектите на виртуализацията е организацията на възможността за стартиране в дадена ОС приложения, които са разработени за други ОС. С други думи, говорим за организиране на няколко операционни среди.

6.) Принципът на независимост на програмите от външни устройства:този принцип сега се прилага в по-голямата част от операционните системи с общо предназначение. За първи път този принцип беше най -последователно приложен в операционната система UNIX. Той се прилага и в повечето съвременни компютърни операционни системи. Този принцип се състои във факта, че свързването на програми със специфични устройства се осъществява не на ниво излъчване на програмата, а през периода на планиране на нейното изпълнение. В резултат на това не е необходимо прекомпилиране, когато програмата работи с ново устройство, на което се намират данните.

7.) Принцип на съвместимост:един от аспектите на съвместимостта е способността на операционната система да изпълнява програми, написани за друга ОС или за по -ранни версии на тази операционна система, както и за друга хардуерна платформа. Необходимо е да се разделят въпросите бинарна съвместимости съвместимост на източникаприложения.

Двоичната съвместимост се постига, когато можете да вземете изпълнима програма и да я стартирате на друга ОС. Това изисква съвместимост на ниво инструкции на процесора и съвместимост на ниво системни повиквания и дори на ниво библиотечни повиквания, ако те са динамично свързани.

Съвместимостта на източника изисква подходящ преводач в системния софтуер, както и съвместимост с библиотека и системни обаждания. В този случай е необходимо да се прекомпилират съществуващите изходни текстове в нов изпълним модул.

Много по -трудно е да се постигне двоична съвместимост между процесори, базирани на различни архитектури. За да може един компютър да изпълнява програми на друг (например програма за компютър като IBM PC е желателно да се изпълнява на компютър, като например Apple Macintosh), този компютър трябва да работи с машинни инструкции, които първоначално не изпълнява разбирам. В този случай трябва да се изпълни процесор 680x0 (или PowerPC) двоичен кодпредназначени за процесора i80x86. Процесорът 80x86 има собствен декодер на инструкции, регистри и вътрешна архитектура. Процесорът 680x0 не разбира двоичния файл 80x86, затова трябва да избере всяка команда, да я декодира, за да определи дали

какво е предназначено да направи и след това изпълнете еквивалентната подпрограма, написана за 680 × 0.

Едно от средствата за гарантиране на съвместимостта на софтуера и потребителските интерфейси е спазването на стандартите POSIX, чието използване ви позволява да създавате програми в стил UNIX, които лесно да бъдат преносими по-късно от една система в друга.

8.) Принципът на откритост и мащабируемост:Отворена операционна система е достъпна за анализ както от потребители, така и от системни специалисти, които поддържат изчислителната система. Разширяема (модифицируема, разработена) операционна система позволява не само използване на възможностите за генериране, но и въвеждане на нови модули в състава й, подобряване на съществуващите и т.н. С други думи, трябва да е възможно лесно да се правят допълнения и промени, ако е необходимо, без да се нарушава целостта на системата. Подходът клиент-сървър за структуриране на операционната система с помощта на микроядрена технология предоставя отлични възможности за разширяване. В съответствие с този подход ОС е изградена като набор от привилегировани програми за управление и набор от непривилегировани услуги (сървъри). Основната част от операционната система остава непроменена и в същото време могат да се добавят нови сървъри или да се подобрят старите. Този принцип понякога се тълкува като разширяване на системата.

9.) Принцип на мобилност:операционната система трябва да бъде сравнително лесна за носене

за свързване от един тип процесор към друг тип процесор и от хардуерна платформа от един тип, която включва, заедно с вида на процесора и начина на организиране на целия компютърен хардуер (архитектура на изчислителната система), към друг тип хардуерна платформа . Имайте предвид, че принципът на преносимост е много близък до принципа на съвместимост, въпреки че те не са едно и също нещо. Писането на преносима операционна система е подобно на писането на всеки преносим код, но трябва да следвате някои правила:

- по -голямата част от операционната система трябва да се изпълнява на език, който е достъпен за всички системи, към които се планира да бъде пренесен в бъдеще. Това на първо място означава, че операционната система трябва да бъде написана на езика високо ниво, за предпочитане стандартизиран, например в C. Програма, написана на асемблер, обикновено не е преносима.

- важно е да минимизирате или, ако е възможно, да изключите тези части от кода, които директно взаимодействат с хардуера. Хардуерната зависимост може да има много форми. Някои очевидни форми на зависимост включват директно манипулиране на регистри и друг хардуер. И накрая, ако хардуерно зависимият код не може да бъде напълно изключен, той трябва да бъде изолиран в няколко добре локализирани модула. Хардуерно зависимият код не трябва да се разпространява в цялата система. Например, можете да скриете хардуерно зависима структура в програмируем абстрактен тип данни.

Въвеждането на стандартите POSIX имаше за цел да осигури преносимост на създадения софтуер.

10.) Принцип на изчислителна сигурност:Осигуряването на изчислителна сигурност е желана функция за всяка многопотребителска система. Правилата за сигурност дефинират свойства, като например защита на ресурсите на един потребител от други и задаване на квоти за ресурси, за да попречи на един потребител да поеме всички системни ресурси, като памет.

Осигуряването на защита на информацията от неоторизиран достъп е задължителна функция на мрежовите операционни системи.

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

КаквоPOSIX: независим от платформата системен интерфейс за компютърна среда POSIX (портативен операционен системен интерфейс за компютърни среди) е стандарт на IEEE (Институт на инженерите по електротехника и електроника), който описва системните интерфейси за отворени операционни системи, включително черупки, помощни програми и комплекти инструменти. В допълнение, POSIX стандартизира задачи за сигурност, задачи в реално време, административни процеси, мрежови функции и обработка на транзакции. Стандартът се основава на UNIX системи, но може да бъде внедрен и в други операционни системи. POSIX възниква като опит в цял свят добре известна организация IEEE насърчава преносимостта на приложенията в UNIX среди чрез разработване на абстрактен, независим от платформата стандарт. Например добре известната операционна система QNX в реално време отговаря на спецификациите на този стандарт.

Този стандарт подробно описва системата за виртуална памет VMS (Virtual Memory System), MPE (Multi-Process Executing) многозадачност и Конвергентна технология, произведена от операционна система ... (CTOS). По този начин POSIX всъщност е набор от стандарти, наречени POSIX.I –POSIX.12. Трябва също така да се отбележи, че POSIX.1 приема C за основен език.

Език за описание на системните функции на API.

По този начин програмите, написани в съответствие с тези стандарти, ще работят еднакво на всички POSIX-съвместими системи. В някои случаи обаче стандартът има само консултативен характер. Някои от стандартите са описани много строго, докато другата част само повърхностно разкрива основните изисквания.

Реализациите на операционната система на POSIX API са различни. Ако по-голямата част от UNIX системите първоначално отговарят на спецификациите на IEEE Standard 1003.1-1990, тогава WinAPI не е съвместим с POSIX. Въпреки това, за да поддържа този стандарт в операционната система MS Windows NT, е въведен специален модул за поддръжка на POSIX API, който работи на ниво привилегии на потребителските процеси.

Този модул осигурява преобразуване и прехвърляне на повиквания от потребителската програма към системното ядро ​​и обратно, като работи с ядрото чрез Win API. Други приложения, създадени с помощта на WinAPI, могат да предават информация на приложения на POSIX чрез стандартни механизми за I / O поток (stdin, stdout).

Няма свързани публикации ...