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

Когда вынесут в sysctl, чтоб из userlevel приложений не парсить текстовые файлы (например /proc/<PID>/stat), а получать структуру с нужной информацией напрямую через системный вызов?

Пипец.... Закапывайте!

/proc вот-вот deprecated объявят, а они тут проснулись...

Ахтунг! Вендузятнег детектед!

moar /proc?!!

А про ту-же /sys нормальной информации на русском почти и нет. :(

> Вендузятнег детектед!

И что же тут вендузятного?

Хочется сделать поэффективней, зачем форматировать (ядро) а затем парсить обратно, если можно просто скопировать?

ты не злой, ты тупой

действительно ты подметил, брат: в _абсолютном большинстве_ случаев делается совершенно не нужная работа, +1

> Хочется сделать поэффективней, зачем форматировать (ядро) а затем парсить обратно, если можно просто скопировать?

А ты не думал, что есть те кто со /proc из скриптов работают?

>Виртуальная файловая система /proc предлагает *новый* подход к взаимодействию ядра Linux

машина времени опять назад откатилась?

> Когда вынесут в sysctl, чтоб из userlevel приложений не парсить текстовые файлы

Удобно будет grep'ать, да

Что ж у тебя за задача такая?

>А ты не думал, что есть те кто со /proc из скриптов работают?

Каков общий объем "работ" со скриптов по сравнению с обыденными обращениями прикладных программ? Текущая форма обмена данными избыточна (в разы).

>Удобно будет grep'ать, да

Что, например?

> /proc вот-вот deprecated объявят, а они тут проснулись...

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

> А ты не думал, что есть те кто со /proc из скриптов работают? > Каков общий объем "работ" со скриптов по сравнению с обыденными обращениями прикладных программ?

Список программ в студию пожалуйста.

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

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

>Хочется сделать поэффективней

Это разве узкое место?

>зачем форматировать (ядро) а затем парсить обратно, если можно просто скопировать?

Текст это ОЧЕНЬ переносимо и гибко.

Очень грамотная и хорошая статья.

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

А на каждый чих писать костыльный текстовый парсер - это true-unix-way?

> proc вот-вот deprecated объявят, а они тут проснулись...

Это кто вам такое сказал?

>И ты предлагаещь переписать их все на новый API

можно ввести ioctl или syscall и первое время пусть существуют параллельно

>Текст это ОЧЕНЬ переносимо и гибко.

Это пока ты там "ручками" работаешь, а когда настанет час написать что-нибудь посложнее "hello world" c тесной интеграцией в систему - тогда будешь изобретать свой велосипед (парсер), как и все твои предшественники

+ ко всему: невозможность использования всей этой "гибкости" если /proc по какой-то причине не монтируется (и такое случалось) - вот и гадай

sysfs уже сильно устарела? Пингвинёный мир хочет иметь две разные ФС, которые по сути можно без особых жертв заменить одной? ;)

Я хотел бы сказать, что файлы procfs не читабельны, что какая цифра значит - ни когда не узнаешь, пока не откроешь исходники ;)

yantux

от sysctl избавляются, стараются делать что бы через этот вызов можно сделать как можно меньше.

и где написано, что /proc хотят выкинуть?

> тогда будешь изобретать свой велосипед (парсер), как и все твои предшественники

Можно подумать, что scanf сложен а regexp-ы вообще в голове не укладываются ?

// darkk

>>Текст это ОЧЕНЬ переносимо и гибко.

>Это пока ты там "ручками" работаешь, а когда настанет час написать что-нибудь посложнее "hello world" c тесной интеграцией в систему - тогда будешь изобретать свой велосипед (парсер), как и все твои предшественники

да какие там парсеры? О.о 99% случаев позволяют использовать регулярные выражения и не иметь никаких проблем

> + ко всему: невозможность использования всей этой "гибкости" если /proc по какой-то причине не монтируется (и такое случалось) - вот и гадай

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

>> proc вот-вот deprecated объявят, а они тут проснулись...

> Это кто вам такое сказал?

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

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

Не путаете ли вы procfs и devfs (которая deprecated)?

Нет, не путаю.

Более того, коллега подошел, заглянул через плечо и сказал то же, что и я, мол, /proc депрекатед в пользу /sys...

Ладно, может я и вру, но, по крайней мере, я такой не один и вообще, свято в это верю :)

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

> Не путаете ли вы procfs и devfs (которая deprecated)?

+1, только что проверил - procfs не deprecated

2AngryElf: внимательнее надо, товарищ :)

Жена Торвальдса, перелогиньтесь! :-)

Накопал тут в гугле...


Power management options (ACPI, APM)  --->
       [*] Power Management support
       ACPI (Advanced Configuration and Power Interface) Support --->
               [*] ACPI Support
               [*]   Procfs interface (deprecated)


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

> Жена Торвальдса, перелогиньтесь! :-)

O.o

> А ты не думал, что есть те кто со /proc из скриптов работают?

Я _не_ хочу, чтоб /proc вообще удалили. (хотя /usr/bin/sysctl тоже никто не отменял). Просто хочется более эффективную альтернативу

>Можно подумать, что scanf сложен а regexp-ы вообще в голове не укладываются ?

На примере ps идет такая вот цепочка преобразований: ядро.данные->proc.текст->ps.данные->ps.текст - и после этого некоторые еще удивляются, почему в линуксе такой зоопарк и нет стабильного API...

в идеале должно быть: ядро.данные->ps.текст, только вот врядли у OSS сообщества хватит организованности для подобного рода решений

> в идеале должно быть: ядро.данные->ps.текст

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

(я - другой анонимус)

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

Имеется в виду, что новую конфигурацию не нужно класть в procfs, а использовать для этого sysfs.

> 99% случаев позволяют использовать регулярные выражения

Молодец, сначала имеем одну проблему, добавляем туда регекспов и... имеем две проблемы!

А я-то думаю, какого тупая софтина, читающая простейший ini-like конфиг без секций, видимо, такие же товарищи на каждый чих регекспов пихают.

Давайте уж тогда, по мотивам известного топика, все запихнем в зумель и гконф, и будем все это парсить регекспами.

Так это и говорит о том, что в проке хотят оставить информацию, которая изначально там планировалась - о процессах, остальное в /sys.

Ага... Ок, понял, пасиб.

> А на каждый чих писать костыльный текстовый парсер - это true-unix-way?

не, надо туда XML запихнуть :)) даёшь очередной флейм про xorg.conf на 50 страниц :))

> Давайте уж тогда, по мотивам известного топика, все запихнем в зумель и гконф, и будем все это парсить регекспами.

зумель - регэкспами?

> Молодец, сначала имеем одну проблему, добавляем туда регекспов и... имеем две проблемы!
Что, уже простейший конечный автомат для регэкспов стал проблемой?

> читающая простейший ini-like конфиг без секций, видимо, такие же товарищи на каждый чих регекспов пихают.
А что, простейший ini-like конфиг (с секциями или без) это не регулярная грамматика в чистом виде, для которой регэкспы и придуманы? Нет, можно все сделать руками (итог будет тем же самым, в общем-то), но зачем?

Хотя вообще давно пора бы сделать нормальный /proc. Чтобы было как в reiser4:

$ cat /proc/net/sockstat
sockets: used 524
TCP: inuse 15 orphan 0 tw 0 alloc 19 mem 7
UDP: inuse 9
UDPLITE: inuse 0
RAW: inuse 0
FRAG: inuse 0 memory 0
$ cat /proc/net/sockstat/tcp/inuse
15

Вот это будет грамотно и правильно.

> зумель - регэкспами?

Ну, такие любители разбора ini-файлов руками в университетах не учились, просто, и о том, что есть разные грамматики не в курсах. Они зато сурово по-дедовски умеют написать разбор ini-файла чтением строки, поиском в ней знака "=" и разрезанием. Хотя это, реально, как минимум в 2 раза дороже, чем использование регулярных выражений.

Впрочем, зумель можно и "регэкспами". Бают (без доказательств, правда, по крайней мере я не видел) что PCRE (как в Perl5) Тьюринг-полны.

Почитай топик про xorg.conf, всего-то 50 страниц, но там и не такие извраты предлагали :)

> а когда настанет час написать что-нибудь посложнее "hello world" c тесной интеграцией в систему - тогда будешь изобретать свой велосипед (парсер), как и все твои предшественники

Зато не придется ничего перекомпилировать, когда в какой-нибудь структуре появится новое поле.

> Просто хочется более эффективную альтернативу

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