procfs

8-я редакция UNIX

Впервые procfs появилась в вышедшей в 1985 году 8-й редакции UNIX и была призвана предоставить интерфейс для управления процессами, более удобный, чем вызов ptrace. Она была подробно описана Томом Киллианом в работе «Processes as Files» («Процессы как файлы») в 1984 году. Каждый процесс был представлен файлом, в который могла производиться запись. Количество имеющихся вызовов ioctl равнялось 11.^[1][2]

System V release 4

Данная система, вышедшая в 1990 году, унаследовала procfs из UNIX 8, с некоторыми усовершенствованиями. Процессы по-прежнему представлялись простыми файлами, но были доступны уже 37 вызовов ioctl. ФС стала достаточной для построения на её базе утилит наподобие ps, но оставалась неудобной и плохо расширяемой.^[1]

Реализация подробно описана в работе Роджера Фолкнера и Рона Гомеса «The Process File System and Process Model in UNIX System V» в 1991 году.

Plan 9

В 1992 году вышел первый публичный релиз ОС Plan 9. Это был пик развития procfs. Всё управление процессами было перенесено сюда. Процессы стали каталогами вместо файлов. Вместо ioctl стали использоваться текстовые команды, и управление могло производиться командами cat и ls.^[3] При монтировании /proc с другого компьютера через сеть локальный процесс мог взаимодействовать с удалённым так, как будто они находились на одной машине.

Solaris 2.6

Solaris 2.6 во многом унаследовал структуру procfs от Plan 9, однако все расположенные там файлы были двоичными, предназначенными для использования программой, а не человеком.^[1] В целом файловая система стала несколько примитивнее по сравнению с таковой в Plan 9, но несравнимо более развитой по сравнению с SVR4.

4.4 BSD

Это был ещё один шаг назад по сравнению с Solaris. Количество файлов в каждом каталоге уменьшилось до 8 (хотя в более поздних релизах слегка увеличилось). Набор доступных команд также существенно сократился. Стал происходить обратный переход, от файловых интерфейсов к системным вызовам.^[1]

В современных версиях FreeBSD procfs постепенно ликвидируется^[4][5].

Linux

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

В то же время свою первоначальную функцию — управление процессами — procfs почти не выполняет. Интерфейс отправки команд отсутствует, файловая система лишь предоставляет подробную информацию о процессах (и кое-где позволяет изменить некоторые опции, например, /proc/<pid>/oom_adj).^[6]

*BSD

Каждый каталог верхнего уровня содержит следующие файлы:

• ctl — файл только для записи, поддерживающий множество операций, которые записываются в него в виде строк:
  • attach — останавливает целевой процесс и подготавливает вызывающий его процесс для выполнения отладки целевого.
  • detach — продолжает выполнение целевого процесса и снимает его из-под контроля процесса-отладчика (последний не обязан быть вызывающим процессом).
  • run — продолжает выполнение целевого процесса до поступления сигнала, достижения точки останова или завершения целевого процесса.
  • step — выполняет одну команду целевой программы, не генерируя иных сигналов.
  • wait — ожидает когда целевой процесс достигнет стабильного состояния, готового для отладки. Целевой процесс должен быть в этом состоянии до того как будут разрешены другие команды.
• dbregs — отладочные регистры, соответствующие struct dbregs в <machine/reg.h>. dbregs сейчас применяется лишь в архитектуре i386.
• etype — тип выполняемого файла к которому идет обращение в file.
• file — символьная ссылка на файл, из которого читался текст процесса. Это может использоваться для получения доступа к таблице идентификаторов процесса или для запуска новой копии процесса. Если файл не найден, то целевое направление принимает значение «unknown».
• fpregs — регистры с плавающей запятой, соответствующие struct fpregs в <machine/reg.h>. fpregs используется только на машинах с различными множествами универсальных регистров и регистров с плавающей запятой.
• map — карта виртуальной памяти процесса.
• mem — полный образ виртуальной памяти процесса. Можно обратиться лишь к тому адресу, который существует в процессе. Чтение и запись в этот файл изменяют процесс. Запись в текстовый сегмент применяется лишь для этого процесса (изменения не повлияют на другие копии этого процесса).
• note — используется для отправки сигнала процессу. Не применяется.
• notepg — используется для отправки сигнала группе процессов. Не применяется.
• regs — позволяет доступ на чтение и запись к множеству регистров процесса. Данный файл содержит структуру двоичных данных struct regs описанную в <machine/reg.h>. regs доступен на запись только когда процесс остановлен.
• rlimit — файл, доступный только на чтение, содержащий текущий и максимальный размер. Каждая строка имеет формат rlimit current max, где −1 обозначает бесконечность.
• status — статус процесса. Файл доступен только для чтения и содержит единственную строку, состоящую из полей, разделённых пробелами:
  • имя команды
  • id процесса
  • id родительского процесса
  • id группы процесса
  • id сессии
  • major, minor управляемого терминала, или −1, −1 в ином случае
  • список флагов процесса: ctty если это управляемый терминал, sldr если процесс управляет сессией, noflags если ни один из вышеперечисленных флагов не установлен
  • время запуска процесса в секундах и микросекундах, разделённых запятой
  • время пользователя в секундах и микросекундах, разделённых запятой
  • системное время в секундах и микросекундах, разделённых запятой
  • время ожидания сообщения
  • мандат процесса, состоящий из id фактического пользователя и списка групп (первый элемент которого является id фактической группы), разделённых запятой
  • имя хоста, в пределах которого запущен процесс, или «-» если процесс запущен без ограничений