OSDev

Hello world!

Как всегда, извиняюсь за глупый вопрос.
Сейчас читаю Таненбаума для общего развития.
И по прочтению первой главы возник первый вопрос.
В чем смысл такого сложного вызова программ через fork+exec? Почему нельзя просто ExecuteFile, как в Wingdows?
Это просто для совместимости? Или для каких-нибудь финтов ушами? Или это - очень важная часть механизма защиты?
(Я имел не так много дел с *nixами, так что если совсем глупость ляпнул - извините)

Спасибо.

_________________
Found a CPU. LAPIC ID: 00

Это желание левой пятки Таненбаума. :)

форк делает разветвление процесса. Это такая простая идея потоков и процессов в nix системах.
После вызова этой функции, текущий процесс с его стеком, данными, кодом клонируется и запускается на выполнение на команду после форка. А тем временем в оригинальном родительском процессе тоже происходит возврат, но уже обычный.
Такой финт позволяет держать все процессы например в менеджере процессов. Это как файл svchost.exe в Windows он в себе в буквальном смысле содержит другие exe программы. Ну это конечно мое грубое описание.

На самом деле так могло и не быть.

Таненбаум рекламирует свою ОСь в своей книге.
Ты почитай из его книги выборочно про файловые системы, планирование задач, методико разделение на компоненты, что такое микроядро. И начинай сам потихоньку писать свою ось. Так будет познавательней.

StasBaybak - спасибо.
Но если писать свою ОСь без Форка - насколько это хуже (я не про стандарты)?
Что меня больше всего с форком смущает - пусть программа А запускает программу Б
при виндовской загрузке:
загрузить и запустить Б
через Форк:
скопировать данные программы А в процесс А1(куча времени!)
загрузить и запустить Б на место А1
Если программа А - гигант типа фотошопа, а Б - калькулятор :-???
А если оперативки на компе не хватает на вторую копию данных А, но хватает на целую программу Б, Б не загрузится?

_________________
Found a CPU. LAPIC ID: 00

Такого гениТального вызова, как форк, в других встречавшихся мне осях (а их немало было) не попадалось. Были системы, где такое организовать в принципе невозможно, были -- где возможно, причём более гибко, но для запуска нового процесса (задачи) у всех у них были нормальные вызовы, а не это извращение.

Что же касается копирования данных, которые Вы упомянули, то специально для реализации форка менеджер памяти униха (и всех осей, выросших из униха) предусматривает так называемое "копирование-при-записи". Т.е. для обоих (и родительского, и дочернего) процессов все области памяти родительского процесса становятся доступными только для чтения. При попытке записи происходит прерывание, ОС это дело анализирует и создаёт копию страницы, уже с доступом для записи, именно для того процесса, который произвёл эту самую запись.

Действительно, извращение...
Спасибо большое!

_________________
Found a CPU. LAPIC ID: 00

fork() в *NIX системах применяется как метод передачи от родительского процесса дочернему дескрипторов открытых файлов. В родительском процессе может быть создан либо pipe либо 2 соединенных сокета. Затем выполняется fork(), дескрипторы доступны и в родительском и в child процессе. В итоге, то что пишется в родителе доступно в child-е и наоборот. По необходимости. Но у fork() есть недостатки. Child процесс наследует не только дескрипторы, но и, к примеру, копию всего сегмента данных родительского процесса. В итоге, если появляется цепочка порожденных процессов, то как правило, child-процессы становятся все больше и больше. В книге Цирюлика "Анатомия параллелизма" проводился эксперимент. Сколько процессов может быть порождено в QNХ, с помощью fork(). Делался вывод, что мало. Я проанализировал пример и обнаружил что у него в примере fork() вызывался постоянно не в родительском, а в child процессе. Видимо в реализации fork() производятся какие-то распределения памяти.... В итоге порожденный процесс с каждым разом становится больше и больше. Тест с перенесенным повторным fork() в родителя дает совершенно иной результат. Такой же эффект, справедливости ради, наблюдается не только в QNX. Т.о. если вы используете связку fork() - exec() то все порождения по возможности должны делаться из одного процесса. И второе. Ввиду описанных проблем ряд операционок предлагают разновидности версий fork() типа vfork() и т.д. Это приводит к зоопарку. fork() в целом, конечно нужен, если вы реализуете UNIX-совместимую систему. Если же о совместимости речи не идет, то делать можно что угодно.

Статья про эксперимент с fork().

Полагаю, что проблема с fork в том, что при отложенном разделении памяти (копирование при записи) требуется, чтобы копируемые для потомка данные были теми, которые были на момент вызова fork. А ведь родитель свои данные мог и изменить к этому времни (наверно это так и происходит), поэтому при создании множества потомков, система должна выполнять дополнительное резервирование памяти для хранения "оригинальных" данных родителя.

Когда создавался этот вызов (конец 60-х), все программы были размером с калькулятор. О монстрах фотошопах тогда никто не думал. Думаю, Томпсон и Ритчи в первых реализациях просто облегчили себе задачу создания нового процесса, – копировали данные, стек и дескриптор родительского процесса, меняя только возвращаемый системным вызовом код. Облегчение в том, что код системного вызова ОС для порождения нового процесса получается простой и маленький, - не надо заново загружать сегмент кода и инициализировать процесс. Но с точки зрения идеологии порождения нового процесса, это один из наихудших вариантов, и я думаю, что форк вызывает оскомину даже у завзятых юниксоидов.


Системный вызов fork блокирует работу родителя до завершения копирования. Так что в смысле целостности данных всё должно быть ОК. Не ОК заключается в том, что два процесса разделяют общий доступ ко внешним данным/ресурсам и здесь надо тщательно следить, чтобы не было накладок ни в процессах, ни в ОС.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

exec типичен для примитивных систем, работающих на мелких машинах.

Монитор или шелл, делает exec usertask, после того, как разберёт параметры команды, откроет нужные файлы и.т.п
Программа, когда закончит работу, возвращает на место монитор вызовом exec monitor. Если почему-то не сможет, оператор дёрнет за хорошо известную пимпочку или просто перезагрузит машину, чтобы снова запустить монитор.

Более сложный случай:
Монитор делает exec fortran,
FORTRAN по завершении exec assembler,
ASSEMBLER завершается exec link
Связывающий загрузчик, если сохранил результат своей работы, запускает exec hellofortran
hellofortran завершается exec monitor