include <stdio.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>
char buffer [ BSIZE ];
extern int errno; /* код ошибки */
void timeout(nsig){ signal( SIGALRM, timeout ); }
void main(argc, argv) char **argv;{
int fd, n, trys = 0; struct stat stin, stout;
if( argc != 2 ){
fprintf(stderr, "Вызов: %s файл\n", argv[0]); exit(1);
}
if((fd = !strcmp(argv[1],"-")? STDIN : open(argv[1],O_RDONLY)) < 0){
fprintf(stderr, "Не могу читать %s\n", argv[1]); exit(2);
}
/* Проверить, что ввод не совпадает с выводом,
* hardcat aFile >> aFile
* кроме случая, когда вывод - терминал.
* Такая проверка полезна для программ-фильтров (STDIN->STDOUT),
* чтобы исключить порчу исходной информации */
fstat(fd, &stin); fstat(STDOUT, &stout);
if( !isatty(STDOUT) && stin.st_ino == stout.st_ino &&
stin.st_dev == stout.st_dev
){ fprintf(stderr,
"\aВвод == выводу, возможно потеряна информация в %s.\n",argv[1]);
exit(33);
}
А. Богатырев, 1992-95 - 217 - Си в UNIX
signal( SIGALRM, timeout );
while( trys < MAX_TRYS ){
alarm( WAIT_TIME ); /* заказать сигнал через 5 сек */
/* и ждем ввода ... */
n = read( fd, buffer, BSIZE );
alarm(0); /* отменили заказ сигнала */
/* (хотя, возможно, он уже получен) */
/* проверяем: почему мы слезли с вызова read() ? */
if( n < 0 && errno == EINTR ){
/* Мы были сбиты сигналом SIGALRM,
* код ошибки EINTR - сисвызов прерван
* неким сигналом.
*/
fprintf( stderr, "\7timed out (%d раз)\n", ++trys );
continue;
}
if( n < 0 ){
/* ошибка чтения */
fprintf( stderr, "read error.\n" ); exit(4);
}
if( n == 0 ){
/* достигнут конец файла */
fprintf( stderr, "Достигнут EOF.\n\n" ); exit(0);
}
/* копируем прочитанную информацию */
write( STDOUT, buffer, n );
trys = 0;
}
fprintf( stderr, "Все попытки провалились.\n" ); exit(5);
}
Если мы хотим, чтобы сисвызов не мог прерываться сигналом, мы должны защитить его:
#include <signal.h>
void (*fsaved)();
...
fsaved = signal (sig, SIG_IGN);
sys_call(...);
signal (sig, fsaved);
или так:
sighold(sig);
sys_call(...);
sigrelse(sig);
Сигналами могут быть прерваны не все системные вызовы и не при всех обстоятельствах.
6.4.3. Напишите функцию sleep(n), задерживающую выполнение программы на n секунд.
Воспользуйтесь системным вызовом alarm(n) (будильник) и вызовом pause(), который
задерживает программу до получения любого сигнала. Предусмотрите рестарт при получе-
нии во время ожидания другого сигнала, нежели SIGALRM. Сохраняйте заказ alarm, сде-
ланный до вызова sleep (alarm выдает число секунд, оставшееся до завершения предыду-
щего заказа). На самом деле есть такая СТАНДАРТНАЯ функция. Ответ:
А. Богатырев, 1992-95 - 218 - Си в UNIX
#include <sys/types.h>
#include <stdio.h>
#include <signal.h>
int got; /* пришел ли сигнал */
void onalarm(int sig)
{ printf( "Будильник\n" ); got++; } /* сигнал получен */
void sleep(int n){
time_t time(), start = time(NULL);
void (*save)();
int oldalarm, during = n;
if( n <= 0 ) return;
got = 0;
save = signal(SIGALRM, onalarm);
oldalarm = alarm(3600); /* Узнать старый заказ */
if( oldalarm ){
printf( "Был заказан сигнал, который придет через %d сек.\n",
oldalarm );
if(oldalarm > n) oldalarm -= n;
else { during = n = oldalarm; oldalarm = 1; }
}
printf( "n=%d oldalarm=%d\n", n, oldalarm );
while( n > 0 ){
printf( "alarm(%d)\n", n );
alarm(n); /* заказать SIGALRM через n секунд */
pause();
if(got) break;
/* иначе мы сбиты с pause другим сигналом */
n = during - (time(NULL) - start); /* прошло времени */
}
printf( "alarm(%d) при выходе\n", oldalarm );
alarm(oldalarm); /* alarm(0) - отмена заказа сигнала */
signal(SIGALRM, save); /* восстановить реакцию */
}
void onintr(int nsig){
printf( "Сигнал SIGINT\n"); signal(SIGINT, onintr);
}
void onOldAlarm(int nsig){
printf( "Звонит старый будильник\n");
}
void main(){
int time1 = 0; /* 5, 10, 20 */
setbuf(stdout, NULL);
signal(SIGINT, onintr);
signal(SIGALRM, onOldAlarm); alarm(time1);
sleep(10);
if(time1) pause();
printf("Чао!\n");
}
А. Богатырев, 1992-95 - 219 - Си в UNIX
6.4.4. Напишите "часы", выдающие текущее время каждые 3 секунды.
#include <signal.h>
#include <time.h>
#include <stdio.h>
void tick(nsig){
time_t tim; char *s;
signal (SIGALRM, tick);
alarm(3); time(&tim);
s = ctime(&tim);
s[ strlen(s)-1 ] = '\0'; /* обрубить '\n' */
fprintf(stderr, "\r%s", s);
}
main(){ tick(0);
for(;;) pause();
}
6.5. Жизнь процессов.
6.5.1. Какие классы памяти имеют данные, в каких сегментах программы они располо-
жены?
char x[] = "hello";
int y[25];
char *p;
main(){
int z = 12;
int v;
static int w = 25;
static int q;
char s[20];
char *pp;
...
v = w + z; /* #1 */
}
Ответ:
Переменная Класс памяти Сегмент Начальное значение
x static data/DATA "hello"
y static data/BSS {0, ..., 0}
p static data/BSS NULL
z auto stack 12
v auto stack не определено
w static data/DATA 25
q static data/BSS 0
s auto stack не определено
pp auto stack не определено
main static text/TEXT
Большими буквами обозначены сегменты, хранимые в выполняемом файле:
DATA - это инициализированные статические данные (которым присвоены начальные значе-
ния). Они помещаются компилятором в файл в виде готовых констант, а при запуске
программы (при ее загрузке в память машины), просто копируются в память из
файла.
BSS (Block Started by Symbol)
- неинициализированные статические данные. Они по умолчанию имеют начальное зна-
чение 0 (NULL, "", '\0'). Эта память расписывается нулями при запуске прог-
раммы, а в файле хранится лишь ее размер.
А. Богатырев, 1992-95 - 220 - Си в UNIX
TEXT - сегмент, содержащий машинные команды (код).
Хранящаяся в файле выполняемая программа имеет также заголовок - в нем в частности
содержатся размеры перечисленных сегментов и их местоположение в файле; и еще - в
самом конце файла - таблицу имен. В ней содержатся имена всех функций и переменных,
используемых в программе, и их адреса. Эта таблица используется отладчиками adb и
sdb, а также при сборке программы из нескольких объектных файлов программой ld.
Просмотреть ее можно командой
nm имяФайла
Для экономии дискового пространства эту таблицу часто удаляют, что делается командой
strip имяФайла
Размеры сегментов можно узнать командой
size имяФайла
Программа, загруженная в память компьютера (т.е. процесс), состоит из 3x сегментов,
относящихся непосредственно к программе:
stack
- стек для локальных переменных функций (автоматических переменных). Этот сег-
мент существует только у выполняющейся программы, поскольку отведение памяти в
стеке производится выполнением некоторых машинных команд (поэтому описание авто-
матических переменных в Си - это на самом деле выполняемые операторы, хотя и не
с точки зрения языка). Сегмент стека автоматически растет по мере надобности
(если мы вызываем новые и новые функции, отводящие переменные в стеке). За этим
следит аппаратура диспетчера памяти.
data - сегмент, в который склеены сегменты статических данных DATA и BSS, загруженные
из файла. Этот сегмент также может изменять свой размер, но делать это надо
явно - системными вызовами sbrk или brk. В частности, функция malloc() для раз-
мещения динамически отводимых данных увеличивает размер этого сегмента.
text - это выполняемые команды, копия сегмента TEXT из файла. Так строка с меткой #1
содержится в виде машинных команд именно в этом сегменте.
Кроме того, каждый процесс имеет еще:
proc - это резидентная часть паспорта процесса в таблице процессов в ядре операцион-
ной системы;
user - это 4-ый сегмент процесса - нерезидентная часть паспорта (u-area). К этому
сегменту имеет доступ только ядро, но не сама программа.
Паспорт процесса был поделен на 2 части только из соображений экономии памяти в ядре:
контекст процесса (таблица открытых файлов, ссылка на I-узел текущего каталога, таб-
лица реакций на сигналы, ссылка на I-узел управляющего терминала, и.т.п.) нужен ядру
только при обслуживании текущего активного процесса. Когда активен другой процесс -
эта информация в памяти ядра не нужна. Более того, если процесс из-за нехватки места
в памяти машины был откачан на диск, эта информация также может быть откачана на диск
и подкачана назад лишь вместе с процессом. Поэтому контекст был выделен в отдельный
сегмент, и сегмент этот подключается к адресному пространству ядра лишь при выполне-
нии процессом какого-либо системного вызова (это подключение называется "переключение
контекста" - context switch). Четыре сегмента процесса могут располагаться в памяти
машины не обязательно подряд - между ними могут лежать сегменты других процессов.
Схема составных частей процесса:
П Р О Ц Е С С
таблица процессов:
паспорт в ядре сегменты в памяти
struct proc[]
####---------------> stack 1
#### data 2
text 3
контекст: struct user 4
А. Богатырев, 1992-95 - 221 - Си в UNIX
Каждый процесс имеет уникальный номер, хранящийся в поле p_pid в структуре proc|-. В
ней также хранятся: адреса сегментов процесса в памяти машины (или на диске, если
процесс откачан); p_uid - номер владельца процесса; p_ppid - номер процесса-родителя;
p_pri, p_nice - приоритеты процесса; p_pgrp - группа процесса; p_wchan - ожидаемое
процессом событие; p_flag и p_stat - состояние процесса; и многое другое. Структура
proc определена в include-файле <sys/proc.h>, а структура user - в <sys/user.h>.
6.5.2. Системный вызов fork() (вилка) создает новый процесс: копию процесса, издав-
шего вызов. Отличие этих процессов состоит только в возвращаемом fork-ом значении:
0 - в новом процессе.
pid нового процесса - в исходном.
Вызов fork может завершиться неудачей если таблица процессов переполнена. Простейший
способ сделать это:
main(){
while(1)
if( ! fork()) pause();
}
Одно гнездо таблицы процессов зарезервировано - его может использовать только супер-
пользователь (в целях жизнеспособности системы: хотя бы для того, чтобы запустить
программу, убивающую все эти процессы-варвары).
Вызов fork создает копию всех 4х сегментов процесса и выделяет порожденному про-
цессу новый паспорт и номер. Иногда сегмент text не копируется, а используется про-
цессами совместно ("разделяемый сегмент") в целях экономии памяти. При копировании
сегмента user контекст порождающего процесса наследуется порожденным процессом (см.
ниже).
Проведите опыт, доказывающий что порожденный системным вызовом fork() процесс и
породивший его - равноправны. Повторите несколько раз программу:
#include <stdio.h>
int pid, i, fd; char c;
main(){
fd = creat( "TEST", 0644);
if( !(pid = fork())){ /* сын: порожденный процесс */
c = 'a';
for(i=0; i < 5; i++){
write(fd, &c, 1); c++; sleep(1);
}
printf("Сын %d окончен\n", getpid());
exit(0);
}
/* else процесс-отец */
c = 'A';
for(i=0; i < 5; i++){
write(fd, &c, 1); c++; sleep(1);
}
printf("Родитель %d процесса %d окончен\n",
getpid(), pid );
}
В файле TEST мы будем от случая к случаю получать строки вида
aABbCcDdEe или AaBbcdCDEe
что говорит о том, что первым "проснуться" после fork() может любой из двух процес-
сов. Если же опыт дает устойчиво строки, начинающиеся с одной и той же буквы - значит
____________________
|- Процесс может узнать его вызовом pid=getpid();
А. Богатырев, 1992-95 - 222 - Си в UNIX
в данной реализации системы один из процессов все же запускается раньше. Но не стоит
использовать этот эффект - при переносе на другую систему его может не быть!
Данный опыт основан на следующем свойстве системы UNIX: при системном вызове
fork() порожденный процесс получает все открытые порождающим процессом файлы "в нас-
ледство" - это соответствует тому, что таблица открытых процессом файлов копируется в
процесс-потомок. Именно так, в частности, передаются от отца к сыну стандартные
каналы 0, 1, 2: порожденному процессу не нужно открывать стандартные ввод, вывод и
вывод ошибок явно. Изначально же они открываются специальной программой при вашем
входе в систему.
до вызова fork();
таблица открытых
файлов процесса
0 ## ---<--- клавиатура
1 ## --->--- дисплей
2 ## --->--- дисплей
... ##
fd ## --->--- файл TEST
... ##
после fork();
ПРОЦЕСС-ПАПА ПРОЦЕСС-СЫН
0 ## ---<--- клавиатура --->--- ## 0
1 ## --->--- дисплей ---<--- ## 1
2 ## --->--- дисплей ---<--- ## 2
... ## ## ...
fd ## --->--- файл TEST ---<--- ## fd
... ## | ## ...
*--RWptr-->ФАЙЛ
Ссылки из таблиц открытых файлов в процессах указывают на структуры "открытый файл" в
ядре (см. главу про файлы). Таким образом, два процесса получают доступ к одной и
той же структуре и, следовательно, имеют общий указатель чтения/записи для этого
файла. Поэтому, когда процессы "отец" и "сын" пишут по дескриптору fd, они пользуются
одним и тем же указателем R/W, т.е. информация от обоих процессов записывается после-
довательно. На принципе наследования и совместного использования открытых файлов
основан также системный вызов pipe.
Порожденный процесс наследует также: реакции на сигналы (!!!), текущий каталог,
управляющий терминал, номер владельца процесса и группу владельца, и.т.п.
При системном вызове exec() (который заменяет программу, выполняемую процессом,
на программу из указанного файла) все открытые каналы также достаются в наследство
новой программе (а не закрываются).
6.5.3. Процесс-копия это хорошо, но не совсем то, что нам хотелось бы. Нам хочется
запустить программу, содержащуюся в выполняемом файле (например a.out). Для этого
существует системный вызов exec, который имеет несколько разновидностей. Рассмотрим
только две:
char *path;
char *argv[], *envp[], *arg0, ..., *argn;
execle(path, arg0, arg1, ..., argn, NULL, envp);
execve(path, argv, envp);
Системный вызов exec заменяет программу, выполняемую данным процессом, на программу,
загружаемую из файла path. В данном случае path должно быть полным именем файла или
именем файла от текущего каталога:
/usr/bin/vi a.out ../mybin/xkick
А. Богатырев, 1992-95 - 223 - Си в UNIX
Файл должен иметь код доступа "выполнение". Первые два байта файла (в его заго-
ловке), рассматриваемые как short int, содержат так называемое "магическое число"
(A_MAGIC), свое для каждого типа машин (смотри include-файл <a.out.h>). Его помещает
в начало выполняемого файла редактор связей ld при компоновке программы из объектных
файлов. Это число должно быть правильным, иначе система откажется запускать прог-
рамму из этого файла. Бывает несколько разных магических чисел, обозначающих разные
способы организации программы в памяти. Например, есть вариант, в котором сегменты
text и data склеены вместе (тогда text не разделяем между процессами и не защищен от
модификации программой), а есть - где данные и текст находятся в раздельных адресных
пространствах и запись в text запрещена (аппаратно).
Остальные аргументы вызова - arg0, ..., argn - это аргументы функции main новой
программы. Во второй форме вызова аргументы не перечисляются явно, а заносятся в мас-
сив. Это позволяет формировать произвольный массив строк-аргументов во время работы
программы:
char *argv[20];
argv[0]="ls"; argv[1]="-l"; argv[2]="-i"; argv[3]=NULL;
execv( "/bin/ls", argv);
либо
execl( "/bin/ls", "ls","-l","-i", NULL):
В результате этого вызова текущая программа завершается (но не процесс!) и вместо нее
запускается программа из заданного файла: сегменты stack, data, text старой программы
уничтожаются; создаются новые сегменты data и text, загружаемые из файла path; отво-
дится сегмент stack (первоначально - не очень большого размера); сегмент user сохра-
няется от старой программы (за исключением реакций на сигналы, отличных от SIG_DFL и
SIG_IGN - они будут сброшены в SIG_DFL). Затем будет вызвана функция main новой
программы с аргументами argv:
void main( argc, argv )
int argc; char *argv[]; { ... }
Количество аргументов - argc - подсчитает сама система. Строка NULL не подсчитыва-
ется.
Процесс остается тем же самым - он имеет тот же паспорт (только адреса сегментов
изменились); тот же номер (pid); все открытые прежней программой файлы остаются отк-
рытыми (с теми же дескрипторами); текущий каталог также наследуется от старой прог-
раммы; сигналы, которые игнорировались ею, также будут игнорироваться (остальные
сбрасываются в SIG_DFL). Зато "сущность" процесса подвергается перерождению - он
выполняет теперь иную программу. Таким образом, системный вызов exec осуществляет
вызов функции main, находящейся в другой программе, передавая ей свои аргументы в
качестве входных.
Системный вызов exec может не удаться, если указанный файл path не существует,
либо вы не имеете права его выполнять (такие коды доступа), либо он не является
выполняемой программой (неверное магическое число), либо слишком велик для данной
машины (системы), либо файл открыт каким-нибудь процессом (например еще записывается
компилятором). В этом случае продолжится выполнение прежней программы. Если же
вызов успешен - возврата из exec не происходит вообще (поскольку управление переда-
ется в другую программу).
Аргумент argv[0] обычно полагают равным path. По нему программа, имеющая нес-
колько имен (в файловой системе), может выбрать ЧТО она должна делать. Так программа
/bin/ls имеет альтернативные имена lr, lf, lx, ll. Запускается одна и та же прог-
рамма, но в зависимости от argv[0] она далее делает разную работу.
Аргумент envp - это "окружение" программы (см. начало этой главы). Если он не
задан - передается окружение текущей программы (наследуется содержимое массива, на
который указывает переменная environ); если же задан явно (например, окружение скопи-
ровано в какой-то массив и часть переменных подправлена или добавлены новые перемен-
ные) - новая программа получит новое окружение. Напомним, что окружение можно про-
честь из предопределенной переменной char **environ, либо из третьего аргумента функ-
ции main (см. начало главы), либо функцией getenv().
А. Богатырев, 1992-95 - 224 - Си в UNIX
Системные вызовы fork и exec не склеены в один вызов потому, что между fork и
exec в процессе-сыне могут происходить некоторые действия, нарушающие симметрию
процесса-отца и порожденного процесса: установка реакций на сигналы, перенаправление
ввода/вывода, и.т.п. Смотри пример "интерпретатор команд" в приложении. В MS DOS, не
имеющей параллельных процессов, вызовы fork, exec и wait склеены в один вызов spawn.
Зато при этом приходится делать перенаправления ввода-вывода в порождающем процессе
перед spawn, а после него - восстанавливать все как было.
6.5.4. Завершить процесс можно системным вызовом
void exit( unsigned char retcode );
Из этого вызова не бывает возврата. Процесс завершается: сегменты stack, data, text,
user уничтожаются (при этом все открытые процессом файлы закрываются); память, кото-
рую они занимали, считается свободной и в нее может быть помещен другой процесс.
Причина смерти отмечается в паспорте процесса - в структуре proc в таблице процессов
внутри ядра. Но паспорт еще не уничтожается! Это состояние процесса называется
"зомби" - живой мертвец.
В паспорт процесса заносится код ответа retcode. Этот код может быть прочитан
процессом-родителем (тем, кто создал этот процесс вызовом fork). Принято, что код 0
означает успешное завершение процесса, а любое положительное значение 1..255 означает
неудачное завершение с таким кодом ошибки. Коды ошибок заранее не предопределены:
это личное дело процессов отца и сына - установить между собой какие-то соглашения по
этому поводу. В старых программах иногда писалось exit(-1); Это некорректно - код
ответа должен быть неотрицателен; код -1 превращается в код 255. Часто используется
конструкция exit(errno);
Программа может завершиться не только явно вызывая exit, но и еще двумя спосо-
бами:
- если происходит возврат управления из функции main(), т.е. она кончилась - то
вызов exit() делается неявно, но с непредсказуемым значением retcode;
- процесс может быть убит сигналом. В этом случае он не выдает никакого кода
ответа в процесс-родитель, а выдает признак "процесс убит".
6.5.5. В действительности exit() - это еще не сам системный вызов завершения, а
стандартная функция. Сам системный вызов называется _exit(). Мы можем переопреде-
лить функцию exit() так, чтобы по окончании программы происходили некоторые действия:
void exit(unsigned code){
/* Добавленный мной дополнительный оператор: */
printf("Закончить работу, "
"код ответа=%u\n", code);
/* Стандартные операторы: */
_cleanup(); /* закрыть все открытые файлы.
* Это стандартная функция |= */
_exit(code); /* собственно сисвызов */
}
int f(){ return 17; }
void main(){
printf("aaaa\n"); printf("bbbb\n"); f();
/* потом откомментируйте это: exit(77); */
}
Здесь функция exit вызывается неявно по окончании main, ее подставляет в программу
компилятор. Дело в том, что при запуске программы exec-ом, первым начинает выпол-
няться код так называемого "стартера", подклеенного при сборке программы из файла
/lib/crt0.o. Он выглядит примерно так (в действительности он написан на ассемблере):
... // вычислить argc, настроить некоторые параметры.
main(argc, argv, envp);
exit();
А. Богатырев, 1992-95 - 225 - Си в UNIX
или так (взято из проекта GNU|-|-):
int errno = 0;
char **environ;
_start(int argc, int arga)
{
/* OS and Compiler dependent!!!! */
char **argv = (char **) &arga;
char **envp = environ = argv + argc + 1;
/* ... возможно еще какие-то инициализации,
* наподобие setlocale( LC_ALL, "" ); в SCO UNIX */
exit (main(argc, argv, envp));
}
Где должно быть
int main(int argc, char *argv[], char *envp[]){
...
return 0; /* вместо exit(0); */
}
Адрес функции _start() помечается в одном из полей заголовка файла формата a.out как
адрес, на который система должна передать управление после загрузки программы в
память (точка входа).
Какой код ответа попадет в exit() в этих примерах (если отсутствует явный вызов
exit или return) - непредсказуемо. На IBM PC в вышенаписанном примере этот код равен
17, то есть значению, возвращенному последней вызывавшейся функцией. Однако это не
какое-то специальное соглашение, а случайный эффект (так уж устроен код, создаваемый
этим компилятором).
6.5.6. Процесс-отец может дождаться окончания своего потомка. Это делается систем-
ным вызовом wait и нужно по следующей причине: пусть отец - это интерпретатор команд.
Если он запустил процесс и продолжил свою работу, то оба процесса будут предпринимать
попытки читать ввод с клавиатуры терминала - интерпретатор ждет команд, а запущенная
программа ждет данных. Кому из них будет поступать набираемый нами текст - непредс-
казуемо! Вывод: интерпретатор команд должен "заснуть" на то время, пока работает
порожденный им процесс:
int pid; unsigned short status;
...
if((pid = fork()) == 0 ){
/* порожденный процесс */
... // перенаправления ввода-вывода.
... // настройка сигналов.
exec(....);
perror("exec не удался"); exit(1);
}
/* иначе это породивший процесс */
while((pid = wait(&status)) > 0 )
printf("Окончился сын pid=%d с кодом %d\n",
pid, status >> 8);
printf( "Больше нет сыновей\n");
____________________
|= _cleanup() закрывает файлы, открытые fopen()ом, "вытряхая" при этом данные, на-
копленные в буферах, в файл. При аварийном завершении программы файлы все равно зак-
рываются, но уже не явно, а операционной системой (в вызове _exit). При этом содер-
жимое недосброшенных буферов будет утеряно.
____________________
|-|- GNU - программы, распространяемые в исходных текстах из Free Software Founda-
А. Богатырев, 1992-95 - 226 - Си в UNIX
wait приостанавливает|- выполнение вызвавшего процесса до момента окончания любого из
порожденных им процессов (ведь можно было запустить и нескольких сыновей!). Как
только какой-то потомок окончится - wait проснется и выдаст номер (pid) этого
потомка. Когда никого из живых "сыновей" не осталось - он выдаст (-1). Ясно, что
процессы могут оканчиваться не в том порядке, в котором их порождали. В переменную
status заносится в специальном виде код ответа окончившегося процесса, либо номер
сигнала, которым он был убит.
#include <sys/types.h>
#include <sys/wait.h>
...
int status, pid;
...
while((pid = wait(&status)) > 0){
if( WIFEXITED(status)){
printf( "Процесс %d умер с кодом %d\n",
pid, WEXITSTATUS(status));
} else if( WIFSIGNALED(status)){
printf( "Процесс %d убит сигналом %d\n",
pid, WTERMSIG(status));
if(WCOREDUMP(status)) printf( "Образовался core\n" );
/* core - образ памяти процесса для отладчика adb */
} else if( WIFSTOPPED(status)){
printf( "Процесс %d остановлен сигналом %d\n",
pid, WSTOPSIG(status));
} else if( WIFCONTINUED(status)){
printf( "Процесс %d продолжен\n",
pid);
}
}
...
Если код ответа нас не интересует, мы можем писать wait(NULL).
Если у нашего процесса не было или больше нет живых сыновей - вызов wait ничего
не ждет, а возвращает значение (-1). В написанном примере цикл while позволяет дож-
даться окончания всех потомков.
В тот момент, когда процесс-отец получает информацию о причине смерти потомка,
паспорт умершего процесса наконец вычеркивается из таблицы процессов и может быть
переиспользован новым процессом. До того, он хранится в таблице процессов в состоя-
нии "zombie" - "живой мертвец". Только для того, чтобы кто-нибудь мог узать статус
его завершения.
Если процесс-отец завершился раньше своих сыновей, то кто же сделает wait и
вычеркнет паспорт? Это сделает процесс номер 1: /etc/init. Если отец умер раньше
процессов-сыновей, то система заставляет процесс номер 1 "усыновить" эти процессы.
init обычно находится в цикле, содержащем в начале вызов wait(), то есть ожидает
____________________
tion (FSF). Среди них - C++ компилятор g++ и редактор emacs. Смысл слов GNU - "gen-
erally not UNIX" - проект был основан как противодействие начавшейся коммерциализации
UNIX и закрытию его исходных текстов. "Сделать как в UNIX, но лучше".
|- "Живой" процесс может пребывать в одном из нескольких состояний: процесс ожидает
наступления какого-то события ("спит"), при этом ему не выделяется время процессора,
т.к. он не готов к выполнению; процесс готов к выполнению и стоит в очереди к процес-
сору (поскольку процессор выполняет другой процесс); процесс готов и выполняется про-
цессором в данный момент. Последнее состояние может происходить в двух режимах -
пользовательском (выполняются команды сегмента text) и системном (процессом был издан
системный вызов, и сейчас выполняется функция в ядре). Ожидание события бывает только
в системной фазе - внутри системного вызова (т.е. это "синхронное" ожидание). Неак-
тивные процессы ("спящие" или ждущие ресурса процессора) могут быть временно откачаны
на диск.
А. Богатырев, 1992-95 - 227 - Си в UNIX
окончания любого из своих сыновей (а они у него всегда есть, о чем мы поговорим под-
робнее чуть погодя). Таким образом init занимается чисткой таблицы процессов, хотя
это не единственная его функция.
Вот схема, поясняющая жизненный цикл любого процесса:
|pid=719,csh
|
if(!fork())------->--------* pid=723,csh
| | загрузить
wait(&status) exec("a.out",...) <-- a.out
: main(...){ с диска
: |
:pid=719,csh | pid=723,a.out
спит(ждет) работает
: |
: exit(status) умер
: }
проснулся <---проснись!--RIP
|
|pid=719,csh
Заметьте, что номер порожденного процесса не обязан быть следующим за номером роди-
теля, а только больше него. Это связано с тем, что другие процессы могли создать в
системе новые процессы до того, как наш процесс издал свой вызов fork.
6.5.7. Кроме того, wait позволяет отслеживать остановку процесса. Процесс может
быть приостановлен при помощи посылки ему сигналов SIGSTOP, SIGTTIN, SIGTTOU,
SIGTSTP. Последние три сигнала посылает при определенных обстоятельствах драйвер
терминала, к примеру SIGTSTP - при нажатии клавиши CTRL/Z. Продолжается процесс
посылкой ему сигнала SIGCONT.
В данном контексте, однако, нас интересуют не сами эти сигналы, а другая схема
манипуляции с отслеживанием статуса порожденных процессов. Если указано явно, сис-
тема может посылать процессу-родителю сигнал SIGCLD в момент изменения статуса любого
из его потомков. Это позволит процессу-родителю немедленно сделать wait и немедленно
отразить изменение состояние процесса-потомка в своих внутренних списках. Данная
схема программируется так:
void pchild(){
int pid, status;
sighold(SIGCLD);
while((pid = waitpid((pid_t) -1, &status, WNOHANG|WUNTRACED)) > 0){
dorecord:
записать_информацию_об_изменениях;
}
sigrelse(SIGCLD);
/* Reset */
signal(SIGCLD, pchild);
}
...
main(){
...
/* По сигналу SIGCLD вызывать функцию pchild */
signal(SIGCLD, pchild);
...
главный_цикл;
}
Секция с вызовом waitpid (разновидность вызова wait), прикрыта парой функций
sighold-sigrelse, запрещающих приход сигнала SIGCLD внутри этой критической секции.
А. Богатырев, 1992-95 - 228 - Си в UNIX
Сделано это вот для чего: если процесс начнет модифицировать таблицы или списки в
районе метки dorecord:, а в этот момент придет еще один сигнал, то функция pchild
будет вызвана рекурсивно и тоже попытается модифицировать таблицы и списки, в которых
еще остались незавершенными перестановки ссылок, элементов, счетчиков. Это приведет к
разрушению данных.
Поэтому сигналы должны приходить последовательно, и функции pchild вызываться
также последовательно, а не рекурсивно. Функция sighold откладывает доставку сигнала
(если он случится), а sigrelse - разрешает доставить накопившиеся сигналы (но если их
пришло несколько одного типа - все они доставляются как один такой сигнал. Отсюда -
цикл вокруг waitpid).
Флаг WNOHANG - означает "не ждать внутри вызова wait", если ни один из потомков
не изменил своего состояния; а просто вернуть код (-1)". Это позволяет вызывать
pchild даже без получения сигнала: ничего не произойдет. Флаг WUNTRACED - означает
"выдавать информацию также об остановленных процессах".
6.5.8. Как уже было сказано, при exec все открытые файлы достаются в наследство
новой программе (в частности, если между fork и exec были перенаправлены вызовом dup2
стандартные ввод и вывод, то они останутся перенаправленными и у новой программы).
Что делать, если мы не хотим, чтобы наследовались все открытые файлы? (Хотя бы
потому, что большинством из них новая программа пользоваться не будет - в основном
она будет использовать лишь fd 0, 1 и 2; а ячейки в таблице открытых файлов процесса
они занимают). Во-первых, ненужные дескрипторы можно явно закрыть close в промежутке
между fork-ом и exec-ом. Однако не всегда мы помним номера дескрипторов для этой
операции. Более радикальной мерой является тотальная чистка:
for(f = 3; f < NOFILE; f++)
close(f);
Есть более элегантный путь. Можно пометить дескриптор файла специальным флагом,
означающим, что во время вызова exec этот дескриптор должен быть автоматически закрыт
(режим file-close-on-exec - fclex):
#include <fcntl.h>
int fd = open(.....);
fcntl (fd, F_SETFD, 1);
Отменить этот режим можно так:
fcntl (fd, F_SETFD, 0);
Здесь есть одна тонкость: этот флаг устанавливается не для структуры file - "открытый
файл", а непосредственно для дескриптора в таблице открытых процессом файлов (массив
флагов: char u_pofile[NOFILE]). Он не сбрасывается при закрытии файла, поэтому нас
может ожидать сюрприз:
... fcntl (fd, F_SETFD, 1); ... close(fd);
...
int fd1 = open( ... );
Если fd1 окажется равным fd, то дескриптор fd1 будет при exec-е закрыт, чего мы явно
не ожидали! Поэтому перед close(fd) полезно было бы отменить режим fclex.
6.5.9. Каждый процесс имеет управляющий терминал (short *u_ttyp). Он достается про-
цессу в наследство от родителя (при fork и exec) и обычно совпадает с терминалом, с
на котором работает данный пользователь.
Каждый процесс относится к некоторой группе процессов (int p_pgrp), которая
также наследуется. Можно послать сигнал всем процессам указанной группы pgrp:
kill( -pgrp, sig );
Вызов
kill( 0, sig );
посылает сигнал sig всем процессам, чья группа совпадает с группой посылающего
А. Богатырев, 1992-95 - 229 - Си в UNIX
процесса. Процесс может узнать свою группу:
int pgrp = getpgrp();
а может стать "лидером" новой группы. Вызов
setpgrp();
делает следующие операции:
/* У процесса больше нет управл. терминала: */
if(p_pgrp != p_pid) u_ttyp = NULL;
/* Группа процесса полагается равной его ид-у: */
p_pgrp = p_pid; /* new group */
В свою очередь, управляющий терминал тоже имеет некоторую группу (t_pgrp). Это значе-
ние устанавливается равным группе процесса, первым открывшего этот терминал:
/* часть процедуры открытия терминала */
if( p_pid == p_pgrp // лидер группы
&& u_ttyp == NULL // еще нет упр.терм.
&& t_pgrp == 0 ){ // у терминала нет группы
u_ttyp = &t_pgrp;
t_pgrp = p_pgrp;
}
Таким процессом обычно является процесс регистрации пользователя в системе (который
спрашивает у вас имя и пароль). При закрытии терминала всеми процессами (что бывает
при выходе пользователя из системы) терминал теряет группу: t_pgrp=0;
При нажатии на клавиатуре терминала некоторых клавиш:
c_cc[ VINTR ] обычно DEL или CTRL/C
c_cc[ VQUIT ] обычно CTRL/\
драйвер терминала посылает соответственно сигналы SIGINT и SIGQUIT всем процессам
группы терминала, т.е. как бы делает
kill( -t_pgrp, sig );
Именно поэтому мы можем прервать процесс нажатием клавиши DEL. Поэтому, если процесс
сделал setpgrp(), то сигнал с клавиатуры ему послать невозможно (т.к. он имеет свой
уникальный номер группы != группе терминала).
Если процесс еще не имеет управляющего терминала (или уже его не имеет после
setpgrp), то он может сделать любой терминал (который он имеет право открыть) управ-
ляющим для себя. Первый же файл-устройство, являющийся интерфейсом драйвера термина-
лов, который будет открыт этим процессом, станет для него управляющим терминалом. Так
процесс может иметь каналы 0, 1, 2 связанные с одним терминалом, а прерывания полу-
чать с клавиатуры другого (который он сделал управляющим для себя).
Процесс регистрации пользователя в системе - /etc/getty (название происходит от
"get tty" - получить терминал) - запускается процессом номер 1 - /etc/init-ом - на
каждом из терминалов, зарегистрированных в системе, когда
- система только что была запущена;
- либо когда пользователь на каком-то терминале вышел из системы (интерпретатор
команд завершился).
В сильном упрощении getty может быть описан так:
void main(ac, av) char *av[];
{ int f; struct termio tmodes;
for(f=0; f < NOFILE; f++) close(f);
/* Отказ от управляющего терминала,
* основание новой группы процессов.
*/
setpgrp();
/* Первоначальное явное открытие терминала */
А. Богатырев, 1992-95 - 230 - Си в UNIX
/* При этом терминал av[1] станет упр. терминалом */
open( av[1], O_RDONLY ); /* fd = 0 */
open( av[1], O_RDWR ); /* fd = 1 */
f = open( av[1], O_RDWR ); /* fd = 2 */
// ... Считывание параметров терминала из файла
// /etc/gettydefs. Тип требуемых параметров линии
// задается меткой, указываемой в av[2].
// Заполнение структуры tmodes требуемыми
// значениями ... и установка мод терминала.
ioctl (f, TCSETA, &tmodes);
// ... запрос имени и пароля ...
chdir (домашний_каталог_пользователя);
execl ("/bin/csh", "-csh", NULL);
/* Запуск интерпретатора команд. Группа процессов,
* управл. терминал, дескрипторы 0,1,2 наследуются.
*/
}
Здесь последовательные вызовы open занимают последовательные ячейки в таблице откры-
тых процессом файлов (поиск каждой новой незанятой ячейки производится с начала таб-
лицы) - в итоге по дескрипторам 0,1,2 открывается файл-терминал. После этого деск-
рипторы 0,1,2 наследуются всеми потомками интерпретатора команд. Процесс init запус-
кает по одному процессу getty на каждый терминал, как бы делая
/etc/getty /dev/tty01 m &
/etc/getty /dev/tty02 m &
...
и ожидает окончания любого из них. После входа пользователя в систему на каком-то
терминале, соответствующий getty превращается в интерпретатор команд (pid процесса
сохраняется). Как только кто-то из них умрет - init перезапустит getty на соответст-
вующем терминале (все они - его сыновья, поэтому он знает - на каком именно терми-
нале).
6.6. Трубы и FIFO-файлы.
Процессы могут обмениваться между собой информацией через файлы. Существуют
файлы с необычным поведением - так называемые FIFO-файлы (first in, first out), веду-
щие себя подобно очереди. У них указатели чтения и записи разделены. Работа с таким
файлом напоминает проталкивание шаров через трубу - с одного конца мы вталкиваем дан-
ные, с другого конца - вынимаем их. Операция чтения из пустой "трубы" проиостановит
вызов read (и издавший его процесс) до тех пор, пока кто-нибудь не запишет в FIFO-
файл какие-нибудь данные. Операция позиционирования указателя - lseek() - неприме-
нима к FIFO-файлам. FIFO-файл создается системным вызовом
#include <sys/types.h>
#include <sys/stat.h>
mknod( имяФайла, S_IFIFO | 0666, 0 );
где 0666 - коды доступа к файлу. При помощи FIFO-файла могут общаться даже неродст-
венные процессы.
Разновидностью FIFO-файла является безымянный FIFO-файл, предназначенный для
обмена информацией между процессом-отцом и процессом-сыном. Такой файл - канал связи
как раз и называется термином "труба" или pipe. Он создается вызовом pipe:
int conn[2]; pipe(conn);
Если бы файл-труба имел имя PIPEFILE, то вызов pipe можно было бы описать как
А. Богатырев, 1992-95 - 231 - Си в UNIX
mknod("PIPEFILE", S_IFIFO | 0600, 0);
conn[0] = open("PIPEFILE", O_RDONLY);
conn[1] = open("PIPEFILE", O_WRONLY);
unlink("PIPEFILE");
При вызове fork каждому из двух процессов достанется в наследство пара дескрипторов:
pipe(conn);
fork();
conn[0]----<---- ----<-----conn[1]
FIFO
conn[1]---->---- ---->-----conn[0]
процесс A процесс B
Пусть процесс A будет посылать информацию в процесс B. Тогда процесс A сделает:
close(conn[0]);
// т.к. не собирается ничего читать
write(conn[1], ... );
а процесс B
close(conn[1]);
// т.к. не собирается ничего писать
read (conn[0], ... );
Получаем в итоге:
conn[1]---->----FIFO---->-----conn[0]
процесс A процесс B
Обычно поступают еще более элегантно, перенаправляя стандартный вывод A в канал
conn[1]
dup2 (conn[1], 1); close(conn[1]);
write(1, ... ); /* или printf */
а стандартный ввод B - из канала conn[0]
dup2(conn[0], 0); close(conn[0]);
read(0, ... ); /* или gets */
Это соответствует конструкции
$ A | B
записанной на языке СиШелл.
Файл, выделяемый под pipe, имеет ограниченный размер (и поэтому обычно целиком
оседает в буферах в памяти машины). Как только он заполнен целиком - процесс, пишу-
щий в трубу вызовом write, приостанавливается до появления свободного места в трубе.
Это может привести к возникновению тупиковой ситуации, если писать программу неакку-
ратно. Пусть процесс A является сыном процесса B, и пусть процесс B издает вызов
wait, не закрыв канал conn[0]. Процесс же A очень много пишет в трубу conn[1]. Мы
получаем ситуацию, когда оба процесса спят:
A потому что труба переполнена, а процесс B ничего из нее не читает, так как ждет
окончания A;
B потому что процесс-сын A не окончился, а он не может окончиться пока не допишет
свое сообщение.
Решением служит запрет процессу B делать вызов wait до тех пор, пока он не прочитает
ВСЮ информацию из трубы (не получит EOF). Только сделав после этого close(conn[0]);
А. Богатырев, 1992-95 - 232 - Си в UNIX
процесс B имеет право сделать wait.
Если процесс B закроет свою сторону трубы close(conn[0]) прежде, чем процесс A
закончит запись в нее, то при вызове write в процессе A, система пришлет процессу A
сигнал SIGPIPE - "запись в канал, из которого никто не читает".
6.6.1. Открытие FIFO файла приведет к блокированию процесса ("засыпанию"), если в
буфере FIFO файла пусто. Процесс заснет внутри вызова open до тех пор, пока в буфере
что-нибудь не появится.
Чтобы избежать такой ситуации, а, например, сделать что-нибудь иное полезное в
это время, нам надо было бы опросить файл на предмет того - можно ли его открыть?
Это делается при помощи флага O_NDELAY у вызова open.
int fd = open(filename, O_RDONLY|O_NDELAY);
Если open ведет к блокировке процесса внутри вызова, вместо этого будет возвращено
значение (-1). Если же файл может быть немедленно открыт - возвращается нормальный
дескриптор со значением >=0, и файл открыт.
O_NDELAY является зависимым от семантики того файла, который мы открываем. К
примеру, можно использовать его с файлами устройств, например именами, ведущими к
последовательным портам. Эти файлы устройств (порты) обладают тем свойством, что
одновременно их может открыть только один процесс (так устроена реализация функции
open внутри драйвера этих устройств). Поэтому, если один процесс уже работает с пор-
том, а в это время второй пытается его же открыть, второй "заснет" внутри open, и
будет дожидаться освобождения порта close первым процессом. Чтобы не ждать - следует
открывать порт с флагом O_NDELAY.
#include <stdio.h>
#include <fcntl.h>
/* Убрать больше не нужный O_NDELAY */
void nondelay(int fd){
fcntl(fd, F_SETFL, fcntl(fd, F_GETFL, 0) & ~O_NDELAY);
}
int main(int ac, char *av[]){
int fd;
char *port = ac > 1 ? "/dev/term/a" : "/dev/cua/a";
retry: if((fd = open(port, O_RDWR|O_NDELAY)) < 0){
perror(port);
sleep(10);
goto retry;
}
printf("Порт %s открыт.\n", port);
nondelay(fd);
printf("Работа с портом, вызови эту программу еще раз!\n");
sleep(60);
printf("Все.\n");
return 0;
}
Вот протокол:
А. Богатырев, 1992-95 - 233 - Си в UNIX
su# a.out & a.out xxx
[1] 22202
Порт /dev/term/a открыт.
Работа с портом, вызови эту программу еще раз!
/dev/cua/a: Device busy
/dev/cua/a: Device busy
/dev/cua/a: Device busy
/dev/cua/a: Device busy
/dev/cua/a: Device busy
/dev/cua/a: Device busy
Все.
Порт /dev/cua/a открыт.
Работа с портом, вызови эту программу еще раз!
su#
6.7. Нелокальный переход.
Теперь поговорим про нелокальный переход. Стандартная функция setjmp позволяет
установить в программе "контрольную точку"|-, а функция longjmp осуществляет прыжок в
эту точку, выполняя за один раз выход сразу из нескольких вызванных функций (если
надо)|=. Эти функции не являются системными вызовами, но поскольку они реализуются
машинно-зависимым образом, а используются чаще всего как реакция на некоторый сигнал,
речь о них идет в этом разделе. Вот как, например, выглядит рестарт программы по
прерыванию с клавиатуры:
#include <signal.h>
#include <setjmp.h>
jmp_buf jmp; /* контрольная точка */
/* прыгнуть в контрольную точку */
void onintr(nsig){ longjmp(jmp, nsig); }
main(){
int n;
n = setjmp(jmp); /* установить контрольную точку */
if( n ) printf( "Рестарт после сигнала %d\n", n);
signal (SIGINT, onintr); /* реакция на сигнал */
printf("Начали\n");
...
}
setjmp возвращает 0 при запоминании контрольной точки. При прыжке в контрольную
точку при помощи longjmp, мы оказываемся снова в функции setjmp, и эта функция возв-
ращает нам значение второго аргумента longjmp, в этом примере - nsig.
Прыжок в контрольную точку очень удобно использовать в алгоритмах перебора с
возвратом (backtracking): либо - если ответ найден - прыжок на печать ответа, либо -
если ветвь перебора зашла в тупик - прыжок в точку ветвления и выбор другой альтерна-
тивы. При этом можно делать прыжки и в рекурсивных вызовах одной и той же функции: с
более высокого уровня рекурсии в вызов более низкого уровня (в этом случае jmp_buf
лучше делать автоматической переменной - своей для каждого уровня вызова функции).
____________________
|- В некотором буфере запоминается текущее состояние процесса: положение вершины
стека вызовов функций (stack pointer); состояние всех регистров процессора, включая
регистр адреса текущей машинной команды (instruction pointer).
|= Это достигается восстановлением состояния процесса из буфера. Изменения, проис-
шедшие за время между setjmp и longjmp в статических данных не отменяются (т.к. они
не сохранялись).
А. Богатырев, 1992-95 - 234 - Си в UNIX
6.7.1. Перепишите следующий алгоритм при помощи longjmp.
#define FOUND 1 /* ответ найден */
#define NOTFOUND 0 /* ответ не найден */
int value; /* результат */
main(){ int i;
for(i=2; i < 10; i++){
printf( "пробуем i=%d\n", i);
if( test1(i) == FOUND ){
printf("ответ %d\n", value); break;
}
}
}
test1(i){ int j;
for(j=1; j < 10 ; j++ ){
printf( "пробуем j=%d\n", j);
if( test2(i,j) == FOUND ) return FOUND;
/* "сквозной" return */
}
return NOTFOUND;
}
test2(i, j){
printf( "пробуем(%d,%d)\n", i, j);
if( i * j == 21 ){
printf( " Годятся (%d,%d)\n", i,j);
value = j; return FOUND;
}
return NOTFOUND;
}
Вот ответ, использующий нелокальный переход вместо цепочки return-ов:
#include <setjmp.h>
jmp_buf jmp;
main(){ int i;
if( i = setjmp(jmp)) /* после прыжка */
printf("Ответ %d\n", --i);
else /* установка точки */
for(i=2; i < 10; i++)
printf( "пробуем i=%d\n", i), test1(i);
}
test1(i){ int j;
for(j=1; j < 10 ; j++ )
printf( "пробуем j=%d\n", j), test2(i,j);
}
test2(i, j){
printf( "пробуем(%d,%d)\n", i, j);
if( i * j == 21 ){
printf( " Годятся (%d,%d)\n", i,j);
longjmp(jmp, j + 1);
}
}
Обратите внимание, что при возврате ответа через второй аргумент longjmp мы прибавили
1, а при печати ответа мы эту единицу отняли. Это сделано на случай ответа j==0,
чтобы функция setjmp не вернула бы в этом случае значение 0 (признак установки конт-
рольной точки).
6.7.2. В чем ошибка?
#include <setjmp.h>
А. Богатырев, 1992-95 - 235 - Си в UNIX
jmp_buf jmp;
main(){
g();
longjmp(jmp,1);
}
g(){ printf("Вызвана g\n");
f();
printf("Выхожу из g\n");
}
f(){
static n;
printf( "Вызвана f\n");
setjmp(jmp);
printf( "Выхожу из f %d-ый раз\n", ++n);
}
Ответ: longjmp делает прыжок в функцию f(), из которой уже произошел возврат управле-
ния. При переходе в тело функции в обход ее заголовка не выполняются машинные команды
"пролога" функции - функция остается "неактивированной". При возврате из вызванной
таким "нелегальным" путем функции возникает ошибка, и программа падает. Мораль: в
функцию, которая НИКЕМ НЕ ВЫЗВАНА, нельзя передавать управление. Обратный прыжок -
из f() в main() - был бы законен, поскольку функция main() является активной, когда
управление находится в теле функции f(). Т.е. можно "прыгать" из вызванной функции в
вызывающую: из f() в main() или в g(); и из g() в main();
-- --
| f | стек прыгать
| g | вызовов сверху вниз
| main | функций можно - это соответствует
---------- выкидыванию нескольких
верхних слоев стека
но нельзя наоборот: из main() в g() или f(); а также из g() в f(). Можно также
совершать прыжок в пределах одной и той же функции:
f(){ ...
A: setjmp(jmp);
...
longjmp(jmp, ...); ...
/* это как бы goto A; */
}
6.8. Хозяин файла, процесса, и проверка привелегий.
UNIX - многопользовательская система. Это значит, что одновременно на разных
терминалах, подключенных к машине, могут работать разные пользователи (а может и один
на нескольких терминалах). На каждом терминале работает свой интерпретатор команд,
являющийся потомком процесса /etc/init.
6.8.1. Теперь - про функции, позволяющие узнать некоторые данные про любого пользо-
вателя системы. Каждый пользователь в UNIX имеет уникальный номер: идентификатор
пользователя (user id), а также уникальное имя: регистрационное имя, которое он наби-
рает для входа в систему. Вся информация о пользователях хранится в файле
/etc/passwd. Существуют функции, позволяющие по номеру пользователя узнать регистра-
ционное имя и наоборот, а заодно получить еще некоторую информацию из passwd:
А. Богатырев, 1992-95 - 236 - Си в UNIX
#include <stdio.h>
#include <pwd.h>
struct passwd *p;
int uid; /* номер */
char *uname; /* рег. имя */
uid = getuid();
p = getpwuid( uid );
...
p = getpwnam( uname );
Эти функции возвращают указатели на статические структуры, скрытые внутри этих функ-
ций. Структуры эти имеют поля:
p->pw_uid идентиф. пользователя (int uid);
p->pw_gid идентиф. группы пользователя;
и ряд полей типа char[]
p->pw_name регистрационное имя пользователя (uname);
p->pw_dir полное имя домашнего каталога
(каталога, становящегося текущим при входе в систему);
p->pw_shell интерпретатор команд
(если "", то имеется в виду /bin/sh);
p->pw_comment произвольная учетная информация (не используется);
p->pw_gecos произвольная учетная информация (обычно ФИО);
p->pw_passwd зашифрованный пароль для входа в
систему. Истинный пароль нигде не хранится вовсе!
Функции возвращают значение p==NULL, если указанный пользователь не существует (нап-
ример, если задан неверный uid). uid хозяина данного процесса можно узнать вызовом
getuid, а uid владельца файла - из поля st_uid структуры, заполняемой системным вызо-
вом stat (а идентификатор группы владельца - из поля st_gid). Задание: модифицируйте
наш аналог программы ls, чтобы он выдавал в текстовом виде имя владельца каждого
файла в каталоге.
6.8.2. Владелец файла может изменить своему файлу идентификаторы владельца и группы
вызовом
chown(char *имяФайла, int uid, int gid);
т.е. "подарить" файл другому пользователю. Забрать чужой файл себе невозможно. При
этой операции биты S_ISUID и S_ISGID в кодах доступа к файлу (см. ниже) сбрасываются,
поэтому создать "Троянского коня" и, сделав его хозяином суперпользователя, получить
неограниченные привелегии - не удастся!
6.8.3. Каждый файл имеет своего владельца (поле di_uid в I-узле на диске или поле
i_uid в копии I-узла в памяти ядра|-). Каждый процесс также имеет своего владельца
(поля u_uid и u_ruid в u-area). Как мы видим, процесс имеет два параметра, обознача-
ющие владельца. Поле ruid называется "реальным идентификатором" пользователя, а uid -
"эффективным идентификатором". При вызове exec() заменяется программа, выполняемая
данным процессом:
____________________
|- При открытии файла и вообще при любой операции с файлом, в таблицах ядра заво-
дится копия I-узла (для ускорения доступа, чтобы постоянно не обращаться к диску).
Если I-узел в памяти будет изменен, то при закрытии файла (а также периодически через
некоторые промежутки времени) эта копия будет записана обратно на диск. Структура
I-узла в памяти - struct inode - описана в файле <sys/inode.h>, а на диске - struct
dinode - в файле <sys/ino.h>.
А. Богатырев, 1992-95 - 237 - Си в UNIX
старая программа exec новая программа
ruid -->----------------->---> ruid
uid -->--------*-------->---> uid (new)
|
выполняемый файл
i_uid (st_uid)
Как видно из этой схемы, реальный идентификатор хозяина процесса наследуется. Эффек-
тивный идентификатор обычно также наследуется, за исключением одного случая: если в
кодах доступа файла (i_mode) выставлен бит S_ISUID (set-uid bit), то значение поля
u_uid в новом процессе станет равно значению i_uid файла с программой:
/* ... во время exec ... */
p_suid = u_uid; /* спасти */
if( i_mode & S_ISUID ) u_uid = i_uid;
if( i_mode & S_ISGID ) u_gid = i_gid;
т.е. эффективным владельцем процесса станет владелец файла. Здесь gid - это иденти-
фикаторы группы владельца (которые тоже есть и у файла и у процесса, причем у про-
цесса - реальный и эффективный).
Зачем все это надо? Во-первых затем, что ПРАВА процесса на доступ к какому-либо
файлу проверяются именно для эффективного владельца процесса. Т.е. например, если
файл имеет коды доступа
mode = i_mode & 0777;
/* rwx rwx rwx */
и владельца i_uid, то процесс, пытающийся открыть этот файл, будет "проэкзаменован" в
таком порядке:
if( u_uid == 0 ) /* super user */
то доступ разрешен;
else if( u_uid == i_uid )
проверить коды (mode & 0700);
else if( u_gid == i_gid )
проверить коды (mode & 0070);
else проверить коды (mode & 0007);
Процесс может узнать свои параметры:
unsigned short uid = geteuid(); /* u_uid */
unsigned short ruid = getuid(); /* u_ruid */
unsigned short gid = getegid(); /* u_gid */
unsigned short rgid = getuid(); /* u_rgid */
а также установить их:
setuid(newuid); setgid(newgid);
Рассмотрим вызов setuid. Он работает так (u_uid - относится к процессу, издавшему
этот вызов):
if( u_uid == 0 /* superuser */ )
u_uid = u_ruid = p_suid = newuid;
else if( u_ruid == newuid || p_suid == newuid )
u_uid = newuid;
else неудача;
Поле p_suid позволяет set-uid-ной программе восстановить эффективного владельца,
который был у нее до exec-а.
А. Богатырев, 1992-95 - 238 - Си в UNIX
Во-вторых, все это надо для следующего случая: пусть у меня есть некоторый файл
BASE с хранящимися в нем секретными сведениями. Я являюсь владельцем этого файла и
устанавливаю ему коды доступа 0600 (чтение и запись разрешены только мне). Тем не
менее, я хочу дать другим пользователям возможность работать с этим файлом, однако
контролируя их деятельность. Для этого я пишу программу, которая выполняет некоторые
действия с файлом BASE, при этом проверяя законность этих действий, т.е. позволяя
делать не все что попало, а лишь то, что я в ней предусмотрел, и под жестким контро-
лем. Владельцем файла PROG, в котором хранится эта программа, также являюсь я, и я
задаю этому файлу коды доступа 0711 (rwx--x--x) - всем можно выполнять эту программу.
Все ли я сделал, чтобы позволить другим пользоваться базой BASE через программу (и
только нее) PROG? Нет!
Если кто-то другой запустит программу PROG, то эффективный идентификатор про-
цесса будет равен идентификатору этого другого пользователя, и программа не сможет
открыть мой файл BASE. Чтобы все работало, процесс, выполняющий программу PROG, дол-
жен работать как бы от моего имени. Для этого я должен вызовом chmod либо командой
chmod u+s PROG
добавить к кодам доступа файла PROG бит S_ISUID.
После этого, при запуске программы PROG, она будет получать эффективный иденти-
фикатор, равный моему идентификатору, и таким образом сможет открыть и работать с
файлом BASE. Вызов getuid позволяет выяснить, кто вызвал мою программу (и занести
это в протокол, если надо).
Программы такого типа - не редкость в UNIX, если владельцем программы (файла ее
содержащего) является суперпользователь. В таком случае программа, имеющая бит дос-
тупа S_ISUID работает от имени суперпользователя и может выполнять некоторые дейст-
вия, запрещенные обычным пользователям. При этом программа внутри себя делает всячес-
кие проверки и периодически спрашивает пароли, то есть при работе защищает систему от
дураков и преднамеренных вредителей. Простейшим примером служит команда ps, которая
считывает таблицу процессов из памяти ядра и распечатывает ее. Доступ к физической
памяти машины производится через файл-псевдоустройство /dev/mem, а к памяти ядра -
/dev/kmem. Чтение и запись в них позволены только суперпользователю, поэтому прог-
раммы "общего пользования", обращающиеся к этим файлам, должны иметь бит set-uid.
Откуда же изначально берутся значения uid и ruid (а также gid и rgid) у про-
цесса? Они берутся из процесса регистрации пользователя в системе: /etc/getty. Этот
процесс запускается на каждом терминале как процесс, принадлежащий суперпользователю
(u_uid==0). Сначала он запрашивает имя и пароль пользователя:
#include <stdio.h> /* cc -lc_s */
#include <pwd.h>
#include <signal.h>
struct passwd *p;
char userName[80], *pass, *crpass;
extern char *getpass(), *crypt();
...
/* Не прерываться по сигналам с клавиатуры */
signal (SIGINT, SIG_IGN);
for(;;){
/* Запросить имя пользователя: */
printf("Login: "); gets(userName);
/* Запросить пароль (без эха): */
pass = getpass("Password: ");
/* Проверить имя: */
if(p = getpwnam(userName)){
/* есть такой пользователь */
crpass = (p->pw_passwd[0]) ? /* если есть пароль */
crypt(pass, p->pw_passwd) : pass;
if( !strcmp( crpass, p->pw_passwd))
break; /* верный пароль */
}
printf("Login incorrect.\a\n");
}
signal (SIGINT, SIG_DFL);
А. Богатырев, 1992-95 - 239 - Си в UNIX
Затем он выполняет:
// ... запись информации о входе пользователя в систему
// в файлы /etc/utmp (кто работает в системе сейчас)
// и /etc/wtmp (список всех входов в систему)
...
setuid( p->pw_uid ); setgid( p->pw_gid );
chdir ( p->pw_dir ); /* GO HOME! */
// эти параметры будут унаследованы
// интерпретатором команд.
...
// настройка некоторых переменных окружения envp:
// HOME = p->pw_dir
// SHELL = p->pw_shell
// PATH = нечто по умолчанию, вроде :/bin:/usr/bin
// LOGNAME (USER) = p->pw_name
// TERM = считывается из файла
// /etc/ttytype по имени устройства av[1]
// Делается это как-то подобно
// char *envp[MAXENV], buffer[512]; int envc = 0;
// ...
// sprintf(buffer, "HOME=%s", p->pw_dir);
// envp[envc++] = strdup(buffer);
// ...
// envp[envc] = NULL;
...
// настройка кодов доступа к терминалу. Имя устройства
// содержится в параметре av[1] функции main.
chown (av[1], p->pw_uid, p->pw_gid);
chmod (av[1], 0600 ); /* -rw------- */
// теперь доступ к данному терминалу имеют только
// вошедший в систему пользователь и суперпользователь.
// В случае смерти интерпретатора команд,
// которым заменится getty, процесс init сойдет
// с системного вызова ожидания wait() и выполнит
// chown ( этот_терминал, 2 /*bin*/, 15 /*terminal*/ );
// chmod ( этот_терминал, 0600 );
// и, если терминал числится в файле описания линий
// связи /etc/inittab как активный (метка respawn), то
// init перезапустит на этом_терминале новый
// процесс getty при помощи пары вызовов fork() и exec().
...
// запуск интерпретатора команд:
execle( *p->pw_shell ? p->pw_shell : "/bin/sh",
"-", NULL, envp );
В результате он становится процессом пользователя, вошедшего в систему. Таковым же
после exec-а, выполняемого getty, остается и интерпретатор команд p->pw_shell (обычно
/bin/sh или /bin/csh) и все его потомки.
На самом деле, в описании регистрации пользователя при входе в систему, созна-
тельно было допущено упрощение. Дело в том, что все то, что мы приписали процессу
getty, в действительности выполняется двумя программами: /etc/getty и /bin/login.
Сначала процесс getty занимается настройкой параметров линии связи (т.е. терми-
нала) в соответствии с ее описанием в файле /etc/gettydefs. Затем он запрашивает имя
пользователя и заменяет себя (при помощи сисвызова exec) процессом login, передавая
ему в качестве одного из аргументов полученное имя пользователя.
Затем login запрашивает пароль, настраивает окружение, и.т.п., то есть именно он
производит все операции, приведенные выше на схеме. В конце концов он заменяет себя
интерпретатором команд.
Такое разделение делается, в частности, для того, чтобы считанный пароль в слу-
чае опечатки не хранился бы в памяти процесса getty, а уничтожался бы при очистке
А. Богатырев, 1992-95 - 240 - Си в UNIX
памяти завершившегося процесса login. Таким образом пароль в истинном, незашифрован-
ном виде хранится в системе минимальное время, что затрудняет его подсматривание
средствами электронного или программного шпионажа. Кроме того, это позволяет изме-
нять систему проверки паролей не изменяя программу инициализации терминала getty.
Имя, под которым пользователь вошел в систему на данном терминале, можно узнать
вызовом стандартной функции
char *getlogin();
Эта функция не проверяет uid процесса, а просто извлекает запись про данный терминал
из файла /etc/utmp.
Наконец отметим, что владелец файла устанавливается при создании этого файла
(вызовами creat или mknod), и полагается равным эффективному идентификатору создаю-
щего процесса.
di_uid = u_uid; di_gid = u_gid;
6.8.4. Напишите программу, узнающую у системы и распечатывающую: номер процесса,
номер и имя своего владельца, номер группы, название и тип терминала на котором она
работает (из переменной окружения TERM).
6.9. Блокировка доступа к файлам.
В базах данных нередко встречается ситуация одновременного доступа к одним и тем
же данным. Допустим, что в некотором файле хранятся данные, которые могут читаться и
записываться произвольным числом процессов.
- Допустим, что процесс A изменяет некоторую область файла, в то время как процесс
B пытается прочесть ту же область. Итогом такого соревнования может быть то,
что процесс B прочтет неверные данные.
- Допустим, что процесс A изменяет некоторую область файла, в то время как процесс
C также изменяет ту же самую область. В итоге эта область может содержать
неверные данные (часть - от процесса A, часть - от C).
Ясно, что требуется механизм синхронизации процессов, позволяющий не пускать
другой процесс (процессы) читать и/или записывать данные в указанной области. Меха-
низмов синхронизации в UNIX существует множество: от семафоров до блокировок областей
файла. О последних мы и будем тут говорить.
Прежде всего отметим, что блокировки файла носят в UNIX необязательный характер.
То есть, программа не использующая вызовов синхронизации, будет иметь доступ к данным
без каких либо ограничений. Увы. Таким образом, программы, собирающиеся корректно
пользоваться общими данными, должны все использовать - и при том один и тот же -
механизм синхронизации: заключить между собой "джентльменское соглашение".
6.9.1. Блокировка устанавливается при помощи вызова
flock_t lock;
fcntl(fd, operation, &lock);
Здесь operation может быть одним из трех:
F_SETLK
Устанавливает или снимает замок, описываемый структурой lock. Структура flock_t
имеет такие поля:
short l_type;
short l_whence;
off_t l_start;
size_t l_len;
long l_sysid;
pid_t l_pid;
l_type
тип блокировки:
А. Богатырев, 1992-95 - 241 - Си в UNIX
F_RDLCK - на чтение;
F_WRLCK - на запись;
F_UNLCK - снять все замки.
l_whence, l_start, l_len
описывают сегмент файла, на который ставится замок: от точки
lseek(fd,l_start,l_whence); длиной l_len байт. Здесь l_whence может быть:
SEEK_SET, SEEK_CUR, SEEK_END. l_len равное нулю означает "до конца файла". Так
если все три параметра равны 0, то будет заблокирован весь файл.
F_SETLKW
Устанавливает или снимает замок, описываемый структурой lock. При этом, если
замок на область, пересекающуюся с указанной уже кем-то установлен, то сперва
дождаться снятия этого замка.
Пытаемся | Нет Уже есть уже есть
поставить | чужих замок замок
замок на | замков на READ на WRITE
-----------|---------------------------------------------------------------
READ | читать читать ждать;запереть;читать
WRITE | записать ждать;запереть;записать ждать;запереть;записать
UNLOCK | отпереть отпереть отпереть
- Если кто-то читает сегмент файла, то другие тоже могут его читать свободно, ибо
чтение не изменяет файла.
- Если же кто-то записывает файл - то все остальные должны дождаться окончания
записи и разблокировки.
- Если кто-то читает сегмент, а другой процесс собрался изменить (записать) этот
сегмент, то этот другой процесс обязан дождаться окончания чтения первым.
- В момент, обозначенный как отпереть - будятся процессы, ждущие разблокировки, и
ровно один из них получает доступ (может установить свою блокировку). Порядок -
кто из них будет первым - вообще говоря не определен.
F_GETLK
Запрашиваем возможность установить замок, описанный в lock.
- Если мы можем установить такой замок (не заперто никем), то в структуре lock
поле l_type становится равным F_UNLCK и поле l_whence равным SEEK_SET.
- Если замок уже кем-то установлен (и вызов F_SETLKW заблокировал бы наш процесс,
привел бы к ожиданию), мы получаем информацию о чужом замке в структуру lock.
При этом в поле l_pid заносится идентификатор процесса, создавшего этот замок, а
в поле l_sysid - идентификатор машины (поскольку блокировка файлов поддержива-
ется через сетевые файловые системы).
Замки автоматически снимаются при закрытии дескриптора файла. Замки не наследу-
ются порожденным процессом при вызове fork.
#include <stdio.h>
#include <sys/types.h>
#include <fcntl.h>
#include <unistd.h>
#include <time.h>
#include <signal.h>
char DataFile [] = "data.xxx";
char info [] = "abcdefghijklmnopqrstuvwxyz";
#define OFFSET 5
#define SIZE 12
#define PAUSE 2
int trial = 1;
int fd, pid;
char buffer[120], myname[20];
void writeAccess(), readAccess();
А. Богатырев, 1992-95 - 242 - Си в UNIX
void fcleanup(int nsig){
unlink(DataFile);
printf("cleanup:%s\n", myname);
if(nsig) exit(0);
}
int main(){
int i;
fd = creat(DataFile, 0644);
write(fd, info, strlen(info));
close(fd);
signal(SIGINT, fcleanup);
sprintf(myname, fork() ? "B-%06d" : "A-%06d", pid = getpid());
srand(time(NULL)+pid);
printf("%s:started\n", myname);
fd = open(DataFile, O_RDWR|O_EXCL);
printf("%s:opened %s\n", myname, DataFile);
for(i=0; i < 30; i++){
if(rand()%2) readAccess();
else writeAccess();
}
close(fd);
printf("%s:finished\n", myname);
wait(NULL);
fcleanup(0);
return 0;
}
А. Богатырев, 1992-95 - 243 - Си в UNIX
void writeAccess(){
flock_t lock;
printf("Write:%s #%d\n", myname, trial);
lock.l_type = F_WRLCK;
lock.l_whence = SEEK_SET;
lock.l_start = (off_t) OFFSET;
lock.l_len = (size_t) SIZE;
if(fcntl(fd, F_SETLKW, &lock) <0)
perror("F_SETLKW");
printf("\twrite:%s locked\n", myname);
sprintf(buffer, "%s #%02d", myname, trial);
printf ("\twrite:%s \"%s\"\n", myname, buffer);
lseek (fd, (off_t) OFFSET, SEEK_SET);
write (fd, buffer, SIZE);
sleep (PAUSE);
lock.l_type = F_UNLCK;
if(fcntl(fd, F_SETLKW, &lock) <0)
perror("F_SETLKW");
printf("\twrite:%s unlocked\n", myname);
trial++;
}
void readAccess(){
flock_t lock;
printf("Read:%s #%d\n", myname, trial);
lock.l_type = F_RDLCK;
lock.l_whence = SEEK_SET;
lock.l_start = (off_t) OFFSET;
lock.l_len = (size_t) SIZE;
if(fcntl(fd, F_SETLKW, &lock) <0)
perror("F_SETLKW");
printf("\tread:%s locked\n", myname);
lseek(fd, (off_t) OFFSET, SEEK_SET);
read (fd, buffer, SIZE);
printf("\tcontents:%s \"%*.*s\"\n", myname, SIZE, SIZE, buffer);
sleep (PAUSE);
lock.l_type = F_UNLCK;
if(fcntl(fd, F_SETLKW, &lock) <0)
perror("F_SETLKW");
printf("\tread:%s unlocked\n", myname);
trial++;
}
А. Богатырев, 1992-95 - 244 - Си в UNIX
Исследуя выдачу этой программы, вы можете обнаружить, что READ-области могут перекры-
ваться; но что никогда не перекрываются области READ и WRITE ни в какой комбинации.
Если идет чтение процессом A - то запись процессом B дождется разблокировки A (чтение
- не будет дожидаться). Если идет запись процессом A - то и чтение процессом B и
запись процессом B дождутся разблокировки A.
6.9.2.
UNIX SVR4 имеет еще один интерфейс для блокировки файлов: функцию lockf.
#include <unistd.h>
int lockf(int fd, int operation, size_t size);
Операция operation:
F_ULOCK
Разблокировать указанный сегмент файла (это может снимать один или несколько
замков).
F_LOCK
F_TLOCK
Установить замок. При этом, если уже имеется чужой замок на запрашиваемую
область, F_LOCK блокирует процесс, F_TLOCK - просто выдает ошибку (функция возв-
ращает -1, errno устанавливается в EAGAIN).
- Ожидание отпирания/запирания замка может быть прервано сигналом.
- Замок устанавливается следующим образом: от текущей позиции указателя чтения-
записи в файле fd (что не похоже на fcntl, где позиция задается явно как пара-
метр в структуре); длиной size. Отрицательное значение size означает отсчет от
текущей позиции к началу файла. Нулевое значение - означает "от текущей позиции
до конца файла". При этом "конец файла" понимается именно как конец, а не как
текущий размер файла. Если файл изменит размер, запертая область все равно
будет простираться до конца файла (уже нового).
- Замки, установленные процессом, автоматически отпираются при завершении про-
цесса.
F_TEST
Проверить наличие замка. Функция возвращает 0, если замка нет; -1 в противном
случае (заперто).
Если устанавливается замок, перекрывающийся с уже установленным, то замки объединя-
ются.
было: ___________#######____######__________
запрошено:______________##########______________
стало: ___________#################__________
Если снимается замок с области, покрывающей только часть заблокированной прежде,
остаток области остается как отдельный замок.
было: ___________#################__________
запрошено:______________XXXXXXXXXX______________
стало: ___________###__________####__________
6.10. Файлы устройств.
Пространство дисковой памяти может состоять из нескольких файловых систем (в
дальнейшем FS), т.е. логических и/или физических дисков. Каждая файловая система
имеет древовидную логическую структуру (каталоги, подкаталоги и файлы) и имеет свой
корневой каталог. Файлы в каждой FS имеют свои собственные I-узлы и собственную их
нумерацию с 1. В начале каждой FS зарезервированы:
А. Богатырев, 1992-95 - 245 - Си в UNIX
- блок для загрузчика - программы, вызываемой аппаратно при включении машины (заг-
рузчик записывает с диска в память машины программу /boot, которая в свою оче-
редь загружает в память ядро /unix);
- суперблок - блок заголовка файловой системы, хранящий размер файловой системы (в
блоках), размер блока (512, 1024, ...), количество I-узлов, начало списка сво-
бодных блоков, и другие сведения об FS;
- некоторая непрерывная область диска для хранения I-узлов - "I-файл".
Файловые системы объединяются в единую древовидную иерархию операцией монтирования -
подключения корня файловой системы к какому-то из каталогов-"листьев" дерева другой
FS.
Файлы в объединенной иерархии адресуются при помощи двух способов:
- имен, задающих путь в дереве каталогов:
/usr/abs/bin/hackIt
bin/hackIt
./../../bin/vi
(этот способ предназначен для программ, пользующихся файлами, а также пользова-
телей);
- внутренних адресов, используемых программами ядра и некоторыми системными прог-
раммами.
Поскольку в каждой FS имеется собственная нумерация I-узлов, то файл в объединенной
иерархии должен адресоваться ДВУМЯ параметрами:
- номером (кодом) устройства, содержащего файловую систему, в которой находится
искомый файл: dev_t i_dev;
- номером I-узла файла в этой файловой системе: ino_t i_number;
Преобразование имени файла в объединенной файловой иерархии в такую адресную пару
выполняет в ядре уже упоминавшаяся выше функция namei (при помощи просмотра катало-
гов):
struct inode *ip = namei(...);
Создаваемая ею копия I-узла в памяти ядра содержит поля i_dev и i_number (которые на
самом диске не хранятся!).
Рассмотрим некоторые алгоритмы работы ядра с файлами. Ниже они приведены чисто
схематично и в сильном упрощении. Форматы вызова (и оформление) функций не соот-
ветствуют форматам, используемым на самом деле в ядре; верны лишь названия функций.
Опущены проверки на корректность, подсчет ссылок на структуры file и inode, блоки-
ровка I-узлов и кэш-буферов от одновременного доступа, и многое другое.
Пусть мы хотим открыть файл для чтения и прочитать из него некоторую информацию.
Вызовы открытия и закрытия файла имеют схему (часть ее будет объяснена позже):
#include <sys/types.h>
#include <sys/inode.h>
#include <sys/file.h>
int fd_read = open(имяФайла, O_RDONLY){
int fd; struct inode *ip; struct file *fp; dev_t dev;
u_error = 0; /* errno в программе */
// Найти файл по имени. Создается копия I-узла в памяти:
ip = namei(имяФайла, LOOKUP);
// namei может выдать ошибку, если нет такого файла
if(u_error) return(-1); // ошибка
// Выделяется структура "открытый файл":
fp = falloc(ip, FREAD);
// fp->f_flag = FREAD; открыт на чтение
А. Богатырев, 1992-95 - 246 - Си в UNIX
// fp->f_offset = 0; RWptr
// fp->f_inode = ip; ссылка на I-узел
// Выделить новый дескриптор
for(fd=0; fd < NOFILE; fd++)
if(u_ofile[fd] == NULL ) // свободен
goto done;
u_error = EMFILE; return (-1);
done:
u_ofile[fd] = fp;
// Если это устройство - инициализировать его.
// Это функция openi(ip, fp->f_flag);
dev = ip->i_rdev;
if((ip->i_mode & IFMT) == IFCHR)
(*cdevsw[major(dev)].d_open)(minor(dev),fp->f_flag);
else if((ip->i_mode & IFMT) == IFBLK)
(*bdevsw[major(dev)].d_open)(minor(dev),fp->f_flag);
return fd; // через u_rval1
}
close(fd){
struct file *fp = u_ofile[fd];
struct inode *ip = fp->f_inode;
dev_t dev = ip->i_rdev;
if((ip->i_mode & IFMT) == IFCHR)
(*cdevsw[major(dev)].d_close)(minor(dev),fp->f_flag);
else if((ip->i_mode & IFMT) == IFBLK)
(*bdevsw[major(dev)].d_close)(minor(dev),fp->f_flag);
u_ofile[fd] = NULL;
// и удалить ненужные структуры из ядра.
}
Теперь рассмотрим функцию преобразования логических блоков файла в номера физических
блоков в файловой системе. Для этого преобразования в I-узле файла содержится таблица
адресов блоков. Она устроена довольно сложно - ее начало находится в узле, а продол-
жение - в нескольких блоках в самой файловой системе (устройство это можно увидеть в
примере "Фрагментированность файловой системы" в приложении). Мы для простоты будем
предполагать, что это просто линейный массив i_addr[], в котором n-ому логическому
блоку файла отвечает bno-тый физический блок файловой системы:
bno = ip->i_addr[n];
Если файл является интерфейсом устройства, то этот файл не хранит информации в логи-
ческой файловой системе. Поэтому у устройств нет таблицы адресов блоков. Вместо
этого, поле i_addr[0] используется для хранения кода устройства, к которому приводит
этот специальный файл. Это поле носит название i_rdev, т.е. как бы сделано
#define i_rdev i_addr[0]
(на самом деле используется union). Устройства бывают байто-ориентированные, обмен с
которыми производится по одному байту (как с терминалом или с коммуникационным пор-
том); и блочно-ориентированные, обмен с которыми возможен только большими порциями -
блоками (пример - диск). То, что файл является устройством, помечено в поле тип
файла
ip->i_mode & IFMT
А. Богатырев, 1992-95 - 247 - Си в UNIX
одним из значений: IFCHR - байтовое; или IFBLK - блочное. Алгоритм вычисления номера
блока:
ushort u_pboff; // смещение от начала блока
ushort u_pbsize; // сколько байт надо использовать
// ushort - это unsigned short, смотри <sys/types.h>
// daddr_t - это long (disk address)
daddr_t bmap(struct inode *ip,
off_t offset, unsigned count){
int sz, rem;
// вычислить логический номер блока по позиции RWptr.
// BSIZE - это размер блока файловой системы,
// эта константа определена в <sys/param.h>
daddr_t bno = offset / BSIZE;
// если BSIZE == 1 Кб, то можно offset >> 10
u_pboff = offset % BSIZE;
// это можно записать как offset & 01777
sz = BSIZE - u_pboff;
// столько байт надо взять из этого блока,
// начиная с позиции u_pboff.
if(count < sz) sz = count;
u_pbsize = sz;
Если файл представляет собой устройство, то трансляция логических блоков в физические
не производится - устройство представляет собой "сырой" диск без файлов и каталогов,
т.е. обращение происходит сразу по физическому номеру блока:
if((ip->i_mode & IFMT) == IFBLK) // block device
return bno; // raw disk
// иначе провести пересчет:
rem = ip->i_size /*длина файла*/ - offset;
// это остаток файла.
if( rem < 0 ) rem = 0;
// файл короче, чем заказано нами:
if( rem < sz ) sz = rem;
if((u_pbsize = sz) == 0) return (-1); // EOF
// и, собственно, замена логич. номера на физич.
return ip->i_addr[bno];
}
Теперь рассмотрим алгоритм read. Параметры, начинающиеся с u_..., на самом деле пере-
даются как статические через вспомогательные переменные в u-area процесса.
read(int fd, char *u_base, unsigned u_count){
unsigned srccount = u_count;
struct file *fp = u_ofile[fd];
struct inode *ip = fp->f_inode;
struct buf *bp;
daddr_t bno; // очередной блок файла
// dev - устройство,
// интерфейсом которого является файл-устройство,
// или на котором расположен обычный файл.
dev_t dev = (ip->i_mode & (IFCHR|IFBLK)) ?
А. Богатырев, 1992-95 - 248 - Си в UNIX
ip->i_rdev : ip->i_dev;
switch( ip->i_mode & IFMT ){
case IFCHR: // байто-ориентированное устройство
(*cdevsw[major(dev)].d_read)(minor(dev));
// прочие параметры передаются через u-area
break;
case IFREG: // обычный файл
case IFDIR: // каталог
case IFBLK: // блочно-ориентированное устройство
do{
bno = bmap(ip, fp->f_offset /*RWptr*/, u_count);
if(u_pbsize==0 || (long)bno < 0) break; // EOF
bp = bread(dev, bno); // block read
iomove(bp->b_addr + u_pboff, u_pbsize, B_READ);
Функция iomove копирует данные
bp->b_addr[ u_pboff..u_pboff+u_pbsize-1 ]
из адресного пространства ядра (из буфера в ядре) в адресное пространство процесса по
адресам
u_base[ 0..u_pbsize-1 ]
то есть пересылает u_pbsize байт между ядром и процессом (u_base попадает в iomove
через статическую переменную). При записи вызовом write(), iomove с флагом B_WRITE
производит обратное копирование - из памяти процесса в память ядра. Продолжим:
// продвинуть счетчики и указатели:
u_count -= u_pbsize;
u_base += u_pbsize;
fp->f_offset += u_pbsize; // RWptr
} while( u_count != 0 );
break;
...
return( srccount - u_count );
} // end read
Теперь обсудим некоторые места этого алгоритма. Сначала посмотрим, как происходит
обращение к байтовому устройству. Вместо адресов блоков мы получаем код устройства
i_rdev. Коды устройств в UNIX (тип dev_t) представляют собой пару двух чисел, назы-
ваемых мажор и минор, хранимых в старшем и младшем байтах кода устройства:
#define major(dev) ((dev >> 8) & 0x7F)
#define minor(dev) ( dev & 0xFF)
Мажор обозначает тип устройства (диск, терминал, и.т.п.) и приводит к одному из драй-
веров (если у нас есть 8 терминалов, то их обслуживает один и тот же драйвер); а
минор обозначает номер устройства данного типа (... каждый из терминалов имеет миноры
0..7). Миноры обычно служат индексами в некоторой таблице структур внутри выбранного
драйвера. Мажор же служит индексом в переключательной таблице устройств. При этом
блочно-ориентированные устройства выбираются в одной таблице - bdevsw[], а байто-
ориентированные - в другой - cdevsw[] (см. <sys/conf.h>; имена таблиц означают
block/character device switch). Каждая строка таблицы содержит адреса функций,
выполняющих некоторые предопределенные операции способом, зависимым от устройства.
Сами эти функции реализованы в драйверах устройств. Аргументом для этих функций
обычно служит минор устройства, к которому производится обращение. Функция в
А. Богатырев, 1992-95 - 249 - Си в UNIX
драйвере использует этот минор как индекс для выбора конкретного экземпляра уст-
ройства данного типа; как индекс в массиве управляющих структур (содержащих текущее
состояние, режимы работы, адреса функций прерываний, адреса очередей данных и.т.п.
каждого конкретного устройства) для данного типа устройств. Эти управляющие структуры
различны для разных типов устройств (и их драйверов).
Каждая строка переключательной таблицы содержит адреса функций, выполняющих опе-
рации open, close, read, write, ioctl, select. open служит для инициализации уст-
ройства при первом его открытии (++ip->i_count==1) - например, для включения мотора;
close - для выключения при последнем закрытии (--ip->i_count==0). У блочных уст-
ройств поля для read и write объединены в функцию strategy, вызываемую с параметром
B_READ или B_WRITE. Вызов ioctl предназначен для управления параметрами работы уст-
ройства. Операция select - для опроса: есть ли поступившие в устройство данные (нап-
ример, есть ли в clist-е ввода с клавиатуры байты? см. главу "Экранные библиотеки").
Вызов select применим только к некоторым байтоориентированным устройствам и сетевым
портам (socket-ам). Если данное устройство не умеет выполнять такую операцию, то
есть запрос к этой операции должен вернуть в программу ошибку (например, операция
read неприменима к принтеру), то в переключательной таблице содержится специальное
имя функции nodev; если же операция допустима, но является фиктивной (как write для
/dev/null) - имя nulldev. Обе эти функции-заглушки представляют собой "пустышки":
{}.
Теперь обратимся к блочно-ориентированным устройствам. UNIX использует внутри
ядра дополнительную буферизацию при обменах с такими устройствами|-. Использованная
нами выше функция bp=bread(dev,bno); производит чтение физического блока номер bno с
устройства dev. Эта операция обращается к драйверу конкретного устройства и вызывает
чтение блока в некоторую область памяти в ядре ОС: в один из кэш-буферов (cache,
"запасать"). Заголовки кэш-буферов (struct buf) организованы в список и имеют поля
(см. файл <sys/buf.h>):
b_dev
код устройства, с которого прочитан блок;
b_blkno
номер физического блока, хранящегося в буфере в данный момент;
b_flags
флаги блока (см. ниже);
b_addr
адрес участка памяти (как правило в самом ядре), в котором собственно и хранится
содержимое блока.
Буферизация блоков позволяет системе экономить число обращений к диску. При обраще-
нии к bread() сначала происходит поиск блока (dev,bno) в таблице кэш-буферов. Если
блок уже был ранее прочитан в кэш, то обращения к диску не происходит, поскольку
копия содержимого дискового блока уже есть в памяти ядра. Если же блока еще нет в
кэш-буферах, то в ядре выделяется чистый буфер, в заголовке ему прописываются нужные
значения полей b_dev и b_blkno, и блок считывается в буфер с диска вызовом функции
bp->b_flags |= B_READ; // род работы: прочитать
(*bdevsw[major(dev)].d_startegy)(bp);
// bno и минор - берутся из полей *bp
из драйвера конкретного устройства.
Когда мы что-то изменяем в файле вызовом write(), то изменения на самом деле
происходят в кэш-буферах в памяти ядра, а не сразу на диске. При записи в блок буфер
помечается как измененный:
b_flags |= B_DELWRI; // отложенная запись
____________________
|- Следует отличать эту системную буферизацию от буферизации при помощи библиотеки
stdio. Библиотека создает буфер в самом процессе, тогда как системные вызовы имеют
буфера внутри ядра.
А. Богатырев, 1992-95 - 250 - Си в UNIX
и на диск немедленно не записывается. Измененные буфера физически записываются на
диск в таких случаях:
- Был сделан системный вызов sync();
- Ядру не хватает кэш-буферов (их число ограничено). Тогда самый старый буфер (к
которому дольше всего не было обращений) записывается на диск и после этого
используется для другого блока.
- Файловая система была отмонтирована вызовом umount;
Понятно, что не измененные блоки обратно на диск из буферов не записываются (т.к. на
диске и так содержатся те же самые данные). Даже если файл уже закрыт close, его
блоки могут быть еще не записаны на диск - запись произойдет лишь при вызове sync.
Это означает, что измененные блоки записываются на диск "массированно" - по многу
блоков, но не очень часто, что позволяет оптимизировать и саму запись на диск: сорти-
ровкой блоков можно достичь минимизации перемещения магнитных головок над диском.
Отслеживание самых "старых" буферов происходит за счет реорганизации списка
заголовков кэш-буферов. В большом упрощении это можно представить так: как только к
блоку происходит обращение, соответствующий заголовок переставляется в начало списка.
В итоге самый "пассивный" блок оказывается в хвосте - он то и переиспользуется при
нужде.
"Подвисание" файлов в памяти ядра значительно ускоряет работу программ, т.к.
работа с памятью гораздо быстрее, чем с диском. Если блок надо считать/записать, а он
уже есть в кэше, то реального обращения к диску не происходит. Зато, если случится
сбой питания (или кто-то неаккуратно выключит машину), а некоторые буфера еще не были
сброшены на диск - то часть изменений в файлах будет потеряна. Для принудительной
записи всех измененных кэш-буферов на диск существует сисвызов "синхронизации" содер-
жимого дисков и памяти
sync(); // synchronize
Вызов sync делается раз в 30 секунд специальным служебным процессом /etc/update,
запускаемым при загрузке системы. Для работы с файлами, которые должны гар