Linux.by

Ядро ведет статистику использования процессорного впемени для каждого процесса которую можно прочитать из файла /proc/nnnn/stats.
По сему вопрос - какой формат выводимой инфопмации?

/usr/share/doc/kernel-doc-*/Documentation/filesystems/proc.txt.gz
или <kernel-source>/Documentation/filesystems/proc.txt в помощь.

Только у себя на машине и в доках не вижу такого файла stats, есть stat, statm, status. А whois mr. Stats ?

Да-с stats это у меня гибрид status и stat
Мне нужно узнать :общее время работы процесса и % нахождения его в режиме user/kernell. Ведется ли вообще ядром такая статистика?

да, ведется, иначе как бы ps об этом узнавал?
разбирай файлики status и stat

А что на linuxe ps использует /proc ? Нехорошо как-то.
Если я kernel перестрою и /proc запрещу (а можно ли это?),
как ps то выживет?

ps сдохнет, даже если просто не дать юзверю его читать. это проверялось.

На Linux используется так называемый procps.
Это версия ps специально заточенная для /proc.

Вообще ничего плохого в том что ps использует /proc нету.
уж лучше работать через procfs чем давать право на чтение /dev/kmem или /dev/mem каждой программе сбора системной статистики (через всякие suid'ные дела). Хотя, конечно, могли бы для этого дела внедрить какойнить sysctl (как, например, сделано в FreeBSD)... Но если всё хорошее копировать с BSD, то оригинальности у линукса не останется

В AIX например есть функция (С), getproctable - она просто
загружает в пользовательский буфер инфу по процессам. И
все. Кернел то все может. Странно что на linux такого не реализовали.

exe писал(а):В AIX например есть функция (С), getproctable - она просто
загружает в пользовательский буфер инфу по процессам. И
все. Кернел то все может. Странно что на linux такого не реализовали.

А в Linux есть /proc fs, который предназначен для экспорта сис информации ядра в "пользовательский" мир. Который в общем и не является fs как в обычном понимании дисковых fs.
Зачем дублировать существующую ф-ность/идеологию новым сис вызовом ядра?
Причем этот вызов был бы не сложным по реализации но довольно большой по объему + куча флагов ввести для определения различного типа информации (NtQuerySystemInformation() в NT можно посмотреть).
Если уж очень хочется, не обязательно вводить новый вызов - можно написать простенький драйвер симв устр., который или по ioctl() запросу или просто расширяет /proc своими экспортируемыми "файлами" и возвращать из ядра все что заблагорассудится. Например, из /proc/ext/ps_id - возвращать id процессов с нек доп. инфой.

Есть небольшое преимущество при вызове простой функции -
не нужно о правах думать. А тут нужно писать код который
будет opendir/readdir/closedir делать да ещё с обработкой строк.
А ещё если формат изменят, или конфигурацию ядра. Интересно
а ftw/nftw() по /proc отработает? Надо будет проверить как
только время появится

exe писал(а):Есть небольшое преимущество при вызове простой функции -
не нужно о правах думать. А тут нужно писать код который
будет opendir/readdir/closedir делать да ещё с обработкой строк.

Это не есть гут. Так, если мне не хочется - я просто отберу права на /proc и и фиг он туда посмотрит... В случае с функциями ядра придется разбираться, как юзверю запустить выполнение именно этой функции... В BSD с этим проще, а вот линух (по крайней мере vanilla kernel) это делать не умеет. Прикрчивать в дистрибутив патчи типа RSBAC или NSA SE Linus - то еще удовольствие...

exe писал(а): Есть небольшое преимущество при вызове простой функции -
не нужно о правах думать. А тут нужно писать код который
будет opendir/readdir/closedir делать да ещё с обработкой строк.
А ещё если формат изменят, или конфигурацию ядра. Интересно
а ftw/nftw() по /proc отработает? Надо будет проверить как
только время появится

Llama писал(а): В случае с функциями ядра придется разбираться, как юзверю запустить выполнение именно этой функции... В BSD с этим проще, а вот линух (по крайней мере vanilla kernel) это делать не умеет. Прикрчивать в дистрибутив патчи типа RSBAC или NSA SE Linus - то еще удовольствие...

В ядре есть возможность проверить от имени какого пользователя был сделан некоторый сис. вызов. См. capable() + уровни привилегий на выполнение различных классов действий...
Так работаю многие сис. вызовы (снова же можно поискать в исходниках).

При считывании параметров через /proc не происходит обращение к диску за данными - это всего-лишь "интерфейс" к данным ядра, а не файлы в обычном понимании.
Единственное преимущество отдельного вызова - в том что он 1 и нет множества переключений в режим ядра и обратно как при аналогичном множественном считывании из /proc.
Недостаток - этот вызов будет слишком "большим" чтобы иметь возможность экспортировать ту же информацию что и /proc. Конечно, можно рассмотреть ряд оптимизаций (как кеширование списка параметров ядра для получения за один вызов). Хотя вряд ли это стоит выделки, не думаю что найдется много программ, которым необходима множественная инф из /proc (как ps), и что они так уж хромают производительностью.
(В любом случае концепция /proc мне кажется довольно удобной нежели сис. вызов для получения инфы, как это есть в винде. Даже для пользователя это выглядит как _вызовы_ , вообще там даже нет единого интерфейса получения списка процессов для 9x и NT.)

dimm_coder писал(а): В ядре есть возможность проверить от имени какого пользователя был сделан некоторый сис. вызов. См. capable() + уровни привилегий на выполнение различных классов действий...
Так работаю многие сис. вызовы (снова же можно поискать в исходниках).

Нет, не то. BSD можно, насколько я помню, можно указать, какую функцию какой именно пользователь может заюзать, или что-то типа того.

Llama писал(а):

dimm_coder писал(а): Нет, не то. BSD можно, насколько я помню, можно указать, какую функцию какой именно пользователь может заюзать, или что-то типа того.

Имеешь в виду настроить права вызова сис. вызовов администратору для пользователей?
Никогда не слышал, хотя можно и уточнить конечно.
В Linux с точки зрения ядра пользователь (скорее даже процесс с его провами) принадлежит к некоторым группам, которые имееют определенные права работы в режиме ядра. Раньше это было просто деление: root или нет. Начиная с 2.1 (насколько я помню) - введены более широкие классы.

ГМ, насколько я помню RSBAC и NSA SE Linux - позволяют делать что-то подобное... Вот то, что им можо контролировать...

ADD_TO_KERNEL -Добавлять модуль в ядро (для драйвера)
ALTER - Изменить контрольную информацию для IPC
APPEND_OPEN -Открытие для добавления
CHANGE_GROUP-Сменить группу
CHANGE_OWNER -Сменить Владельца
CHDIR-Сменить Каталог
CLONE-Клонировать процесс
CLOSE-Запрос на закрытие
CREATE-Запрос на создание
DELETE-Запрос на удаление
EXECUTE-Запрос на запуск
GET_PERMISSIONS_DATA-Прочитать права UNIX.
GET_STATUS_DATA- Получить информацию о файле ( вызов stat() ).
LINK_HARD-Сделать жесткую ссылку
MODIFY_ACCESS_DATA -Модифицировать информацию о времене доступа к файлу
MODIFY_ATTRIBUTE-Изменить аттрибут rsbac
MODIFY_PERMISSIONS_DATA- Изменить права Unix.
MODIFY_SYSTEM_DATA- Изменить системные данные.
MOUNT-Совершить операцию монтирования
READ-Произвести чтение.
READ_ATTRIBUTE- Произвести чтение аттрибута RSBAC.
READ_OPEN- Открыть файл для чтения.
READ_WRITE_OPEN- Открыть файл для чтения-записи.
REMOVE_FROM_KERNEL- Удалить модуль из ядра (для драйверов)
RENAME-Переименовать
SEARCH-Произволить поиск.
SEND_SIGNAL-Посылать сигнал дркгим процессам.
SHUTDOWN-Выключать/Перезагружать систему.
SWITCH_LOG-изменять параметры протоколирования RSBAC.
SWITCH_MODULE-Включать/Выключать модули.
TERMINATE- Останавливать процесс.
TRACE- Трессировать процесс.
TRUNCATE-Усекать файл
UMOUNT-Выполнять демонтирование.
WRITE-Производить запись
WRITE_OPEN-Открывать файл для записи.