Новости :

Основы операционной системы UNIX - 06. Управление файловой системой

Основы операционной системы UNIX - 06. Управление файловой системой

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

Создание физической файловой системы

Команда mkfs создает файловую систему путем записи на указанное устройство (необходимо указать специальное символьное устройство). Файловая система создается на основе указанных в командной строке типа файловой системы (ТипФС), специфических_опций и операндов. Команда имеет следующий синтаксис:

mkfs [-F ТипФС][-V][-m] [-o специфические_опции]
   устройство размер [операнды]

Специфические опции и операнды зависят от конкретного типа создаваемой файловой системы. Их можно посмотреть на соответствующей странице справочного руководства (например, man mkfs_ufs для файловой системы ufs).

Основные опции и параметры команды mkfs представлены в табл. 14.

Таблица 14. Основные опции и параметры команды mkfs

Опция Назначение
-F Указывает тип файловой системы, которую необходимо создать. Тип файловой системы должен быть либо указан здесь, либо находится в файле таблицы стандартных файловых систем (/etc/vfstab в SVR4, /etc/fstab в других версиях UNIX) путем сопоставления устройства с записью в таблице.
-V Выдает результирующую командную строку, но не выполняет команду. Командная строка генерируется с использованием опций и аргументов, указанных пользователем, путем добавления к ним информации, взятой из таблицы стандартных файловых систем. Эта опция используется для проверки правильности командной строки.
-m Возвращает командную строку, использованную для создания файловой системы. Файловая система должна уже существовать. Эта опция обеспечивает средства получения команды, использованной при создании файловой системы. Для нее не применимы специфические_опции, размер и операнды.
-o Задает опции, специфические для указанного типа физической файловой системы.
устройство Задает специальное символьное устройство, на котором будет создана файловая система.
размер Задает количество 512-байтовых блоков в файловой системе. Максимальный размер многих физических файловых систем в UNIX - 4194304 блока размером 512 байт (или 2 Гбайта).

Проверка и восстановление целостности файловых систем

Программа fsck ищет и, автоматически или в интерактивном режиме, исправляет противоречия в файловых системах. Если файловая система находится в несогласованном состоянии, которое нельзя однозначно исправить, у пользователя спрашивают подтверждения перед попыткой выполнить каждое исправление. Следует иметь в виду, что некоторые исправления приводят к определенным потерям данных. Объем и серьезность потери данных можно определить по диагностическому сообщению. Стандартным действием при каждом исправлении является ожидание от пользователя утвердительного (yes) или отрицательного (no) ответа.

При использовании fsck файловая система должна быть неактивной (размонтирована или смонтирована только для чтения). Если это невозможно, необходимо обеспечить, чтобы машина находилась в состоянии покоя (без работающих пользователей) и чтобы сразу после завершения команды она была перезагружена, если исправляется критическая файловая система, например, корневая.

Команда fsck имеет следующий синтаксис:

fsck [-F ТипФС] [-V] [-m] [устройство ...]
fsck [-F ТипФС] [-V] [-o специфические_опции] [устройство ...]

Основные опции и параметры команды fsck представлены в табл. 15.

Таблица 15. Основные опции команды fsck

Опция Назначение
-F Задает тип проверяемой файловой системы. Если тип не указан, команда обращается к таблице стандартных файловых систем.
-V Выдает результирующую командную строку, но не выполняет команду. Командная строка генерируется с использованием опций и аргументов, указанных пользователем, путем добавления к ним информации, взятой из таблицы стандартных файловых систем.
-m Проверять, но не восстанавливать. Эта опция позволяет проверить, может ли файловая система быть смонтирована.
-o Позволяет задать опции, специфические для типа файловой системы.

Для работы команде fsck необходимо указывать специальное символьное устройство.

Корневая файловая система обычно проверяется при запуске автоматически. Система при запуске может автоматически проверять и другие физические файловые системы, для которых в таблице стандартных файловых систем указана необходимость такой проверки. Эта проверка может вестись параллельно, путем запуска отдельного процесса fsck для каждой проверяемой файловой системы с одним и тем же порядковым номером проверки. Параллельно имеет смысл проверять файловые системы, расположенные на разных физических дисках.

Монтирование и демонтирование физических файловых систем

Физические файловые системы, кроме корневой (/), считаются съемными (removable) в том смысле, что они могут быть как доступны для пользователей, так и не доступны. Команда mount уведомляет систему, что блочное устройство или удаленный ресурс доступны для пользователей в точке_монтирования, которая уже должна существовать; точка монтирования становится именем корня вновь смонтированного устройства или ресурса. Говорят, что эта команда монтирует или подключает физическую файловую систему или ресурс к общей логической файловой системе.

Команда mount имеет следующий синтаксис:

mount [-v | -p]
mount [-F ТипФС] [-V] [-o специфические_опции]
   {устройство|точка_монтирования}
mount [-F ТипФС] [-V] [-o специфические_опции]
   устройство точка_монтирования}

Команда mount, при вызове с аргументами, проверяет все аргументы, за исключением устройства, и вызывает специфический модуль монтирования для указанного типа файловой системы. При вызове без аргументов mount выдает список всех смонтированных файловых систем из соответствующей таблицы. При вызове с неполным списком аргументов (например, только с указанием устройства или точки_монтирования, или когда указаны оба эти аргумента, но не задан тип файловой системы), mount будет просматривать таблицу стандартных файловых систем в поисках недостающих аргументов. Затем она вызывает специфический модуль монтирования для соответствующего типа файловой системы.

Специфические опции монтирования зависят от типа физической файловой системы. Все физические файловые системы можно монтировать только для чтения (-o ro).

Обратная процедура по отношению к монтированию называется демонтированием и выполняется командой umount со следующим синтаксисом:

umount [-V] [-o специфические_опции]
   {устройство|точка_монтирования}

Для большинства типов файловых систем нет специфического модуля демонтирования. Если такой модуль существует, он выполняется; иначе файловая система демонтируется стандартным модулем.

Команды mount и umount воспринимают следующие основные опции:

-v

Выдает результаты в "новом" стиле. При этом дополнительно отображается тип файловой системы и флаги. Поля точка_монтирования и устройство переставлены.

-p

Выдает список смонтированных файловых систем в формате таблицы смонтированных файловых систем.

-F

Задает тип файловой системы для монтирования. Тип файловой системы должен быть либо задан, либо определяется по таблице стандартных файловых систем в ходе монтирования.

-V

Выдает результирующую командную строку, но не выполняет команду. Командная строка генерируется с использованием опций и аргументов, указанных пользователем, путем добавления к ним, при необходимости, информации, взятой из таблицы стандартных файловых систем.

-o

Задает специфические опции для указанного типа физической файловой системы.

Любой пользователь может вызывать команду mount для получения списка смонтированных файловых систем и ресурсов. Например:

[kravchuk@arturo 13:05:48 /]$ mount -p
/dev/dsk/c1t0d0s0 - / ufs - no 
rw,intr,largefiles,logging,onerror=panic,suid,dev=740040
/dev/dsk/c1t0d0s3 - /usr ufs - no 
rw,intr,largefiles,logging,onerror=panic,suid,dev=740043
/dev/dsk/c1t0d0p0:boot - /boot pcfs - no rw,nohidden,nofoldcase,dev=763050
/proc - /proc proc - no dev=2c00000
fd - /dev/fd fd - no rw,suid,dev=2cc0000
mnttab - /etc/mnttab mntfs - no dev=2dc0000
/dev/dsk/c1t0d0s1 - /var ufs - no 
rw,intr,largefiles,logging,onerror=panic,suid,dev=740041
swap - /var/run tmpfs - no dev=1
swap - /tmp tmpfs - no dev=2
/dev/dsk/c1t0d0s4 - /home ufs - no 
rw,intr,largefiles,logging,onerror=panic,suid,dev=740044
/dev/dsk/c2t0d0s1 - /fs ufs - no 
rw,intr,largefiles,logging,onerror=panic,suid,dev=740401

Только пользователь root может монтировать или демонтировать файловые системы.

Таблица смонтированных файловых систем

Команда mount по умолчанию добавляет запись в таблицу смонтированных файловых систем (файл /etc/mnttab в SVR4); umount удаляет запись из этой таблицы. Поля в таблице смонтированных устройств разделены пробелами и представляют блочное специальное устройство, точку монтирования, тип смонтированной файловой системы, опции монтирования и время, когда файловая система была смонтирована.

Таблица стандартных файловых систем

Таблица стандартных файловых систем (в файле /etc/vfstab или /etc/fstab, в зависимости от разновидности UNIX) описывает стандартные параметры для физических файловых систем. Поля в таблице (их 7) разделены пробелами и символами табуляции, и представляют, соответственно:

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

Если в поле нет значения, используется дефис (-). Рассмотрим пример записей из таблицы стандартных файловых систем из ОС Solaris 8:

#device           device                  mount   FS      fsck  mount   mount
#to mount         to fsck                 point   type    pass  at boot options
/dev/dsk/c1t0d0s0 /dev/rdsk/c1t0d0s0      /       ufs     1     no      logging
/dev/dsk/c1t0d0s3 /dev/rdsk/c1t0d0s3      /usr    ufs     1     no      logging
/dev/dsk/c1t0d0s1 /dev/rdsk/c1t0d0s1      /var    ufs     1     no      -
/dev/dsk/c1t0d0s4 /dev/rdsk/c1t0d0s4      /home   ufs     2     yes     logging
...

Получение информации о файловых системах

Для получения информации о смонтированных физических файловых системах используется команда df со следующим синтаксисом:

df [ -F ТипФС ] [ -abegklntV ] [ -o специфические_опции ]
   [ устройство | каталог | файл | ресурс ... ]

Опции и параметры определяют формат выдаваемой информации и файловые системы, о которых информирует команда. Чаще всего, команда df вызывается без опций или с опцией -k. Опция -k выдает информацию об объемах в килобайтах. Для каждой физической файловой системы выдается отдельная строка, включающая (при использовании опции -k) специальный файл или имя смонтированного ресурса, общий объем, использованный объем, доступный объем для использования обычными пользователями, процент свободного места в файловой системе и точку монтирования.

Рассмотрим примеры выполнения команды df в ОС Solaris:

[kravchuk@arturo 12:11:00 /]$ df -k
Filesystem            kbytes    used   avail capacity  Mounted on
/dev/dsk/c1t0d0s0     245983   20713  200672    10%    /
/dev/dsk/c1t0d0s3    3096090 1782106 1252063    59%    /usr
/dev/dsk/c1t0d0p0:boot
                       10797    1622    9175    16%    /boot
/proc                      0       0       0     0%    /proc
fd                         0       0       0     0%    /dev/fd
mnttab                     0       0       0     0%    /etc/mnttab
/dev/dsk/c1t0d0s1     491983  204863  237922    47%    /var
swap                  324832      16  324816     1%    /var/run
swap                  337828   13012  324816     4%    /tmp
/dev/dsk/c1t0d0s4    2305873 1021225 1238531    46%    /home
/dev/dsk/c2t0d0s1    6192197 5633827  496449    92%    /fs
[kravchuk@arturo 12:45:58 /]$ df
/                  (/dev/dsk/c1t0d0s0 ):  450540 blocks   120616 files
/usr               (/dev/dsk/c1t0d0s3 ): 2627968 blocks   338652 files
/boot              (/dev/dsk/c1t0d0p0:boot):   18350 blocks       -1 files
/proc              (/proc             ):       0 blocks     3615 files
/dev/fd            (fd                ):       0 blocks        0 files
/etc/mnttab        (mnttab            ):       0 blocks        0 files
/var               (/dev/dsk/c1t0d0s1 ):  574236 blocks   240784 files
/var/run           (swap              ):  647568 blocks    43108 files
/tmp               (swap              ):  647568 blocks    43108 files
/home              (/dev/dsk/c1t0d0s4 ): 2569298 blocks   379999 files
/fs                (/dev/dsk/c2t0d0s1 ): 1116738 blocks   688872 files
Комментарии: (0) | UNIX | 2006-04-04

Основы операционной системы UNIX - 07. Управление процессами

Основы операционной системы UNIX - 07. Управление процессами

Основным ресурсом компьютера является его процессор (или процессоры). В каждый момент времени один процессор может выполнять только один процесс. Организация планирования процессов так, чтобы за счет их переключения создавалась иллюзия одновременной работы нескольких процессов - одна из основных задач любой многопользовательской и многозадачной операционной системы.

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

Основой операционной системы UNIX является ядро. Ядро представляет собой специальную программу (или несколько программных модулей, в случае модульного ядра), которая постоянно находится в оперативной памяти и работает, пока работает операционная система. Ядро управляет всеми таблицами, используемыми для отслеживания процессов и других ресурсов. Ядро загружается в память во время начальной загрузки и немедленно запускает необходимые процессы, в частности процесс инициализации операционной системы - init.

Данные, связанные с процессом, также являются частью образа процесса. Некоторые из них хранятся в регистрах, обычно представленных регистрами процессора. Кроме того, существуют динамические области хранения данных (куча), выделяемые процессом по ходу работы при необходимости.

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

Регистры играют важную роль в работе процессов. Обычно выделяется четыре регистра, имеющих специальное значение:

Регистр Назначение
PC Программный счетчик - указывает на текущую строку кода.
PS Указывает состояние процессора.
SP Указывает на вершину стека.
FP Указывает на текущий фрейм стека.

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

Виртуальная память реализуется и автоматически поддерживается ядром ОС UNIX.

Типы процессов

В ОС UNIX выделяется три типа процессов: системные, процессы-демоны и прикладные процессы.

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

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

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

К прикладным процессам относятся все остальные процессы, выполняющиеся в системе. Как правило, это процессы, порожденные в рамках пользовательского сеанса работы. Важнейшим пользовательским процессом является начальный командный интерпретатор, который обеспечивает выполнение команд пользователя в системе UNIX.

Пользовательские процессы могут выполняться как в интерактивном (приоритетном), так и в фоновом режимах. Интерактивные процессы монопольно владеют терминалом, и пока такой процесс не завершит свое выполнение, пользователь не имеет доступа к командной строке.

В следующем примере, показывающем часть списка процессов в ОС Solaris 8, полужирным выделены системные процессы. В этой ОС системными являются процесс- планировщик (sched), процесс откачки страниц виртуальной памяти (pageout) и процесс, синхронизирующий файловые системы (fsflush). Пользовательские процессы представлены на более темном фоне. Все остальные процессы - это демоны, реализующие те или иные службы. Имена команд, начинающиеся с дефиса, представляют начальные командные интерпретаторы пользователей.

[kravchuk@arturo 13:48:53 /]$ ps -ecf | more
     UID   PID  PPID  CLS PRI    STIME TTY      TIME CMD
    root 0 0 SYS 96 Фев 23 ? 0:19 sched
    root     1     0   TS  58   Фев 23 ?        0:04 /etc/init -
    root 2 0 SYS 98 Фев 23 ? 0:08 pageout
    root 3 0 SYS 60 Фев 23 ? 87:49 fsflush
    root   411     1   TS  58   Фев 23 ?        0:00 /usr/lib/saf/sac -t 300
    root   259     1   TS  50   Фев 23 ?        2:20 /usr/sbin/nscd
    root   184     1   TS  46   Фев 23 ?        0:00 /usr/lib/netsvc/yp/ypxfrd
    root    68     1   TS  58   Фев 23 ?        0:02 
/usr/lib/sysevent/syseventd
    root   144     1   TS  59   Фев 23 ?        0:00 /usr/sbin/in.rdisc -s
    root   161     1   TS  58   Фев 23 ?        0:41 /usr/sbin/rpcbind
...
  markov  5724  5723   TS  48 12:07:16 pts/1    0:00 -bash
    root  3705   215   TS  54 09:46:57 ?        0:00 in.telnetd
    root  6804  6803   IA  48   Мар 25 ??       0:00 /usr/dt/bin/dtterm
    root    87   310   TS  59   Мар 19 ?        0:02 /usr/local/samba/bin/smbd 
-D -s/usr/local/samba/lib/smb.conf
    root 27210   215   TS  54   Мар 27 ?        0:00 in.telnetd
    root  3918   215   TS  54 10:11:00 ?        0:00 in.telnetd
kravchuk  3697  3679   TS  38 09:46:39 pts/14   0:00 -bash
...

Атрибуты процесса

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

Идентификатор процесса (PID)

Каждый процесс имеет уникальный идентификатор PID, позволяющий ядру системы различать процессы. Когда создается новый процесс, ядро присваивает ему следующий свободный (т.е. не ассоциированный ни с каким процессом) идентификатор. Присвоение идентификатора обычно происходит по возрастающий, т.е. идентификатор нового процесса больше, чем идентификатор процесса, созданного перед ним. Если идентификатор достигает максимального значения (обычно - 65737), следующий процесс получит минимальный свободный PID и цикл повторяется. Когда процесс завершает работу, ядро освобождает использовавшийся им идентификатор.

Идентификатор родительского процесса (PPID)

Идентификатор процесса, породившего данный процесс. Все процессы в системе, кроме системных процессов и процесса init, являющегося прародителем остальных процессов, порождены одним из существующих или существовавших ранее процессов.

Поправка приоритета (NI)

Относительный приоритет процесса, учитываемый планировщиком при определении очередности запуска. Фактическое же распределение процессорных ресурсов определяется приоритетом выполнения (атрибут PRI), зависящим от нескольких факторов, в частности от заданного относительного приоритета. Относительный приоритет не изменяется системой на всем протяжении жизни процесса (хотя может быть изменен пользователем или администратором) в отличие от приоритета выполнения, динамически изменяемого планировщиком.

Терминальная линия (TTY)

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

Процессы-демоны не связаны с терминалом.

Реальный (UID) и эффективный (EUID) идентификаторы пользователя

Реальным идентификатором пользователя данного процесса является идентификатор пользователя, запустившего процесс. Эффективный идентификатор служит для определения прав доступа процесса к системным ресурсам (в первую очередь к ресурсам файловой системы). Обычно реальный и эффективный идентификаторы совпадают, т.е. процесс имеет в системе те же права, что и пользователь, запустивший его. Однако существует возможность задать процессу более широкие права, чем права пользователя, путем установки бита SUID, когда эффективному идентификатору присваивается значение идентификатора владельца выполняемого файла (например, пользователя root).

Реальный (GID) и эффективный (EGID) идентификаторы группы

Реальный идентификатор группы равен идентификатору основной или текущей группы пользователя, запустившего процесс. Эффективный идентификатор служит для определения прав доступа к системным ресурсам от имени группы. Обычно эффективный идентификатор группы совпадает с реальным. Но если для выполняемого файла установлен бит SGID, такой файл выполняется с эффективным идентификатором группы-владельца.

Жизненный цикл процесса в UNIX и основные системные вызовы

Жизненный цикл процесса в ОС UNIX может быть разбит на несколько состояний. Переход из одного состояния в другое происходит в зависимости от наступления определенных событий в системе.

Возможны следующие состояния процесса:

  1. Процесс выполняется в пользовательском режиме. При этом процессором выполняются прикладные инструкции данного процесса.
  2. Процесс выполняется в режиме ядра. При этом процессом выполняются системные инструкции ядра от имени процесса.
  3. Процесс не выполняется, но готов к запуску, как только планировщик выберет его (состояние runnable). Процесс находиться в очереди на выполнение и обладает всеми необходимыми ему ресурсами, кроме процессора.
  4. Процесс находиться в состоянии сна (asleep), ожидая недоступного в данный момент ресурса, например завершения операции ввода-вывода.
  5. Процесс возвращается из режима ядра в режим задачи, но ядро прерывает его и производит переключение контекста для запуска более приоритетного процесса.
  6. Процесс только что создан системным вызовом fork и находится в переходном состоянии: он существует, но не готов к запуску и не находиться в состоянии сна.
  7. Процесс выполнил системный вызов exit и перешел в состояние зомби (zombie, defunct). Как такового процесса не существует, но остаются записи, содержащие код возврата и временную статистику его выполнения, доступную для родительского процесса. Это состояние является конечным в жизненном цикле процесса.

Процесс начинает свой жизненный путь с состояния 6, когда родительский процесс выполняет системный вызов fork. После того как создание процесса полностью завершено, процесс завершает "дочернюю часть" вызова fork и переходит в состояние 3 готовности к запуску, ожидая своей очереди на выполнение. Когда планировщик выбирает процесс для выполнения, он переходит в состояние 1 и выполняется в пользовательском режиме.

Выполнение в пользовательском режиме завершается в результате системного вызова или прерывания, и процесс переходит в режим ядра, в котором выполняется код системного вызова или прерывания. После этого процесс опять может вернуться в пользовательский режим. Однако во время выполнения системного вызова процесса в режиме ядра процессу может понадобиться недоступный в данный момент ресурс. Для ожидания доступа к такому ресурсу, процесс делает системный вызов sleep и переходит в состояние 4 - сна. При этом процесс добровольно освобождает вычислительные ресурсы, которые предоставляются следующему наиболее приоритетному процессу. Когда ресурс становиться доступным, ядро "пробуждает процесс", используя вызов wakeup, помещает его в очередь на выполнение, и процесс переходит в состояние 3 готовности к запуску.

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

Таким образом, после того как планировщик выбрал процесс на запуск, последний начинает свое выполнение в режиме ядра, где завершает переключение контекста. Далее состояние процесса зависит от предыстории.

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

Контекст процесса

Каждый процесс UNIX имеет контекст, под которым понимается вся информация, требуемая для описания процесса. Эта информация сохраняется, когда выполнение процесса приостанавливается, и восстанавливается, когда планировщик предоставляет процессу вычислительные ресурсы.

Контекст процесса в ОС UNIX состоит из нескольких частей:

  • Адресное пространство процесса в пользовательском режиме
    Сюда входят код, данные и стек процесса, а также другие области, например, разделяемая память или код и данные динамических библиотек.
  • Управляющая информация
    Ядро использует две основные структуры для управления процессом - proc и user. Сюда же входят данные, необходимые для отображения виртуального адресного пространства процесса в физическую память.
  • Среда процесса
    Переменные среды процесса, значения которых задаются в командном интерпретаторе или в самом процессе с помощью системных вызовов, а также наследуются порожденным процессом от родительского и обычно хранятся в нижней части стека. Среду процесса можно получать или изменять с помощью функций.
  • Аппаратный контекст
    Сюда входят значения общих и ряда системных регистров процессора, в частности, указатель текущей инструкции и указатель стека (см. в начале раздела).

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

Контекст переключается в четырех случаях:

  1. Текущий процесс переходит в состояние сна, ожидая недоступного ресурса.
  2. Текущий процесс завершает свое выполнение.
  3. Если после пересчета приоритетов в очереди на выполнение есть более высокоприоритетный процесс.
  4. Происходит пробуждение более высокоприоритетного процесса.

Первые два случая соответствуют добровольному переключению контекста и действия ядра при этом достаточно просты. Ядро вызывает процедуру переключения контекста из функций sleep или exit.

Третий и четвертый случаи переключения контекста происходят не по воле процесса, который в это время выполняется в режиме ядра и поэтому не может быть немедленно приостановлен. В этой ситуации ядро устанавливает специальный флаг runrun, который указывает, что в очереди находится более высокоприоритетный процесс, требующий предоставления вычислительных ресурсов. Перед переходом процесса из режима ядра в режим задачи ядро проверяет этот флаг и, если он установлен, вызывает функцию переключения контекста.

Приоритеты процессов

Планирование процессов и UNIX основано на приоритете процесса. Планировщик всегда выбирает процесс с наивысшим приоритетом. Приоритет процесса не является фиксированным и динамически изменяется системой в зависимости от использования вычислительных ресурсов, времени ожидания запуска и текущего состояния процесса. Если процесс готов к запуску и имеет наивысший приоритет, планировщик приостановит выполнение текущего процесса (с более низким приоритетом), даже если последний не "выработал" свой временной квант.

Ядро UNIX является непрерываемым (nonpreemptive). Это означает, что процесс, находящийся в режиме ядра (в результате системного вызова или прерывания) и выполняющий системные инструкции, не может быть прерван системой, а вычислительные ресурсы переданы другому высокоприоритетному процессу. В этом состоянии выполняющийся процесс не может освободить процессор "по собственному желанию", в результате недоступности какого-либо ресурса перейдя в состояние сна. В противном случае система может прервать выполнение процесса только при переходе из режима ядра в пользовательский режим. Такой подход значительно упрощает решение задач синхронизации и поддержки целостности структур данных ядра.

Каждый процесс имеет два атрибута приоритета: текущий приоритет, на основании которого происходит планирование, и относительный приоритет, называемый также поправкой приоритета - nice number, который задается при порождении процесса и влияет на текущий приоритет.

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

Создание процесса

Новый процесс создается в UNIX только путем системного вызова fork. Процесс, сделавший вызов fork, называется родительским, а вновь созданный процесс - порожденным. Новый процесс является точной копией родительского. При порождении (разветвлении) процесса проверяется, достаточно ли памяти и места в таблице процессов для данного процесса. Если да, то образ текущего процесса копируется в новый образ процесса, и в таблице процессов возникает новый элемент. Новому процессу присваивается новый уникальный идентификатор (PID). Когда изменение таблицы процессов ядра завершается, процесс добавляется к списку процессов, доступных для выполнения и ожидающих в очереди планировщика подобно другим процессам.

Порожденный процесс наследует от родительского процесса следующие основные характеристики:

  1. Способы обработки сигналов (адреса функций обработки сигналов).
  2. Реальные и эффективные идентификаторы пользователя и группы.
  3. Значение поправки приоритета.
  4. Все присоединенные разделяемые сегменты памяти.
  5. Идентификатор группы процессов.
  6. Терминальную линию.
  7. Текущий каталог.
  8. Корневой каталог.
  9. Маска создания файлов (umask).
  10. Ограничения ресурсов (ulimit).

Порожденный процесс отличается от родительского процесса следующими основными характеристиками:

  1. Порожденный процесс имеет свой уникальный идентификатор.
  2. Порожденный процесс имеет другой идентификатор родительского процесса, равный идентификатору породившего процесса.
  3. Порожденный процесс имеет свои собственные копии дескрипторов файлов (в частности, стандартных потоков), открытых родительским процессом. Каждый дескриптор файла порожденного процесса имеет первоначально такое же значение текущей позиции в файле, что и соответствующий родительский.
  4. У порожденного процесса обнуляются счетчики времени, потраченного системой для его обслуживания.

Системный вызов fork завершается неудачей и новый процесс не порождается, если:

  • Создать процесс запрещает системное ограничение на общее количество процессов.
  • Создать процесс запрещает системное ограничение на количество процессов у одного пользователя.
  • Общее количество системной памяти, предоставленной для физического ввода-вывода, временно оказалось недостаточным.

При успешном завершении порожденному процессу возвращается значение 0, а родительскому процессу возвращается идентификатор порожденного процесса. В случае ошибки родительскому процессу возвращается -1, новый процесс не создается и переменной errno присваивается код ошибки.

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

Выполняемый файл состоит из заголовка, сегмента команд и сегмента данных. Данные (глобальные переменные) состоят из инициализированной и неинициализированной частей.

Если системный вызов exec закончился успешно, то он не может вернуть управление, так как вызвавший процесс уже заменен новым процессом. Возврат из системного вызова exec свидетельствует об ошибке. В таком случае результат равен -1, а переменной errno присваивается код ошибки.

Новый процесс наследует у процесса, вызвавшего exec, следующие основные характеристики:

  1. Значение поправки приоритета.
  2. Идентификатор процесса.
  3. Идентификатор родительского процесса.
  4. Идентификатор группы процессов.
  5. Терминальную линию.
  6. Текущий каталог.
  7. Корневой каталог.
  8. Маску создания файлов.
  9. Ограничения ресурсов.
  10. Счетчики времени, потраченного системой на обслуживание этого процесса.
  11. Блокировки доступа к сегментам файлов.

Сон и пробуждение

Процесс обычно переводится в состояние сна при обработке системной функции. Если для завершения обработки запроса требуется недоступный ресурс, процесс снимается с процессора и переводится в состояние сна.

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

События информируют о доступности того или иного ресурса. Как правило, события связаны с работой периферийных устройств. Наступление одного и того же события может ожидать несколько процессов. Поскольку переход из состояния в состояние акт скорее логический, то и пробуждаются все процессы ожидающие данное событие. Это приводит к смене состояния со "сна" на "готов к выполнению", и соответствующие процессы помещаются в очередь на запуск. Задачу выбора процесса для запуска решает планировщик.

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

Завершение выполнения процесса

Процесс завершает работу при выполнении системного вызова exit. Процесс может сам завершить свою работу, в соответствии с алгоритмом, либо может быть прекращен ядром.

При завершении процесса последовательно выполняются следующие действия:

  1. Отключаются все сигналы.
  2. В вызвавшем процессе закрываются все дескрипторы открытых файлов.
  3. Если родительский процесс находится в состоянии вызова wait, то системный вызов wait завершается, выдавая родительскому процессу в качестве результата идентификатор завершившегося процесса, и младшие 8 бит его кода завершения.
  4. Если родительский процесс не находится в состоянии вызова wait, то завершающийся процесс переходит в состояние зомби.

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

Если идентификатор процесса, терминальная линия и идентификатор группы процессов у завершающегося процесса совпадают, то всем процессам с тем же идентификатором группы процессов посылается сигнал SIGHUP. Тем самым, завершаются и все порожденные в приоритетном режиме процессы.

Родительскому процессу посылается сигнал SIGCHLD (завершение порожденного процесса). Этот сигнал пробуждает родительский процесс, если тот ожидает завершения порожденных процессов.

Получение информации о процессах

Для получения информации о состоянии процессов используется команда ps. Она имеет следующий синтаксис:

ps [-acdelfjLP]
   [-t список_терминалов]
   [-p список_идентификаторов_процессов]
   [-u|U список_идентификаторов_пользователей]
   [-g список_идентификаторов_лидеров_групп]
   [-G список_числовых_идентификаторов_групп]

Основные опции команды ps в системах SVR4 и BSD описаны в табл. 16.

Таблица 16. Опции команды ps

Опция Назначение
-a Предоставляет информацию обо всех процессах, кроме групповых, и не связанных с терминалом.
-d Предоставляет информацию обо всех процессах, исключая лидеров сеанса.
-e Предоставляет информацию обо всех процессах.
-l Генерирует длинный листинг.
-f Генерирует полный листинг.
-g список Выводит информацию только о процессах, для которых указаны идентификаторы лидеров групп. Лидер группы - это процесс, номер которого идентичен его идентификатору группы. Командный интерпретатор, запускаемый при входе в систему, является стандартным примером лидера группы.
-G список Предоставляет информацию обо всех процессах, имеющих отношение к указанным номерам групп.
-p список Предоставляет информацию по процессам с указанными идентификаторами.
-t список Предоставляет информацию по процессам, имеющим отношение к указанным терминалам.
-U список Предоставляет информацию обо всех процессах, имеющих отношение к указанным идентификаторам пользователей.
-u список Предоставляет информацию обо всех процессах, имеющих отношение к указанным именам пользователей.

Основные поля в результатах выполнения команды ps представлены в табл. 17.

Таблица 17. Основные характеристики процессов, предоставляемые командой ps

Заголовок Значение
ADDR Адрес процесса в памяти.
С Доля выделенного планировщиком времени ЦП.
COMD Имя команды и аргументы (для опции -f).
F Флаги (шестнадцатеричные), логическая сумма которых дает следующие сведения о процессе:
00 - процесс терминирован; элемент таблицы процессов свободен;
01 - системный процесс: всегда в основной памяти;
02 - процесс трассируется родительским процессом;
04 - родительский трассировочный сигнал остановил процесс; родительский процесс ждет [см. ptrace(2)];
08 - процесс не может быть разбужен сигналом;
10 - процесс в основной памяти;
20 - процесс в основной памяти; блокирован до завершения события;
40 - идет сигнал к удаленной системе;
80 - процесс в очереди на ввод-вывод.
NI Поправка приоритета.
PID Идентификатор процесса.
PPID Идентификатор родительского процесса.
PRI Текущий приоритет процесса.
S Состояние процесса:
B,W - процесс находиться в состоянии ожидания;
I - создание процесса;
O - процесс выполняется;
R - находиться в очереди готовых к выполнению процессов;
S - процесс не активен;
T - процесс трассируется;
X - ожидает дополнительной оперативной памяти;
Z - процесс "зомби".
STIME Время запуска процесса.
SZ Размер (в блоках по 512 байт) образа процесса в памяти.
TIME Общее время выполнения для процесса
TTY Терминальная линия процесса
UID Идентификатор пользователя владельца процесса
WCHAN Адрес события, которого ожидает процесс. У активного процесса этот столбец - пустой.

В зависимости от переданных опций и реализации, команда ps может выдавать и другие атрибуты. Команду ps может выполнять любой пользователь. Рассмотрим простой пример:

[kravchuk@arturo 15:59:30 /]$ ps
   PID TTY      TIME CMD
  3697 pts/14   0:00 bash
[kravchuk@arturo 15:59:33 /]$ ps -l
 F S   UID   PID  PPID  C PRI NI     ADDR     SZ    WCHAN TTY      TIME CMD
 8 S 31061  3697  3679  0  51 20 e3110048    499 e31100b4 pts/14   0:00 bash
[kravchuk@arturo 15:59:38 /]$ ps -p 5726
   PID TTY      TIME CMD
  5726 pts/1    0:00 mc

Управление приоритетом процессов

Во всех UNIX-системах пользователи могут при запуске процесса задавать значение поправки приоритета с помощью команды nice. (Говорят, что команда запускается "из- под" nice.) Эта команда имеет следующий синтаксис:

nice [-инкремент | -n [-|+]инкремент] команда [аргумент...]

Диапазон значений инкремента в большинстве систем - от -20 до 20. Если инкремент не задан, используется стандартное значение 10. Положительный инкремент означает снижение текущего приоритета. Обычные пользователи могут задавать только положительный инкремент и, тем самым, только снижать приоритет.

Пользователь root может задать отрицательный инкремент, который повышает приоритета процесса и, тем самым, способствует его более быстрой работе:

# nice -n -10 make

Сигналы: посылка и обработка

Сигналы обеспечивают механизм вызова определенной процедуры при наступлении некоторого события (аналогично прерываниям). Каждое событие имеет свой числовой идентификатор (обычно в диапазоне от 1 до 36) и соответствующую символьную константу - имя. При работе с сигналами необходимо различать две фазы:

  1. Генерация или посылка сигнала.
  2. Доставка и обработка сигнала.

Сигнал отправляется, когда происходит определенное событие, о наступлении которого должен быть уведомлен процесс. Сигнал считается доставленным, когда процесс, которому был отправлен сигнал, получает его и выполняет его обработку. В промежутке между этими двумя событиями сигнал ожидает доставки.

Сигнал может посылаться одним процессом другому (с помощью соответствующего системного вызова ) и будет доставлен, если оба процесса - одного пользователя или сигнал послан от имени пользователя root. Сигналы посылаются также ядром.

Ядро генерирует и посылает процессу сигнал в ответ на ряд событий, которые могут быть вызваны самим процессом, другим процессом, прерыванием или каким либо внешним событием. Основные причины отправки сигнала:

Исключительные ситуации

Выполнение процесса вызывает исключительну ситуацию, например, деление на 0.

Терминальные прерывания

Нажатие клавиш терминала, например, <Del>, <Ctrl+C>, <Ctrl+\>, вызывает посылку сигнала текущему процессу, связанному с терминалом.

Другие процессы

Процесс может посылать сигнал другому процессу или группе процессов с помощью системного вызова kill. В этом случае сигналы являются элементарной формой межпроцессного взаимодействия.

Управление заданиями

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

Квоты

Когда процесс превышает выделенную ему квоту вычислительных ресурсов или ресурсов файловой системы, ему посылается соответствующий сигнал.

Уведомления

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

Будильники

Если процесс установил таймер, ему будет послан сигнал, когда значение таймера станет равным 0.

Доставка и обработка сигнала

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

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

Доставка сигнала происходит после того, как ядро от имени процесса вызывает системную процедуру issig(), которая проверяет, существуют ли ожидающие доставки сигналы, адресованные данному процессу. Процедура issig() вызывается ядром в трех случаях:

  1. Непосредственно перед возвращением из режима ядра в пользовательский режим после обработки системного вызова или прерывания.
  2. Непосредственно перед переходом процесса в состояние сна с приоритетом, допускающим прерывание сигналом.
  3. Сразу же после пробуждения после сна с приоритетом, допускающим прерывание сигналом.

Если процедура issig() обнаруживает ожидание доставки сигнала, ядро вызывает функцию доставки сигнала, которое выполняет действие по умолчанию или вызывает специальную функцию sendsig(), запускающую обработчик сигнала, зарегистрированный процессом. Функция sendsig() возвращает процесс в пользовательский режим, передает управление обработчику сигнала, а затем восстанавливает контекст процесса для продолжения прерванного сигналом выполнения.

Работа с сигналами, связанными с исключительными ситуациями, незначительно отличается от описанной выше. Исключительная ситуация возникает при выполнении процессом определенной инструкции, вызывающей в системе ошибку. Если такое происходит, вызывается системный обработчик исключительной ситуации, и процесс переходит в режим ядра, почти так же, как и при обработке любого другого прерывания. Обработчик отправляет процессу соответствующий сигнал, который доставляется, когда процесс возвращается в пользовательский режим.

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

Основные сигналы

Информация об основных сигналах представлена в табл. 18.

Таблица 18. Основные сигналы

Сигнал Стандартная обработка Значение
SIGTERM
15
Завершение процесса Стандартный сигнал, посылаемый для остановки процесса.
SIGHUP
1
Завершение процесса Отключился терминал (или закрыто терминальное окно). Сигнал посылается всем не фоновым процессам, связанным с соответствующей терминальной линией.
SIGKILL
9
Завершение процесса Не перехватываемый сигнал, позволяющий завершить любой процесс.
SIGILL
4
Завершение процесса и сброс образа памяти На центральный процессор была послана запрещенная инструкция. Это могло быть следствием недопустимого перехода в машинном коде программы, например, попытки выполнить строку данных.
SIGTRAP
5
Завершение процесса и сброс образа памяти Была установлена ловушка точки прерывания процесса. Этим управляет системный вызов ptrace, который полезен для отладки.
SIGFPE
8
Завершение процесса и сброс образа памяти Была попытка выполнить запрещенную арифметическую операцию, например, взятие логарифма отрицательного числа или деление на 0.
SIGBUS
10
Завершение процесса и сброс образа памяти Ошибка на шине ввода-вывода. Обычно это является результатом попытки выполнить чтение или запись вне границ памяти программы.
SIGSEGV
11
Завершение процесса и сброс образа памяти Это нарушение сегментации - проклятие разработчиков программ! Оно означает, что вы попытались получить доступ к сегменту памяти запрещенным образом. Может быть, это было присваивание значения части сегмента кода или чтение из нулевого адреса.
SIGPIPE
13
Завершение процесса Программа попыталась выполнить чтение или запись в программный канал, другой конец которого уже завершил работу. Этот сигнал помогает завершить работу конвейера, когда одна из его команд дала сбой.
SIGALRM
14
Завершение процесса Программист может установить будильник, чтобы позволить вам в определенный момент времени выполнить какое-нибудь действие.
SIGCHLD
18
Игнорируется Сначала это был сигнал завершения работы дочернего процесса, но сейчас он означает изменение состояния дочернего процесса.
SIGTSTP
24
Остановка процесса Это запрос от терминала на остановку процесса. Посылка этого сигнала процессу происходит при нажатии комбинации клавиш Ctrl-Z.
SIGCONT
25
Игнорируется Этот сигнал указывает процессу на возобновление его работы. Процессу посылается либо команда fg, либо bg, а командный интерпретатор выполняет внутренний системный вызов wait для привилегированного процесса, либо не выполняет его для фонового процесса.

Детальная информация о сигналах представлена на страницах справочного руководства signal.

Процесс с помощью системного вызова signal() может задать нестандартный обработчик любого сигнала, кроме SIGKILL (9).

Посылка сигналов

Для посылки сигналов из командного интерпретатора используется команда kill. Она имеет следующий синтаксис:

kill [ -сигнал ] pid ...

Эта команда посылает указанный сигнал (по умолчанию - SIGTERM) всем процессам с указанными идентификаторами. Посылать сигнал можно и не существующему процессу - выдается предупреждение, но другим процессам сигнал посылается. Посылаемый сигнал задается по имени без префикса SIG или по номеру, например:

[kravchuk@arturo 16:56:55 /]$ echo $$
3697
[kravchuk@arturo 16:56:58 /]$ kill -STOP 3697

В результате текущий сеанс зависает.

Комментарии: (0) | UNIX | 2006-04-04

Рождение патриарха

Рождение патриарха

Мне кажется, что история — великая наука. Она дает нам шанс пробежать за пару минут несколько десятков лет, ощутить сложность становления и развития чего-то великого, в очередной раз убедить себя в том, что развитие человечества — это заслуга личностей, которые смогли несмотря ни на что остаться преданными своей идее и довести ее до логического завершения. Я бы хотел, дорогие читатели, окунуться вместе с вами в атмосферу конца 60-х годов, во времена рождения одной операционной системы, которая сделала просто огромный прорыв в развитии современной компьютерной науки, под ее четким руководством зарождалась глобальная сеть и сообщество людей, ставшими новой социальной группой — интернет-сообществом.

Все началось в далеком 1965-м... Четыре года компания American Telegraph&Telephone Bell Labs совместно с фирмой General Electric и группой исследователей из Массачусетского технологического института создавала проект OS Multics (также именуемый MAC). Целью проекта было создание многопользовательской интерактивной операционной системы, обеспечивающей большое число пользователей удобными и мощными средствами доступа к вычислительным ресурсам. Эта операционная система основывалась на принципах многоуровневой защиты. Виртуальная память имела сегментно-страничную организацию, с каждым сегментом связывался уровень доступа. Для того чтобы какая-либо программа могла вызвать программу или обратиться к данным, располагающимся в некотором сегменте, требовалось, чтобы уровень выполнения этой программы был не ниже уровня доступа соответствующего сегмента. Впервые в Multics была реализована полностью централизованная файловая система. Увы, все попытки наладить в системе относительно дружественный интерфейс провалились. Было вложено много денег, а результат был несколько иной, нежели того хотели спонсоры из Bell Labs. Проект был закрыт. Кстати, участниками проекта значились Кен Томпсон и Денис Ритчи, о них речь пойдет далее.

Итак, приблизительно в это же время сотрудник Bell Labs Кен Томпсон (Ken Thompson), который вскоре стал известен всему миру как один из создателей Unix, заинтересовался компьютером PDP-7 производства Digital Equipment Corporation (DEC), считавшимся тогда бесперспективным. Томпсон решил построить операционную систему, которая поддерживала бы совместную работу коллектива программистов при проведении исследований и разработке новых продуктов. Чтобы заручиться поддержкой руководства, Томпсон пообещал, что разрабатываемую систему можно будет использовать как инструментальное средство для подготовки патентной документации.

Первый этап работы Томпсона увенчался созданием операционной системы, ассемблера для PDP-7 и нескольких утилит. Более того, он написал новую файловую систему, включил понятие inodes, подсистему управления процессами и памятью, обеспечивающую работу в системе двух пользователей в режиме разделения времени и простой командный интерпретатор. Так как создание новой операционной системой происходило после провалившегося проекта Multics, то разработчики решили в память былых заслуг назвать новую операционную систему Томпсона похожим именем — UNICS (Uniplexed Information and Computing System). Через некоторое время название сократили до UNIX. Но к сожалению, изобретение, как это часто бывает, уперлось в трудности материального плана. Во-первых, PDP-7 было арендовано отделом, а не куплено, и рано или поздно пришлось бы его отдавать, а во-вторых, операционка разрослась настолько, что системных ресурсов уже устаревшего на то время компьютера ей не хватало.

Поэтому в 1971 году Кен Томпсон вместе со своими друзьями перенесли свою последнюю модификацию UNIX на более совершенный Digital Equipment PDP-11/20. Если учесть, что ОС была написана на ассемблере, а физически взять и перенести весь этот код было невозможно, то можете себе представить, чего это стоило. Зато PDP-11 без проблем поддерживала большое количество залогинившихся пользователей, да к тому же позволила, наконец, написать простенький интерпретатор текстового процессора.

В ноябре 1971 года был опубликован первый выпуск полноценной документации по Юниксу. В соответствии с этим операционная система была названа Первой редакцией UNIX. Вторая редакция вышла довольно быстро — меньше чем через год. Система была полностью переписана на язык B, созданный Томпсоном под влиянием языка BCPL. Третья редакция ничем особенным не отличалась. Разве что заставила Дениса Ритчи с головой уйти в работу над созданием нового языка программирования, вследствие чего тот написал собственный язык, известный сейчас как C. Он позволял расширить функции своего предшественника — B, и именно на нем была написана четвертая редакция UNIX в 1973 году. Ритчи разработал этот язык общего назначения специально для дальнейшей работы над системой UNIX. Язык C легко адаптировался для различных архитектур и вскоре начал применяться на различных машинах. Если бы система UNIX не была написана на переносимом языке, каковым является C, она была бы жестко привязана к одному типу компьютеров, в данной случае к PDP-7. В результате использования С система стала легко переносимой, и в настоящее ее можно сравнительно небольшими усилиями адаптировать для машины новой архитектуры.

Впервые UNIX была перенесена на другую платформу в 1976 году. Ритчи и Джонсон адаптировали систему для Interdata 8/32, затем был выполнен перенос Unix на различные популярные архитектуры, в частности Intel 8086/8088/80x86 и даже на суперкомпьютер Cray.

После того как система UNIX была принята на вооружение Bell Labs, началось ее распространение и в остальных компаниях Bell System. Приблизительно в то же время ею заинтересовались престижные учебные заведения, такие как Калифорнийский и Массачусетский Технологический Институт. В 1975 году Western Electric Company, входящая в состав AT&T, начала продавать независимым производителям исходные коды UNIX и лицензии на использование системы. В то же время учебным заведениям, желающим получить в свое распоряжение UNIX, достаточно было приобрести магнитную ленту и затратить незначительные средства на поддержку системы. Таким образом стимулировались дальнейшие работы по модификации данной операционной системы.

В отличие от большинства операционных систем, UNIX, по крайней мере на начальных стадиях разработки, создавалась не для того чтобы способствовать увеличению сбыта компьютеров. В течение первых десяти лет существования UNIX AT&T не занималась продажей вычислительных средств. Некоторая "коммерциализация" UNIX явилась лишь результатом огромного спроса на систему.

Все существующие в настоящее время версии UNIX берут свое начало из двух источников — AT&T System V и BSD (Berkeley Software Distribution) v 4 — системы коммерческой и системы некоммерческой, если можно так сказать. Об этом читайте далее.

AT&T System V

В 1976 году появилась Version 6, которая стала использоваться в Bell System и в университетах, расположенных по всему миру. Version 6 стала основой для нескольких разновидностей UNIX, включая систему реального времени MERT и PWB UNIX.

В 1978 году Bell Labs выпустила version 7 UNIX, ставшую прообразом современных систем UNIX. В ней была впервые реализована оболочка Bourne, содержащая мощный интерпретатор командного языка, и средства интерактивного взаимодействия с пользователем.

В конце 80-х годов в составе AT&T была создана компания под названием USL (UNIX System Laboratories), которая подготовила исходные коды для промышленного выпуска систем UNIX, базирующихся на System V. Последней версией UNIX, выпущенной USL, стала UNIX System V Release 4.2 (известная как SRV 4.2), которая увидела свет в начале 90-х годов. Эта версия включала в себя графический пользовательский интерфейс (GUI) под названием UNIX Desktop. Кроме того, в состав SVR4.2 вошли драйверы для обслуживания аппаратуры персональных компьютеров, например часто используемых типов жестких дисков и устройств чтения компакт-дисков, а также средства поддержки многопроцессорных систем.

Соглашение, заключенное в 1991 году между USL и компанией Novell привело к созданию версии SVR4.2 под названием UnixWare, предназначенной для аппаратных платформ Intel. В настоящее время эта система доступна в двух конфигурациях: Personal Edition (PE) и Application Server (AS).

В 1993 году компания Novell приобрела у AT&T USL вместе с продуктом UNIX System V, включила USL в состав Novell UNIX System Group и приступила к дальнейшей работе над UnixWare.

В начале 1997 года Novell реализовала в UnixWare v2 поддержку системы каталогов NDS (Novell Directory Services), в результате чего была создана единая структура для работы UNIX и Netware (сетевой операционной системы Novell).

В 1996 году SCO приобрела у Novell права на дальнейшее развитие UNIX, после чего начала самостоятельно поддерживать исходные коды и технологические решения системы. Тем не менее, SCO не получила прав на использование торговой марки UNIX.

BSD v4

В конце 70-х начале 80-х годов AT&T уделяла мало внимания развитию UNIX. В это же время профессоры и студенты факультета компьютерных наук Калифорнийского университета усиленно занимались поддержкой и доработкой данной системы. Одним из главных разработчиков и "доработчиков" UNIX был в то время дипломник, а в будущем создатель BSD (Berkeley Software Distribution), президент и основатель Sun Microsystems — Билл Джой. Пожалуй, если бы не он, то вряд ли бы сейчас называли многие из нас себя юниксоидами. Так как только благодаря усилиям Билла и его друзей родилась FreeBSD.

Итак, параллельно с улучшением UNIX шла разработка системы, известной нам как FreeBSD. Когда в 1976 году в Университет Беркли попала "шестерка", там возникли местные юникс-гуру. Одним из них был Билл Джой.

Собрав своих друзей-программистов, Билл начал разработку собственной системы на ядре UNIX. Запихнув помимо основных функций кучу своих (включая компилятор Паскаля), он назвал всю эту сборную солянку Berkeley Software Distribution (BSD 1.0). Вторая версия BSD носила следы попыток изнасилования :-) (то есть частичной перезаписи ядра системы). Третья версия BSD основывалась на переносе UNIX Version 7 на компьютеры семейства VAX, что дало систему 32/V, легшую в основу BSD 3.x. Ну, и самое главное: при этом был разработан стек протоколов TCP/IP; разработка финансировалась Министерством Безопасности США.

Начиная с версии 4.1 (1980 год), Berkeley Software Distribution распространялась практически бесплатно — сначала среди пользователей, обладавших лицензией Bell Labs, а позже, переименовавшись в FreeBSD, и вовсе для всех практически бесплатно.

Позже, в 1982-м Билл Джой основал Sun Microsystems, забрал себе исходники платной версии BSD и начал делать SunOS, которая в 1990-х мутировала в Solaris. Отдельные версии Solaris сейчас распространяются бесплатно. Пожалуй, самым значительным вкладом в BSD стала разработка утилит, обеспечивающих дружественный пользовательский интерфейс. Этому вопросу практически не уделялось внимания при создании AT&T первых версий UNIX.

Комментарии: (0) | UNIX | 2006-04-04

Словарь юного POSIX'ивиста

Словарь юного POSIX'ивиста

Создан творческим гением посетителей Линуксфорума
Под редакцией Алексея Федорчука
Версия 1.0, 6 июня 2005 г.

Возможно, в этом словаре не охвачены все необходимые термины и непонятные слова, которые могут встретиться при первом знакомстве с POSIX-системами. Замечания, пожелания, предложения, дополнения и исправления можно высказать в специальной теме Линуксорума.

Аккаунт - учетная запись в базе данных пользователей, в которой определены его учетное имя (login) и пароль для идентификации при входе в систему, пользовательская командная оболочка (login shell - см. шелл) и каталог для пользовательских данных (т.н. домашний каталог). Один из аккаунтов носит имя root, он же - администратор или суперпользователь, он (и обычно только он) может выполнять общую настройку системы.

Атрибуты файла - набор свойств файла, составляющих часть его метаданных и служащих для разграничения доступа пользователей к различным частям системы. Важнейшими для пользователя являются атрибуты принадлежности (хозяин файла, группа пользователей, к которой он принадлежит, прочие пользователи) и атрибуты доступа (право на чтение, право на исполнение и право на измнение файла). Атрибуты доступа определяются независимо для каждого атрибута принадлежности.
Пример: пользователь, создавший файл, как правило, является его хозяином, имеет право на его чтение, исполнение (если файл исполняемый) и изменение; права пользователей из его группы обычно ограничиваются чтением и, если возможно, исполнением; прочие пользователи могут иметь право только на чтение файла (возможно , также и исполнение).

База данных - в рамках настоящего словаря достаточно представления о базе данных как о таблице, содержащей имена каких-либо объектов (каждое - в отдельной строке), и перечень их свойств, каждое из которых занимает свое поле. Разделителями полей могут выступать пробелы, символы табуляции, двоеточие, точка с запятой, и так далее. Множество конфигурационных файлов в *nix-системах представляют собой базы данных, хотя и очень простые.
Примеры: /etc/passwd - база данных пользовательских аккаунтов;
/etc/fstab - база данных монтируемых файловых систем.

Библиотека, в обиходе либа (library, libs) - набор программ для выполнения ряда операций, одинаковых для многих других программ. Они избавляют от необходимости заново программировать повторяющиеся действия в каждом пакете. Например, практически каждая программа выполняет действия по открытию, закрытию и записи файлов, и поэтому соответствующие функции объединяются в библиотеку, из которой заимствуются при необходимости. Отсутсвие нужной библиотеки - наиболее чатсая причина невозможности установки какого-либо пакета.
Примеры: libc - главная системная библиотека функций для включения в программы на языке Си, на котором написана большая часть *nix-систем, их утилит и приложений; в Linux представлена ее GNU-реализация - glibc.

Виртуальный терминал (виртуальная консоль) - способ разделения ресурсов компьютера, при котором перед пользователем предстает как бы несколько почти самостоятельных, хотя и виртуальных, устройств обработки ввода/вывода. На каждом виртуальном терминале может быть запущена отдельная программа, между ними возможен обмен данными. См. также консоль, терминал.

Графический режим - описание вывода на монитор изображений (в том числе и шрифтов) как набора экранных точек (пикселей). Характеристика графического режима - разрешение (число пикселей по горизонтали и вертикали). Противопоставляется текстовому режиму.

Группа (пользователей) - служит для установки единых прав доступа к файлам или каталогам (не обязательно более широких, чем у не-членов группы) для группы пользовательских аккаунтов (хотя может включать и одного пользователя). Например, во многих дистрибутивах Linux и во всех BSD-системах получить права root могут только пользователи определенной группы (wheel).

Дистрибутив (дистр, distribution, distro) - способ комплектации операционной системы дополнительными пакетами. Применяется преимущественно к разновидностям ОС Linux, реже - к BSD-системам. Дистрибутивы Linux, как правило, имеют имя собственное (название), отличаются программами установки, средствами управления пакетами, конфигурационными файлами и средствами их настройки. Дистрибутивы различных BSD-систем обычно отличаются только наборами пакетов и, иногда, программами инсталляции.
Примеры: Fedora Core, Mandriva, Debian GNU/Linux, Gentoo Linux.

Домашний каталог - место для хранения файлов данного пользователя, обычно /home/username.

Зависимость пакета - подразумевает, что для установки и (или) функционирования данной программы предварительно должен быть установлен иной пакет. Различают зависимости жесткие, без удовлетворения которых данная программа не может быть установлена или не будет работать, и мягкие, добавляющие ей дополнительные функции. Для разрешения зависимостей предназначены системы портов и пакетного менеджмента.
Пример: файловый менеджер mc зависит от нескольких библиотек, без которых он не сможет работать (жесткие зависимости); использование мыши в нем как указательного устройства обеспечивается пакетом gpm (мягкая зависимость).

Иксы - жаргонное, но точное название оконной системы X (X Window System), обеспечивающей работу графического режима в операционках *nix-семейства.

Исходники (source, в просторечии сырцы) - текст программы, написанной на языке программирования; для использования такая программа должна быть собрана - в это понятие входят компиляция и линковка - и инсталлирована, то есть включена в дерево файловой системы.

Каталог - особый файл, единственное содержание которого - список имен других файлов (или вложенных каталогов). Используются также термины директория и папка. Однако ни в коем случае не следует понимать каталог как физический контейнер для других файлов. Более точной метафорой будет понятие каталога как базы данных файлов, содержащих их идентификаторы (обычно - просто числа-номера в порядке создания) и соответствующие им имена.

Консоль - пережиток эпохи, "когда машины были большими". В настоящее время обычно - синоним терминала [ИМХО стоит либо исключить, либо отнести к виртуальным терминалам - ddc].

Корневая файловая система, корень (/ - не путать с пользователем root) - исходная точка построения иерархии файловой системы.

Локаль (locale) - совокупность параметров, зависящих от языкового окружения, страны, используемого набора символов, формата представления даты, времени, десятичной дроби, денежной единицы и т.д.
Примеры:
ru_RU.KOI8-R - локаль для русскоязычного окружения, страны России, набора символов KOI8-R:
ru_RU.CP1251 - то же, но для набора символов CP1251;
fr_FR.ISO8859-1 - локаль для франкоязычного окружения, страны Франции, набора символов Latin-1 (Западная Европа);
fr_BE.ISO8859-1 - то же самое, но для страны Бельгии.

Монтирование - процедура подключения ("вживления") файловой системы, находящейся, например, на компакт-диске (или любом другом носителе), в иерархию файлов и каталогов корневой файловой системы (см. также корень).

Морда -- англ. frontend, программа-надстройка над утилитой командной строки, маскирующая от пользователя прямую команду (серию связанных команд), и выглядит как ее заменитель. В ней опции и параметры команд реализованы как элементы графического (иногда текстового) интерфейса. Примеры:
k3b и прочие графические программы для записи CD/DVD - "морда" для команд mkisofs, создающей образ диска, и cdrecord, выполняющей непосредственно запись.

Пакет (package) - 1) программа или набор связанных программ, атом POSIX-системы, наименьшая часть, на которую ее можно разделить; в этом понимании пакет может быть добавлен в систему только целиком, и также целиком - удален; 2) скомпилированная, то есть готовая к установке и использованию программа - обычно противопоставляется исходникам.

Пакетный менеджмент, система управления пакетами - программа или комплекс программ для централизованной установки, обновления и удаления бинарных пакетов, а также для разрешения их зависимостей.
Примеры:
apt - система управления пакетами дистрибутива Debian, позднее приспособленная также для работы с пакетами rpm;
pkg_* - общее название комплекса утилит для установки (pkg_add), удаления (pkg_delete), создания (pkg_create) пакетов, и так далее; утилиты с такими (или похожими) именами используются во всех BSD системах и многих дистрибутивах Linux (например, в Slackware), хотя и представляют собой разные программы.

Патчить (patch) - изменение исходного текста пакета с помощью готового файла различия версий (т.н. diff-файла). Обычно применяется для апдейта старой версии до более новой, позволяя обойтись без скачивания всего пакета, а только файла обновлений.

Пользователь - некто, имеющий учетную запись (аккаунт) в базе данных пользователей.

Порт - набор правил для получения исходных текстов программы (см. исходники), ее сборки (сборка) и включения в дерево файловой системы (см. файловая иерархия). Обычно противопоставляется бинарным пакетам. Собственно порты применяются во FreeBSD, однако в других BSD-системах и многих дистрибутивах Linux используются сходные системы, обычно носящие иные имена собственные.
Примеры: портежи (portages) Gentoo Linux, pkgsrc NetBSD, ABS из Archlinux.

Раздел (partition) - непрерывная область дискового пространства, предстающая перед пользователем как отдельное дисковое устройство. Для архитектуры PC различают разделы физические, или первичные (primary partiotions) и логические.

Рекурсия - в узком (програмистском) смысле - определение функции через саму себя. В обиходе широко употребляется как определение некоего понятия таким же образом.
Пример: GNU - GNU is Not Unix (что по русски можно было бы перевести без всякой рекурсии: GNU - это вам не хрен антилопий:-)).

Репозиторий (repository) - централизованный архив программ (обычно собранных для какого-либо конкретного дистрибутива Linux).
Примеры: Debian - репозитарий для одноименного дистрибутива, Sysiphus - репозитарий программ для дистрибутива Altlinux.

Символическая ссылка - файл специального типа, не содержащий никаких данных, кроме определния пути к другому файлу или каталогу.

Тарбалл (tarball) - архив, то есть файл, содержащий в себе набор других файлов. информацию об их принадлежности к каталогам (см.), владельцах, правах доступа, времени создания и модификации. Почти всегда создается программой tar и обычно сжимается утилитами gzip и bzip2.
Примеры: filename.tar.gz - тарбалл, сжатый утилитой gzip, filename.tar.bz2 - то же, с использованием bzip2.

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

Терминал, текстовый терминал - совокупность устройства ввода (клавиатуры) и устройства вывода (экрана монитора). Обычно - синоним понятий консоль и виртуальный терминал, от которых следует отличать понятия эмулятора терминала и x-терминала.

Файл - в общем случае однозначно идентифицируемая последовательность байтов. Применительно к *nix-системам важно, что, помимо собственно данных, эта последовательность описывает также и служебную информацию о файле (метаданные), в том числе атрибуты файла. Столь же существенно, что в качестве файлов в *nix-системах предстают не только пользовательские данные, исполняемые программы, каталоги, но также устройства и даже протекающие процессы и средства взаимодействия между ними: все это суть отдельные типы файлов.

Файловая иерархия - не общепринятый, но логичный с точки зрения русского языка синоним второго значения файловой системы.

Файловая система - один из самых многозначных терминов. Для начинающего пользователя важно различать два значения:
1) метод физического размещения данных на носителе
примеры: ext2fs, ext3fs, ReiserFS - файловые системы Linux; ufs, ufs2 - файловые системы BSD;
2) логическая организация каталогов и файлов; в *nix-системах имеет древовидную (иерархическую) форму.
Примеры: корневая файловая система, файловая система /home, /usr и так далее.

Шелл (shell, командная оболочка, командный интерпретатор) - программа, обеспечивающая ввод, исполнение и получение результата от других программ (команд).

Эмулятор терминала - программа, воспроизводящая в графической среде (см.Иксы) свойства текстового терминала.

BSD (Berkeley Software Distributions) - родовое именование нескольких родственных ОС *nix-семейства.
Примеры: FreeBSD, NetBSD, OpenBSD, DragonFlyBSD.

GNU - проект создания свободной операционной системы, полностью воспроизводящей функциональность коммерческих Unix. Система эта (известная под названием Hurd) до сих пор не создана. Однако в рамках проекта было разработано множество системных утилит и приложений, вошедших в состав Linux и частично - BSD-систем, в частности, компилятор gcc.

Linux (образовано от имени Linus и X - родового компонента названий большинства *nix-систем) - этот термин имеет минимум три значения. Первое, практически общепризнанное, - название ядра операционной системы, разработанного Линусом Торвальдсом. Второе применяется по отношению к одноименному ядру и комплексу средств, обеспечивающих его базовую функциональность (Base Linux, часто также GNU/Linux [Читал - смеялся; пардон - ddc]). Третье - в сочетании с именем собственным применяется для названия определенной разновидности (дистрибутива) этой ОС.

*nix - собирательное название для операционных систем, родственных Unix, и отвечающих критериям совместимости со стандартом POSIX.

POSIX - Portable Operating Systems Interface (интерфейс переносимых операционных систем), набор стандартов, которым должна соответствовать как операционная система, претендующая на звание кросс-платформенной, так и приложения для нее. Создан на базе опыта разработки *nix-систем, и потому POSIX-системы, с некоторыми оговорками, обычно рассматриваются как их синоним. Примеры:: Linux, FreeBSD и другие BSD-системы, коммерческие Unix'ы.

Root (администратор, суперпользователь) - пользователь, имеющий права доступа ко всем каталогам и на изменение всех компонентов системы.

rpm (RPM Package Manager) - 1) система управления пакетами во многих распространенных дистрибутивах Linux (Red Hat/Fedora Core, Mandrake/Mandriva, ASPLinux, Altinux, Suse); 2) формат бинарных (то есть готовых к установке) пакетов для использования с программой rpm.

srpm - разновидность rpm-пакета, содержит исходные тексты программы и набор правил для сборки из них бинарного пакета.

Unix - родовое название семейства операционных систем, близко по смыслу к понятию *nix или POSIX-систем. Однако, в отличие от них, включает только те операционки, разработчики которых приобрели право на соответствующую торговую марку.
Примеры: AIX, Solaris, HP-UX.

X-сервер - основная часть Иксов, отвечающая за взаимодействие с "железом" компьютера - клавиатурой, мышью и видеосистемой.

X-терминал - обычно слабая машина, единственным назначением которой является запуск X-сервера и подключение к более мощной машине, на которой исполняются прикладные программы.

Комментарии: (0) | UNIX | 2006-05-29

Unix - "Курс молодого бойца" или "Сержантская школа"

Unix

Дмитрий Карпов, МИСиС

О чем это я?

Этот опус не претендует на полноту описания. Более того, в целях упрощения сознательно опущены некоторые подробности. Сначала цикл задумывался как FAQ (ЧаВо - часто задаваемые вопросы), но видимо получится "Курс молодого бойца" или "Сержантская школа".

Я попытался дать сравнительное описание разных операционных систем - именно этого на мой взгляд не хватает большинству учебников и технических пособий.

Не дожидаясь разоблачения со стороны опытных Unix'оидов, делаю добровольное признание - я не могу претендовать на роль великого знатока Unix, а мои знания в основном вокруг FreeBSD. Надеюсь, это не помешает.

Этот файл еще долго будет находиться в состоянии "under construction". :-)

Что такое Unix?

Unix - полноценная, изначально многопользовательская, многозадачная и многотерминальная операционная система. Точнее, это целое семейство систем, почти полностью совместимых друг с другом на уровне исходных текстов программ.

Какие бывают Unix'ы и на каких машинах они запускаются?

Unix платформа
SCO Unix (Santa Cruz Operation) i*86
Novell UnixWare (куплена SCO) i*86
Interactive Unix (куплен Sun) i*86
Linux i*86, Motorolla 680*0, DEC Alpha, IBM POWER-PC, Sun Sparc, ???
Семейство BSD: BSDI, FreeBSD, NetBSD, OpenBSD i*86, Acorn ARM, Sun Sparc, ???
Solaris Sun Sparc, i*86
AIX IBM RS/6000 и AS/400 на POWER-PC
IRIX SGI MIPS
Digital Unix (ранее Unix OSF/1) DEC Alpha
HP-UX Hewlett-Packard PA-RISC

Этот список не претендует на полноту, ибо кроме перечисленных есть еще множество менее распространенных Unix'ов и Unix-подобных систем, не говоря уже о древних Unix'ах для устаревших машин.

Условно можно выделить семейства System V и Berkeley. System V (читается "System Five") имеет несколько вариантов, последний по моим сведениям System V Release 4. Университет Berkeley славен не только разработкой BSD, но и большинства протоколов Internet. Впрочем, многие Unix'ы сочетают свойства обеих систем.

Где взять бесплатный Unix?

FreeBSD База - www.freebsd.org;
	есть также на ftp.kiae.su/FreeBSD/*-RELEASE/ и еще во множестве мест
OpenBSD ftp.openbsd.org
Linux	ftp.cs.msu.su/pub/Os/Linux/Slachware_3.1/
SCO	По моим сведениям, в Internet недоступен, но можно получить
	лицензию на бесплатное использование. Обратитесь на www.sco.com

Каковы основные отличия Unix от других OS?

Unix состоит из ядра с включенными в него драйверами и из утилит (внешних по отношению к ядру программ). Если надо изменить конфигурацию (добавить устройство, изменить порт или прерывание), то ядро пересобирают (перелинковывают) из обьектных модулей или (напр., во FreeBSD) из исходников. /* Это не совсем верно. Некоторые параметры пожно поправить без пересборки. Существуют также loadable kernel modules. */

В противоположность Unix'у Windows (если не уточняется, какая, то имеются в виду 3.11, 95 и NT) и OS/2 при загрузке фактически на ходу прилинковывают драйверы. При этом компактность собранного ядра и повторное использование общего кода на порядок ниже, чем у Unix. Кроме того, при неизменной конфигурации системы ядро Unix без переделки (потребуется изменить только стартовую часть BIOS) может быть записан в ПЗУ и выполняться _не_загружаясь_ в ОЗУ. Компактность кода особенно важна, т.к. ядро и драйверы никогда не покидают физическую оперативную память, не свопятся на диск.

Unix - самая многоплатформенная OS. WindowsNT пытается подражать ему, но пока это плохо удается - после отказа от MIPS и POWER-PC, W'NT остались всего на двух платформы - традиционная i*86 и DEC Alpha. Переносимость программ с одной версии Unix на другую ограничена. Неаккуратно написанная программа, не учитывающая различий в реализациях Unix, делающая необоснованные предположения типа 'переменная integer должна занимать четыре байта' может потребовать серьезной переделки. Но все равно это на много порядков легче, чем например пернести с OS/2 на NT.

Почему Unix?

Unix используется как в качестве как сервера, так и рабочей станции. В номинации серверов с ним конкурируют MS WindowsNT, Novell Netware, IBM OS/2 Warp Connect, DEC VMS и операционные системы мэйнфреймов. Каждая система имеет свою область применения, в которой она лучше других.

  • WindowsNT - для администраторов, которые предпочитают удобный интерфейс экономному расходованию ресурсов и высокой производительности.
  • Netware - для сетей, где нужна высокая производительность файлового и принтерного сервиса и не столь важны остальные сервисы. Главный недостаток - на сервере Netware трудно запускать приложения.
  • OS/2 хороша там, где нужен "легкий" сервер приложений. Ресурсов требует меньше чем NT, в управлении гибче (хотя в настройке может и сложнее), а многозадачность очень хорошая. Авторизация и разграничение прав доступа не реализованы на уровне ОС, что с лихвой окупается реализацией на уровне приложений-серверов. (Впрочем, зачастую остальные OS делают то же самое). Многие станции FIDOnet и BBS сделаны на базе OS/2.
  • VMS - мощный, ничем не уступающий Unix'ам (а во многом и превосходящий его) сервер приложений, но только для платформ VAX и Alpha фирмы DEC.
  • Мэйнфреймы - для обслуживания очень большого количества пользователей (порядка нескольких тысяч). Но работа этих пользователей как правило организована в виде не клиент-серверного взаимодействия, а в виде хост-терминального. Терминал же в этой паре скорее не клиент, а сервер (Мир Internet, N3 за 1996-й год). К преимуществам мэйнфреймов надо отнести более высокую защищенность и устойчивость к сбоям, а к недостаткам - соответствующую этим качествам цену.

Unix хорош для квалифицированного (или желающего стать таковым) администратора, т.к. требует знания принципов функционирования происходящих в нем процессов. Реальная многозадачность и жесткое разделение памяти обеспечивают высокую надежность функционирования системы, хотя в производительности файл- и принт-сервисов Unix'ы уступают Netware.

Недостаточная гибкость предоставления прав доступа пользователей к файлам по сравнению с WindowsNT затрудняет организацию _на_уровне_файловой_системы_ группового доступа к данным (точнее, к файлам), что на мой взгляд компенсируется простотой реализации, а значит меньшими требованиями к аппаратуре. Впрочем, такие приложения, как SQL-сервер решают проблему группового доступа к данным своими силами, так что отсутствующая в Unix возможность запретить доступ к _файлу_ конкретному пользователю на мой взгляд является явно избыточной.

Практически все протоколы, на которых основан Internet, были разработаны под Unix, в частности стек протоколов TCP/IP придуман в университете Berkeley.

Защищенность Unix при правильном администрировании (а когда это не так?) ни в чем не уступает ни Novell, ни WindowsNT.

Важным свойством Unix, которое приближает его к мэйнфреймам, является его многотерминальность, много пользователей могут одновременно запускать программы на одной Unix-машине. Если не требуется использовать графику, можно обойтись дешевыми текстовыми терминалами (специализированными или на базе дешевых PC), подключенными по медленным линиям. В этом с ним конкурирует только VMS. Можно использовать и графические X-терминалы, когда на одном экране присутствуют окна процессов, выполняющихся на разных машинах.

В номинации рабочих станций с Unix конкурируют MS Windows*, IBM OS/2, Macintosh и Acorn RISC-OS.

  • Windows - для тех, кто ценит совместимость больше эффективности; для тех, кто готов купить большое количество памяти, дискового пространства и мегагерц; для тех, кто любит не вникая в суть, щелкать мышкой по кнопочкам в окошке. Правда, рано или поздно все равно придется изучить принципы работы системы и протоколов, но тогда уже будет поздно - выбор сделан. Немаловажным преимуществом Windows надо признать также возможность украсть кучу программного обеспечения.
  • OS/2 - для любителей OS/2. :-) Хотя по некоторым сведениям OS/2 лучше других взаимодействует с мэйнфреймами и сетями IBM.
  • Macintosh - для графических, издательских и музыкальных работ, а также для тех, кто любит понятный, красивый интерфейс и не хочет (не может) разбираться в подробностях функционирования системы.
  • RISC-OS, прошитая в ПЗУ, позволяет не тратить время на инсталляцию операционной системы и восстановление ее после сбоев. Кроме того, практически все программы под ней очень экономно расходуют ресурсы, благодаря чему не нуждаются в свопинге и работают очень быстро.

Unix функционирует как на PC, так и на мощных рабочих станциях с RISC-процессорами, под Unix написаны действительно мощные САПР и геоинформационные системы. Своей масштабируемостью Unix из-за его многоплатформенности на порядок превосходит любую другую операционную систему из известных мне.

Основные понятия Unix

Unix базируется на двух основных понятиях: "процесс" и "файл". Процессы являют собой динамическую сторону системы, это субьекты; а файлы - статическую, это обьекты действия процессов. Почти весь интерфейс взаимодействия процессов с ядром и друг с другом выглядит как запись/чтение файлов. /* Хотя надо добавить такие вещи, как сигналы, разделяемая память и семафоры. */

Процессы нельзя путать с программами - одна программа (как правило с различными данными) может выполняться в разных процессах. Процессы можно весьма условно разделить на два типа - задачи и демоны. Задача - это процесс, который выполняет свою работу, стремясь побыстрее закончить ее и завершиться. Демон ждет событий, которые он должен обработать, обрабатывает произошедшие события и снова ждет; завершается он как правило по приказу другого процесса, чаще всего его убивает пользователь, дав команду "kill номер_процесса". /* В этом смысле получается, что интерактивная задача, обрабатывающая ввод пользователя, скорее похожа на демона, чем на задачу. :-) */

Файловая система

В старых Unix'ах отводилось 14 букв на имя, в новых это ограничение снято. В директории кроме имени файла находится его идентефикатор inode - целое число, определяющее номер блока, в котором записаны атрибуты файла. Среди них: номер пользователя - хозяина файла; номер группы; количество ссылок на файл (см.далее) даты и время создания, последней модификации и последнего обращения к файлу; атрибуты доступа. Атрибуты доступа содержат тип файла (см.далее), атрибуты смены прав при запуске (см.далее) и права доступа к нему для хозяина, одногрупника и остальных на чтение, запись и выполнение. Право на стирание файла определяется правом записи в вышележащую директорию.

Каждый файл (но не директория) может быть известен под несколькими именами, но обязательно лежащими на одном разделе. Все ссылки на файл равноправны; файл стирается, когда удаляется последняя ссылка на файл. Если файл открыт (для чтения и/или записи), то число ссылок на него увеличивается еще на единицу; так многие программы, открывающие временный файл, сразу удаляют его, чтобы при аварийном завершении, когда операционная система закрывает открытые процессом файлы, этот временный файл был удален операционной системой.

Есть еще одна интересная особенность файловой системы: если после создания файла запись в него шла не подряд, а с большими интервалами, то для этих интервалов место на диске не выделяется. Таким образом суммарный обьем файлов в разделе может быть больше обьема раздела, а при удалении такого файла освобождается меньше места, чем его размер.

Файлы бывают следующих типов:

  • обычный файл прямого доступа;
  • директория (файл, содержащий имена и идентефикаторы других файлов);
  • символьный линк (строка с именем другого файла);
  • блочное устройство (диск или магнитная лента);
  • последовательное устройство (терминалы, последовательные и параллельные порты; диски и магнитные ленты тоже имеют интерфейс последовательного устройства)
  • поименованный канал.

Специальные файлы, предназначенные для работы с устройствами как правило сосредоточены в директории "/dev". Вот некоторые из них (в номинации FreeBSD):

  • tty* - терминалы, в т.ч.:
    • ttyv<цифра> - виртуальная консоль;
    • ttyd<цифра> - DialIn терминал (обычно последовательный порт);
    • cuaa<цифра> - DialOut линия
    • ttyp<цифра> - сетевой псевдо-терминал;
    • tty - терминал, с которым ассоциирована задача;
  • wd* - жесткие диски и их подразделы, в т.ч.:
    • wd<цифра> - жесткий диск;
    • wd<цифра>s<цифра> - партиция этого диска (именуемая здесь "slice");
    • wd<цифра>s<цифра><буква> - раздел партиции;
  • fd<цифра>[<буква>] - floppy-диск;
  • rwd*, rfd* - то же самое, что wd* и fd*, но с последовательным доступом;

Иногда требуется, чтобы программа, запущенная пользователем, имела не права запустившего ее пользователя, а какие-то другие. В этом случае устанавливается атрибут смены прав на права пользователя - хозяина программы. (В качестве примера приведу программу, которая читает файл с вопросами и ответами и на основании прочитанного тестирует запустившего эту программу студента. Программа должна иметь право читать файл с ответами, а запустивший ее студент - нет.) Так, например, работает программа passwd, с помощью которой юзер может изменить свой пароль. Юзер может запустить программу passwd, она может произвести изменения в системной базе данных - а пользователь не может.

В отличие от DOS, в котором полное имя файла выглядит как "диск:\путь\имя", и RISC-OS, в которой оно выглядит "-файловая_система-диск:$.путь.имя" (что вообще говоря имеет свои преимущества), Unix использует прозрачную нотацию в виде "/путь/имя". Корень отсчитывается от раздела, с которого было загружено ядро Unix. Если мы собираемся использовать другой раздел (а на загрузочном разделе как правило находится только самое необходимое для загрузки), используется команда `mount /dev/файл_раздела директория`. При этом файлы и поддиректории, ранее находившиеся в этой директории, становятся недоступными, пока раздел не будет размонтирован (естественно, все нормальные люди используют для монтирования разделов пустые директории). Производить монтирование и размонтирование имеет право только супервизор.

При запуске каждый процесс может расчитывать, что для него уже открыты три файла, которые ему известны как стандартный ввод stdin по дескриптору 0; стандартный вывод stdout по дескриптору 1; и стандартный вывод stderr по дескриптору 2. При регистрации в системе, когда пользователь вводит имя и пароль, а ему запускается shell, все трое направлены на /dev/tty; позже любой из них может быть перенаправлен в любой файл.

Комадный интерпретатор

В Unix практически всегда входят два командных интерпретатора - sh (shell) и csh (C-подобный shell). Кроме них еще бывают bash (Bourne), ksh (Korn), и другие. Не вдаваясь в подробности, приведу общие принципы:

Все команды, кроме изменения текущей директории, установки переменных окружения (environment) и операторов структурного программирования - внешние программы. Программы эти как правило располагаются в каталогах /bin и /usr/bin. Программы системного администрирования - в каталогах /sbin и /usr/sbin.

Команда состоит из имени запускаемой программы и аргументов. Аргументы отделяются от имени команды и друг от друга пробелаим и табуляциями. Некоторые спецсимволы интерпретируются самим shell'ом. Спецсимволами являются " ' ` \ ! $ ^ * ? < > | & ; (еще какие?).

В одной командной строке можно дать несколько команд. Команды могут быть разделены ; (последовательное выполнение команд), & (асинхронное одновременное выполнение команд), | (синхронное выполнение, стандартный вывод stdout первой команды будет подан на стандартный ввод stdin второй).

Кроме того, можно брать стандартный ввод из файла, включив в качестве одного из аргументов "<файл" (без кавычек); можно направить стандартный вывод в файл, используя ">файл" (файл будет обнулен) или ">>файл" (запись будет произведена в конец файла). Сама программа не получит этого аргумента; чтобы узнать, что ввод или вывод переназначены, программа должна сама предпринять некоторые весьма нетривиальные телодвижения.

Руководства - man

Если надо получить информацию по какой-либо команде, дайте команду "man имя_команды". На экран это будет выдаваться через программу "more" - посмотрите, как с ней управляться на вашем Unix'е командой `man more`.

Дмитрий Ю. Карпов

Комментарии: (0) | UNIX | 2006-05-29


Страница 2 из 4«1234 »