LINUX.ORG.RU

Доступ к ядру Linux через файловую систему /proc

 , , ,


0

0

Виртуальная файловая система /proc предлагает новый подход к взаимодействию ядра Linux® и пользовательского пространства. В этой файловой системе содержатся виртуальные файлы, путем чтения и записи которых можно манипулировать структурами ядра. В отличие от обыкновенных файлов, их содержимое динамически генерируется ядром. Данная статья расскажет вам о виртуальной файловой системе /proc и покажет ее в действии.

>>> Подробности

★★★

Проверено: Shaman007 ()
Ответ на: комментарий от anonymous

> думаю, всё же так: ядро.данные->ps.данные->ps.текст

А теперь внимание, шоу! У ответсвенной за контекст процесса структуры появилось четыре новых атрибута, называемых например приоритет ввода-вывода, метка уровня доступа, группа процессов, группа процессов ввода-вывода. Ваши действия? Да, и еще интересно - как вы представите список открытых процессом фалов? А как у вас там с доступом к переенным среды процесса (environ)?

no-dashi ★★★★★
()

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

гениально!

isden ★★★★★
()

Я не спец по кернелу, но если и правдо то что в /proc читать можно только через парсинг текстовых файлов, а прямого АПИ, позволяющего читать структуры нету - то тогда ЭТО ТАКИ ГОВНЕЦО, товаиисчи...

[новый анонимус]

anonymous
()
Ответ на: комментарий от anonymous

> Я не спец по кернелу

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

anonymous
()
Ответ на: комментарий от anonymous

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

А от того что структуры меняются это уже забота кернел-девелоперов и прочих кто эти структуры читает. АПИ ядра всеравно меняется как не в себя - так что не страшно.

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

Так что как не крути - а если новые атрибуты появляются то текст не спасет. А ЕСЛИ прямого АПИ на чтение нету - то тогда это БЕЛЫМИ НИТКАМИ ШИТО.

[тот же новый анонимус]

anonymous
()
Ответ на: комментарий от anonymous

> А от того что структуры меняются это уже забота кернел-девелоперов и прочих кто эти структуры читает.

Ты эти структуры читать собрался сейчас. Из юзерспейса спросить ядро.

> Соответсвенно скрипт на привычных позициях будет читать лабуду.

Вы наркоман что ли? Какие позиции?

$ head -n 5 /proc/meminfo
MemTotal: 1035116 kB
MemFree: 122636 kB
Buffers: 85304 kB
Cached: 209408 kB
SwapCached: 32164 kB

Появится новое поле в любом месте — никаких проблем. /(\S+):\s*(\d+)\s+([kMG]B)/ все решит. В отличие от получения некоего struct { long mem_total, long mem_free, ... }

anonymous
()
Ответ на: комментарий от anonymous

>Ты эти структуры читать собрался сейчас. Из юзерспейса спросить ядро.

Нет, например я пишу модуль ядра, который и будет, из не юзер спейса, читать инфу про ядро.

>Вы наркоман что ли? Какие позиции?

Поменяй местами MemTotal с MemFree.

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

[тот же новый анонимус]

anonymous
()
Ответ на: комментарий от anonymous

>В отличие от получения некоего struct { long mem_total, long mem_free, ... }

э-э-э а теперь объясните, а нахрена забиваться именно на жёсткую структуру? есть же способы погибче.

WatchCat ★★★★★
()
Ответ на: комментарий от WatchCat

>есть же способы погибче.

Например? Визде /proc?

Тогда почему инод описан именно структурой, а не каким то там текстовым файлом в какойто там псевдо фс?

[тот же новый анонимус]

anonymous
()
Ответ на: комментарий от anonymous

>Тогда почему инод описан именно структурой, а не каким то там текстовым файлом в какойто там псевдо фс?

Да причём тут текстовый файл?

Я говорю об апи. зачем представлять значения в /proc в виде жёстко заданной структуры?

WatchCat ★★★★★
()
Ответ на: комментарий от anonymous

> Тогда почему инод описан именно структурой, а не каким то там текстовым файлом в какойто там псевдо фс?

Описано все структурами. А вот как экспортируется — другой вопрос.

То, что у чего-то нет обычного plain and simple text представления — значит только одно из двух: а) это никому не потребовалось или б) это упущение и недоделка.

Кастую в тред выездную бригаду с plan9.org.ru (кстати, что с ним?)

anonymous
()

Ну вот во ФриБСД /проц нет, хотя можно смонтировать при желании. Все делается через сисцтл. Пожалуй это все же удобнее, чем /проц, хотя /проц тоже вполне неплохо.

В линуксе тоже есть некоторый сисцтл.

Правда и то и другое мало документировано. Какие значения что означают, какие можно менять и каковы значения.

Кто-нибудь знает какую-нибудь документацию?

dmitryilyin
()
Ответ на: комментарий от no-dashi

>А теперь внимание, шоу! У ответсвенной за контекст процесса структуры появилось четыре новых атрибута, называемых например приоритет ввода-вывода, метка уровня доступа, группа процессов, группа процессов ввода-вывода. Ваши действия?

Добавляем поля в структуру, sizeof() в ответе естессно увеличивается

>Да, и еще интересно - как вы представите список открытых процессом фалов? А как у вас там с доступом к переенным среды процесса (environ)?

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

anonymous
()
Ответ на: комментарий от no-dashi

>Ну-ка, расскажи нам всем, как ты более эффективно и более гибко представишь содержимое /proc/modules не в текстовом виде. Ждем с нетерпением :-)

Да, о древовидных структурах "продвинутые" линуксоеды и не подозревают...

anonymous
()
Ответ на: комментарий от anonymous

А если отменить /proc то теперь я не смогу посмотреть cat /proc/sys/net/ipv4/ip_forward , и включить его если надо, для этого специальная программа на C понадобится?

sin_a ★★★★★
()
Ответ на: комментарий от sin_a

>А если отменить /proc то теперь я не смогу посмотреть cat /proc/sys/net/ipv4/ip_forward , и включить его если надо, для этого специальная программа на C понадобится?

А чтобы посмотреть /proc/sys/net/ipv4/ip_forward специальной программы на С разве не надо? Тем более, что в рамках одной утилиты можно связать работу со многими параметрами, не набирая при этом длюннющие пути, как в случае с /proc

anonymous
()
Ответ на: комментарий от anonymous

> А чтобы посмотреть /proc/sys/net/ipv4/ip_forward специальной программы на С разве не надо?

Специальной — не надо, cat подойдет.

Иначе мы скатимся к венде и ее реестру со специальными программами. Sysctl'ы это как раз в эту оперу.

anonymous
()
Ответ на: комментарий от anonymous

> А чтобы посмотреть /proc/sys/net/ipv4/ip_forward специальной программы на С разве не надо?

А такая программа уже и так есть. В UNIX всё есть файл. И конечно есть программы для работы с ними, чтения и многое другое.

sin_a ★★★★★
()
Ответ на: комментарий от sin_a

Зато вместо двух программ (cat, echo) нужна только одна - sysctl :)

anonymous
()
Ответ на: комментарий от sin_a

> В UNIX всё есть файл.

4.2. В UNIX и GNU/Linux не все есть файл. И GNU/Linux катится от этого в задницу, достаточно только посмотреть на ALSA с их долбанутым интерфейсом вместо куда более человеческого /dev/dsp.

anonymous
()
Ответ на: комментарий от anonymous

>top, mount, ps, gdb, lsdev, quota, vmstat, chown, ip, arp, route... продолжать?

насколько помню апачка без /proc не работает

borisych ★★★★★
()
Ответ на: комментарий от anonymous

>Иначе мы скатимся к венде и ее реестру со специальными программами.

гном уже скатился до рееестра и gconf, ты просто слишком предвзят по отношению к венде

>Sysctl'ы это как раз в эту оперу.

ну это не тебе решать

anonymous
()
Ответ на: комментарий от anonymous

> гном уже скатился до рееестра и gconf

Пользуясь случаем передаю привет Мигелю.

> ты просто слишком предвзят по отношению к венде

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

> ну это не тебе решать

Запрещаете? А я плевать хотел, беру и решаю. Для себя.

____ 1) Да, «то то, что что-то». Я тут вам не мастер словесностей. In before Grammar Nazi.

anonymous
()
Ответ на: комментарий от anonymous

Всё очень просто...

KISS

Что, применительно к данному топику, можно перевести как "чмоки всем в этом чате". UNIX хорош тем, что это конструктор. Просто конструктор.

sin_a ★★★★★
()

deprecated давно, а все - из танка никак не вылезут :-/ "лучше для меня" и "лучше" not equals.

BasileyOne
()

"эффективный" и "эффективнее" , это вообще-то - из лексикона Strogg-ов. Ахтунг ! Силы Зла detected !

BasileyOne
()
Ответ на: комментарий от no-dashi

> А теперь внимание, шоу!

Вот уж действительно шоу.... И от тебя уж никак не ожидал.

> Ваши действия?

Пересборка программы с новыми kernel headers.

Нынешний /proc - это костыль, опереться пока нет стабильного krenel API. То, что на нем долго скачут не заменяет необходимость лечить ноги. Хотя наглядно демонстрирует необходимость лечить голову.

LamerOk ★★★★★
()
Ответ на: комментарий от sin_a

Кстати, было бы совсем не плохо. Куда как лучше сделать осознанный выбор в специализированной программе, чем вводить шаманские заклинания, меняющиеся от ведра к версии и обратно, пристукивая в бубен с логотипом гугла. Хотя теряется такая заманчивая и изящная Ъ unix-вейная возможность сделать cat /dev/null > /proc/somthing ...

LamerOk ★★★★★
()

Наконец-то, теперь то всех заставят перейти на новую систему.

gh0stwizard ★★★★★
()
Ответ на: комментарий от sv75

>Поподробнее можно, я то как раз пособие пишу (надоело пересказывать LDD и LKMPG каждому делающему курсовой в отдельности)

Автор коммента загнул: в /proc хотят оставить только то, для чего он и был когда-то придуман - информацию о процессах +какая-то мелочь. Информация о прочих компонентах ядра постепенно перекочёвывает в /sys. lspci, к примеру, в /proc уже давно не лезет.

AsphyX ★★★
()
Ответ на: комментарий от AngryElf

>[*] Procfs interface (deprecated)

После этого перестаёт работать acpid. Его пока не научили получать ACPI-сообщения через /dev/input/event*. Да-да, это теперь основной способ. Короче, кнопка питания теперь действительно кнопка :)

AsphyX ★★★
()

кому нужна кнопка питания ? ;-) лишь бы похмельфс не deprecat-или.

BasileyOne
()
Ответ на: комментарий от no-dashi

> А теперь внимание, шоу! У ответсвенной за контекст процесса структуры появилось четыре новых атрибута, называемых например приоритет ввода-вывода, метка уровня доступа, группа процессов, группа процессов ввода-вывода. Ваши действия? Да, и еще интересно - как вы представите список открытых процессом фалов? А как у вас там с доступом к переенным среды процесса (environ)?

Все очень просто, создается пара новых сисколов (которые разработчики ядра по близорукости не любят создавать, как впрочем и ioctl). Один будет возвращать версию бинарной структуры, другой саму структуру. В юзерской программе типа ps или mount будет стадо фильтров входных для этих бинарных стуктур- по одному на каждую версию. Нужный фильтр будет подставляться, в зависимости от версии, котрую возвращает второй сискол. Добавили пару полей в структуру - добавили фильтр. Т.е. после обновления ядра - обновляем мир. Если мир не обновили - будет ситуация, когда во FreeBSD ядро уже от семерки, а мир еще от шестерки (т.е. запустили ifconfig, а там пусто). Очень удобно. Зато обмен между ядром и юзерспейсом бинарный - очень эффективный.

Это черный стеб, кто в танке. Пацаны, вопросы на засыпку, зачем придумали XML, почему proc больше 10 лет не меняет формат и что как обеспечить стабильность работы юзерспейс программи при смене функционала ядра? Вопрос для упрощения мыслительного процесса: как сделать при бинарном формате, чтобы при добавлении новых полей в эти структуры, написанный пару лет назад ps продолжал работать? Ну и что делать после этого шелловским скиптам с бинарным фоматом? cat /proc/net/nf_conntrack | grep ... | wc -l При бинарном подходе для каждого файла в проц потребуется свой конвертор в текст, чтобы этими данными можно было пользоваться в скриптах.

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

anonymous
()
Ответ на: комментарий от anonymous

> А от того что структуры меняются это уже забота кернел-девелоперов и прочих кто эти структуры читает. АПИ ядра всеравно меняется как не в себя - так что не страшно. Кстати, вот хорошо, из поста выше, да добавились новые атрибуты, и они же новые пишутся в текстовые конфиги, да так пишутся что не в конец, а в перемешку со старыми. --> Соответсвенно скрипт на привычных позициях будет читать лабуду. Так что как не крути - а если новые атрибуты появляются то текст не спасет. А ЕСЛИ прямого АПИ на чтение нету - то тогда это БЕЛЫМИ НИТКАМИ ШИТО.

кароче. лет пять назад дебиановский apt+dpkg, который работал с текстовыми файлами через grep имел функционал и скорость выше, чем существующий Yum+rpm, который толи через Berkly DB, то ли SQLite работают.

anonymous
()
Ответ на: комментарий от Adjkru

Аа, sysctl в линуксе это просто костыль к /proc/sys, судя по ману :)

Adjkru ★★★★★
()

Я чего то не понимаю, или /proc не такая уж и новая???

Vitaly-KF
()

Мда, не смешно, на дворе 21 век, а люди требуют бинарных интерфейсов. Бедный Реймондс икает.

sv75 ★★★★★
()
Ответ на: комментарий от anonymous

> Добавляем поля в структуру, sizeof() в ответе естессно увеличивается

sizeof выполняется на этапе компиляции. Так что ты в пролёте. :)

anonymous
()
Ответ на: комментарий от sin_a

> В UNIX всё есть файл.

В последнее время от этого отходять :( Попробуйте найти файл устройства eth0, или файл устройства звуковой карты через alsa (не через alsa-oss, для которой так и остануться /dev/{mixer,dsp,..})

anonymous
()
Ответ на: комментарий от anonymous

А чего отходят, интересно? Что не устраивает?

anonymous
()
Ответ на: комментарий от sv75

>И ты предлагаещь переписать их все на новый API, который еще и анти-unix-way?? O_O

+1
Файлы и текст - наше все.

shlag
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.