Деятельность комитетов posix

Следует вспомнить, что наряду с версиями ОС UNIX, развивавшимися в компании AT&T (затем в USL, затем в Novell, затем...), исторически существовало еще направление BSD (Berkeley Standard Distribution), успешно поддерживаемое небольшой, но всемирно известной группой из университета г. Беркли (шт. Калифорния). В свое время (в конце 1970-х) университет получил из AT&T исходные тексты 16-разрядной ОС UNIX, на основе которых была произведена 32-разрядная система, которая сначала использовалась на компьютерах семейства VAX, а затем была перенесена на многие другие аппаратные платформы. В результате наборы системных вызовов UNIX AT&T и BSD стали значительно различаться.

Хотя большинство коммерческих реализаций UNIX основывалось на System V, UNIX BSD всегда был популярен в университетах, и общественность потребовала определения некоторого интерфейса, который являлся бы по сути объединением средств AT&T и BSD. Эта работа была начата Ассоциаций профессиональных программистов Открытых Систем UniForum, а затем продолжена в специально созданных рабочих группах POSIX (Portable Operating System Interface). В рабочих группах POSIX разрабатываются многие стандарты открытых систем, но наиболее известным и авторитетным является принятый ISO по представлению IEEE стандарт POSIX 1003.1, в котором определены минимальные требуемые средства операционной системы (по сути дела, UNIX).

Деятельность X/Open

Международная организация X/Open, которая выполняет многие работы, связанные с пропагандой и анализом использования открытых систем, кроме того, собирает и систематизирует де-юре и де-факто стандарты, имеющие промышленное значение, в так называемом X/Open Common Application Environment (CAE). Спецификаций интерфейсов средств, входящих в CAE, публикуются в многотомном документе X/Open Portability Guide (XPG).

Стандарт ANSI C

Очень важным в мире UNIX является принятый сначала ANSI, а потом и ISO международный стандарт языка программирования Си. Дело в том, что в этом стандарте специфицирован не только непосредственно язык Си, но и библиотеки, необходимые в каждой стандартной реализации. Поскольку с самого своего появления язык Си и соответствующие системы программирования были неразрывно связаны с ОС UNIX, то состав стандартных библиотек достаточно точно соответствует стандартной среде ОС UNIX.

Другие стандарты

Перечисленные четыре стандарта, только два из которых являются официально принятыми, наиболее авторитетны для производителей операционных систем, претендующих на совместимость с ОС UNIX. Особенностью этих стандартов является их полная машинная независимость.

Имеется другая разновидность стандартов де-факто, распространяемых на некоторый класс аппаратных архитектур. Примером такого стандарта может служить документ, принятый международной организацией SPARC International документ SPARC Complience Definition, содержащий машинно-зависимые уточнения к машинно-независимым спецификациям интерфейсов. Аналогичный документ разрабатывался организацией 88/Open, связанной с RISC-процессорами фирмы Motorola.

Среди других индустриальных де-факто стандартов для современных вариантов ОС UNIX наиболее важны фактический стандарт оконной системы, поддерживаемый X Cosortium, в основе которого находится лаборатория Масачусетского технологического института (MIT), являющаяся разработчиком системы X, а также спецификации интерфейсов инструментального средства разработки графических пользовательских интерфейсов OSF/Motif, разработанные в Open Software Foundation (OSF).

Кроме того, заметим, что в OSF разработан документ OSF Application Environment Specification (AES), содержащий спецификации интерфейсов ОС OSF/1, являющей собственной реализацией OSF ОС UNIX на базе новой микроядерной технологии (правда, до сих пор в этой реализации используются фрагменты исходного текста System V). AES является расширением SVID, POSIX 1003.1 и XPG.

8. ОС UNIX: стандартные команды

6.4 UNIX .pdf

9. 10.11.12.понятие процесса, создание и уничтожение процесса, системные вызовы fork(), exit(), wait().

8_Protsessy.pdf

Еще один способ создания нового процесса — клонирование текущего Perl-процесса с помощью UNIX-функции fork. Функция fork делает то же самое, что и системний вызов fork(2): создает клон текущего процесса. Этот клон (он называется порожденным процессом, а оригинал — родительским) использует тот же выполняемый код, те же переменные и даже те же открьггые файлы. Различаются эти два процесса по возвращаемому значенню функции fork: для порожденного процесса оно равно нулю, а для родительского — ненулевое (или undef, если этот системний вызов окажется неудачним). Ненулевое значение, получаемое родительским процессом,— это не что иное как идентификатор порожденного процесса.

Функция exit обеспечивает немедленный выход из текущего Perl-процесса. Она используется для прерывания Perl-программы где-нибудь посередине или — вместе с функцией fork — для выполнения Perl-кода в процессе с последующим выходом.

В результате выполнения системного вызова wait процесс приостанавливается до тех пор, пока один из непосредственно порожденных им процессов не завершится, или пока порожденный процесс, который находится в режиме трассировки, не остановится при достижении точки прерывания. Преждевременный выход из системного вызова wait происходит, если был получен сигнал; если же порожденный процесс остановился или завершился раньше вызова wait, то возврат происходит немедленно.

13.14. досистемная загрузка, системный загрузчик

9_Zagruzka_OS_UNIX.pdf

14. процесс init, его конфигурация и основные функции в системе

14. Init является родителем всех процессов. Его главная задача — создавать процессы по сценарию из файла /etc/inittab. В этом файле обычно содержатся записи, указывающие init породить getty для каждой линии, по которой пользователи могут входить в систему. Он также контролирует автономные процессы, требуемые какой-либо системе. Уровень выполнения — программная конфигурация системы, которая позволяет существовать только заданной группе процессов. Процессы, порождаемые init на каждом из таких уровней выполнения, определяются в файле /etc/inittab.[6]

По сути Init организует и поддерживает всё пользовательское пространство, что включает в себя также проверку и монтирование файловых систем, запуск нужных пользовательских служб и, переключение в пользовательскую среду, когда запуск системы завершится. Он похож на процессы init в Unix и BSD, от которых произошёл, но в некоторых случаях он изменён или переделан. В обычной системе Linux init с параметром, известном как уровень выполнения, принимающим значения от 1 до 6, и определяющим, какие подсистемы следует включить. Для каждого уровня выполнения есть собственные сценарии, которые регламентируют различные процессы, участвующие в установлении или снятии данного уровня, и именно эти сценарии считаются необходимыми для процесса загрузки. Сценарии Init обычно хранятся в каталогах с именами вида /etc/rc…. Главный файл конфигурации уровней для init — /etc/inittab.[7]

Во время загрузки системы он проверяет, описан ли уровень по умолчанию в /etc/inittab, а если же нет — запрашивает его через системную консоль. Затем он продолжает выполнять все соответствующие сценарии загрузки для этого уровня, включая загрузку модулей, проверку целостности файловой системы (которая монтировалась только для чтения), перемонтирование её для чтения-записи и настройку сети.[1]

В частности, по сообщению Red Hat, процесс init следует такой схеме:[2]

Он просматривает сценарий sysinit, который "устанавливает путь к среде, запускает swap, проверяет файловые системы и делает всё, что необходимо для инициализации системы. Это, в частности, системные и аппаратные часы, специальные процессы для последовательного порта и т. п.

Затем Init просматривает конфигурацию, указанную для заданного уровня выполнения.

После этого Init устанавливает исходную библиотеку функций для системы. Это определяет, как следует запустить или снять программу и как определить её PID.

Затем он запускает все предусмотренные процессы и создает сессию входа пользователя в систему.

После того, как он породил все заданные процессы, init переходит в режим ожидания и ждет одного из трёх событий:

Нормального или аварийного завершения порождённых процессов.

Сигнала аварии питания.

Запроса от /sbin/telinit на изменение уровня выполнения.[6]

Init

Init представляет собой специальный процесс с несколькими характерными особенностями. Это первый пользовательский процесс, запускаемый ядром, и он отвечает за запуск всех остальных процессов, которые, собственно, и позволяют извлекать определенную пользу из системы. Работа управляется файлом /etc/inittab и предполагает установку процессов, связанных с регистрацией пользователей, инициализацию сетевых служб наподобие FTP и HTTP и многое другое. Без такого рода процессов на компьютере мало что удастся сделать.

Важная сторона, характерная для данного проекта, заключается в том, что init является предком любого процесса в системе, Init порождает процесс регистрации, который, в свою очередь, порождает процесс входа, а тот — командный процессор, в рамках которого пользователь порождает любой требуемый процесс. Помимо прочего, это позволяет получить уверенность в том, что все элементы в таблице процессов ядра в конце концов заполнятся. Выполнение определенной обработки после завершения процесса находится в ведении родителя процесса; если родитель процесса уже завершился, обработкой занимается родитель родителя и т.д. В таком случае, за выполнение обработки после завершения процессов несет ответственность init, который никогда не завершается.

init

20044: Аргумент unused так называется в связи с необычным способом вызова данной функции. Функция init — не путать с процессом init — начинается как поток ядра, процесс, который выполняется как часть ядра. (Такая трактовка потока ядра может отличаться от таковой, принятой в многопотоковом программировании, — в этом смысле функция init не является потоком ядра.) Функция init похожа на усеченную main для нового процесса, и аргумент unused (указатель) является единственной заслуживающей внимания информацией, передаваемой в процесс — намного меньше, чем передается в обычный процесс через аргументы argc, argv и envp. Функция init не нуждается в дополнительной информации, поэтому и аргумент назван unused (т.е. неиспользованный).

Вот краткое резюме. Функция init является частью ядра, она выполняется в рамках ядра как независимая его часть; со всех точек зрения функция init — это часть кода ядра. Ни одна из перечисленных характеристик не относится к процессу init. В определенном смысле процесс init — специальный выделенный процесс, который не является частью собственно ядра. Код этого процесса находится в отдельном исполняемом образе, хранящемся на диске подобно любой другой программе. Несколько путает тот факт, что функция init, которая позже запускает процесс init, сама по себе запускается в виде процесса.

Поскольку идентификатор процесса (PID) со значением 0 уже зарезервирован для процесса idle (ожидание), функция init (и, следовательно, процесс init) получает PID, равный 1. (Идентификаторы процессов обсуждаются в главе 7.) Ядро во многих местах предполагает, что процесс с PID 1 — это idle, поэтому изменение PID для idle приводит к существенным накладным расходам.

20046: Обращение к lock_kernel (строка 17492 для однопроцессорной версии и 10174 — для мультипроцессорной) для выполнения нескольких нижеследующих строк без возможного влияния других частей ядра. Ядро будет разблокировано в строке 20053.

20047: Вызов do_basic_setup (строка 19916) с целью инициализации шин и порождения некоторых необходимых потоков ядра, а также выполнения других мелких действий.

20052: В настоящий момент ядро полностью инициализировано, поэтому free_initmem (строка 7620) избавляется от функций в разделе .text.init и данных в разделе .data.init ядра. Все функции, помеченные в начале как __initfunc, и все данные, помеченные как __initdata, в дальнейшем более не доступны, а занимаемая ими память освобождается и становится доступной для других целей.

20055: По возможности открывается консольное устройство, на которое процесс init будет выводить сообщения и с него считывать пользовательский ввод. Процесс init использует консоль исключительно для выдачи сообщений об ошибках, однако если вместо init запускается другой командный процессор, ему может потребоваться консоль для чтения данных, введенных пользователем. Если открытие консоли по open проходит успешно, /dev/console становится стандартным вводом (файловый дескриптор 0) для init.

20059: Вызов dup (создание копии) дважды для файлового дескриптора /dev/console, что дает возможность init использовать консоль дополнительно для стандартного вывода и стандартного вывода ошибок (файловые дескрипторы 1 и 2). Предполагая, что open в строке 20055 завершается успешно, в распоряжении init появляется первых три файловых дескриптора (стандартный ввод, стандартный вывод и стандартный вывод ошибок), связанные с системной консолью.

20067: Если в командной строке для ядра явно указывается путь к init (или другой аналогичной программе), init предпринимает попытку ее запуска.

Поскольку в случае успешного запуска целевой программы из execve возврата не происходит, управление на каждый последующий оператор будет передаваться, только если предыдущий оператор потерпит неудачу. В этой последовательности строк предпринимаются попытки нахождения init в различных местах, так сказать, с увеличением степени безрассудства: в первую очередь, в /sbin/init, стандартном месте расположения; затем еще в двух местах, где имеет смысл ожидать присутствие init — /etc/init и /bin/ink.

20072: Исчерпаны все места, где может находиться init. Если все докатилось до этой строки, значит, init понятия не имеет, где еще искать своего тезку. Скорее всего, что-то нехорошее случилось с компьютером. Предпринимается попытка создать взамен init интерактивный командный процессор /bin/sh. Самое лучшее, на что надеется init, пребывая в этой точке, — так это то, что привилегированный пользователь устранит неисправность и выполнит перезагрузку. (Будьте уверены, привилегированный пользователь надеется на то же самое.)

20073: init не смог создать даже командный процессор — определенно, что-то не так! Раз так, это неплохой повод запаниковать, т.е. обратиться к panic (строка 25563). Предпринимается попытка синхронизации дисков для приведения в согласованное состояние всех данных, после чего вся обработка останавливается. Компьютер может также перезагрузиться по истечении времени тайм-аута, определенного в параметрах ядра.

Это относится к программе init в стиле UNIX System V. Другие программы init могут вести себя иначе.

15. Устройство дисковой подсистемы

Опубликовано 21 Март 2011 автором Валера Леонтьев

Хочу немного поделиться своими познаниями в области дисковой подсистемы операционных систем, файловых систем и работы с ними в ОС Linux. Практическая ценность этой информации заключается в алгоритме простых и быстрых бэкапов разделов, а так же подвод к следующему посту про мультизагрузочную флэшку. Можно использовать этот материал как первую попытку разобраться принципе работы дисковой подсистемы. Ничего углубленного, все описано очень поверхностно и популярно

Материал разделен на три части: А — теория, Б — практика, В — создание мультизагрузочной флэшки.

А. Общая теория (популярно).