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

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

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

даешь /proc в xml! :)

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

да ты что! для тупых вантузятников "регексп" - это что то из некрономикона. а былопрграмеры вантузные про libpcre даже не слышали

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

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

может еще вантуз поставить? ну фантазеры. ну квестопридумщики

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

хреново там это сделано. но мы не о том. как ты дебил из скрипта будешь структуры бинарные доставать?

тут все работает годами замечательно, но в один прекрасный день приходят вантузятники ("слепые с рождения") и начинают нам рассказывать что так "не может быть", "не должно", "балмер не освятил" ("цвета не нужны, быть слепыми лучше!")

блин, прыщавая молодежь, вы хоть осознаете насколько смешны? :)

>Хотя вообще давно пора бы сделать нормальный /proc. Чтобы было как в reiser4: >$ cat /proc/net/sockstat >$ cat /proc/net/sockstat/tcp/inuse

надо просто чтобы гдето в /proc/net или /proc/metadata лежала схема, описывающая структуру этих файлов. или "бинарный" парсер-транслятор в /proc/parsers/blablaname, через который доступны эти данные по пути вида /proc/parsers/blablabla/net/sockstat

То есть, чтобы отдельная ветка в /proc/net была самодостаточной, самоописываемой. Получим все прелести XML как самоописываемого формата и схемы + без его костылей для хранения. А если кому-то этот XML так понадобится, можно и в него "экспортировать" по пути вроде /rpc/parsers/xml/blablabla/net/sockstat

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

сосать метаобъектный протокол, бинарную совместимость и какой-либо язык запросов. Как в объектных БД, они же как-то изменение структуры объекта переживают?

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

и как же оно сделано в винде? те же объекты ядра в виде ФС \\.\blablabla, только корень этой ФС не смонтирован, корень настоящей ФС подмонтирован в ветку этой, а просто так не остальные ветки этой "ФС объектов ядра" не все просто так смонтируешь

> такая программа уже и так есть. В UNIX всё есть файл.

да-да-да, всё это файл. И сокет файл, правда lseek нельзя делать и отвалиться может. И блочные устройства -- файл, правда lseek тоже с трудом, и из него содержимое вываливается разное каждый раз. И пайпы -- файл, и юникс-сокеты, и инет-сокеты (вот тебе тоже две "почти" одинаковых сущности). И псевдотерминал тоже файл (толком ни файл ни устройство, сплошная эмуляция. Очень искусственная сущность). И видеооверлеи тоже файл, ага. И экран - - файл, только с каким-то нестандтным интерфейсом, когда требуется 2d/3d ускорение, видео, и т.п.

//insert standart disclaimer here (Unix Haters Handbook)

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

типизации вот только не хватает. Файл -- это сплошной нетипизированный поток байтов, объект -- это сущность, имеющая структуру и связи-отношения с другим объектом и системой типов объектов. Осталось подумать, почему интерфейс этой структуры нельзя описать в терминах её самой.

> Пацаны, вопросы на засыпку, зачем придумали XML,

1. самоописываемый формат: контейнер задаёт структуру данных 2. отвязаться от big endian/low endian 3. универсальность ценой эффективности (превед, строгги)

> почему proc больше 10 лет не меняет формат

зачем?

> и что как обеспечить стабильность работы юзерспейс программи при смене функционала ядра?

не ломать ABI ядро-программы в этом месте. Вроде C++ в ядре пока ещё нет, можно бы и не ломать.

>как сделать при бинарном формате, чтобы при добавлении новых полей в эти структуры, написанный пару лет назад ps продолжал работать?

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

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

не факт. Если будет что-то вроде MOP по бинарному формату, конвертор может быть один универсальный.

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

Неправда ваша: http://mydebianblog.blogspot.com/2008/07/proc.html

про /sys там немного, но зато есть про /proc

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

пускай их требуют. Из текстового бинарный завсегда сделать можно. Назад вот не всегда.

>тут все работает годами замечательно, но в один прекрасный день приходят вантузятники ("слепые с рождения") и начинают нам рассказывать что так "не может быть", "не должно", "балмер не освятил" ("цвета не нужны, быть слепыми лучше!")

бугога. Прыщавые виндузятники писали Unix Hater's Handbook и по слогам разбирали чем плоха ситуация когда ps выдает нетипизированный просто текст и cut/sed/awk его парсят (ломая скрипты на них при изменении выхлопа ps) и как хорошо у них в PowerShell что монады только нужного типа а выхлоп текста по типизированным данным строится.

Потом уже правда, и ps подкрутили, и выхлоп настраивается, а осадочек-то остался :))

Люди требуют не столько бинарных интерфейсов, сколько интерфейсов, как таковых. Потому как произвольный текст в качестве _интерфейса_ ну никак не катит.

интерфейса чего? для хранения конфигов, произвольный текст вполне себе интерфейс :) правда парсер к нему гвоздями прикручен (зато голова не болит с big/low endian). Парсер бы отодрать от остального и описать в этом самом хранимом тексте -- и будет универсальность.

какой интрефейс ? API ? ABI ? вам в Виндовз ?

p.s. cм речь тов. Линуса на эту тему(множество таковых).

> А теперь внимание, шоу! У ответсвенной за контекст процесса структуры
> появилось четыре новых атрибута, называемых например приоритет ввода-
> вывода, метка уровня доступа, группа процессов, группа процессов
> ввода-вывода. Ваши действия?
Вы действительно не знаете, как поступают в
таких случаях, или прикалываетесь? Объясняю.
Все вызовы, которые заполняют пользовательские
структуры, принимают так же и размер этой структуры
отдельным параметром.
Все новые поля добавляются _в конец_ структуры.
Это - ключевой момент. Прога, если её не перекомпилить,
будет пытаться заполнить старую версию структуры,
но и размер будет тоже от старой передавать. И
она будет заполняться, как и раньше. А все новые
поля, те, что в конце _новой_ структуры, старую
никак не затронут.
Так делают все и всегда. Вам ли, автору пособий типа
"не для чайников", этого не знать?

> интерфейса чего? для хранения конфигов,

Вернись к первому сообщению темы. Если ты думаешь, что в /proc лежат конфиги, лучше помолчи.

Никого не волнуют речи товарища Линуса. Линус инженер как в хорошем смысле этого слова, так и не в очень. Он не видит, либо видит, но сознательно игнорирует проблемы, которые не являются чисто техническими.

Линус в первую очередь - Стратег. плохой или не очень - выходит за рамки. но в общем случае - ситуацию с ФАТАЛЬНОСТЬЮ для Linux, на данном этапе - появления API и ABI - он предсказывает, совершенно верно.

p.s. хотя для разного рода(и "размера) DE - появление таковых - вполне возможно.

p.p.s. ничто не мешает кому-то - форкнуть ядро(или выпускать патчи, Инго Молнар-стайл(в минувшем)) если вы УБЕЖДЕНЫ, что правы - ДОКАЖИТЕ !!

> ситуацию с ФАТАЛЬНОСТЬЮ для Linux, на данном этапе - появления API и ABI - он предсказывает, совершенно верно.

Разверни.

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

Если ты пишешь модуль ядра, ты можешь вообще не использовать /proc, а напрямую лазить по структурам ядра.

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

И теперь будем тащить в ядро все версии заполнения старых структур, да?

in->param1 = 0; in_parma2 = 2; switch (in->size) { case (11): { in->param5 = 10; }; case (10): { in->param3 = 3; in->param4 = 5; } }

А как насчет работы более новой версии программы на старой версии ядра? Ах, будет как в винде, "Invalid size"? А что делать с удаленными параметрами? Не удалять? А чтобы определить, какой I/O шедулер у меня используется, теперь надо использовать io_sched_ctl? Вот спасибо!!!

> Так делают все и всегда. Вам ли, автору пособий типа "не для чайников", этого не знать?

Я работал с winapi, и даже драйверы для винды писал. Так вот впечатение одно - это было ужасно. Это костыль для закрытой системы, и не более.

> Я работал с winapi, и даже драйверы для винды писал. Так вот
> впечатение одно - это было ужасно. Это костыль для закрытой системы,
> и не более.
А при чём тут винапи? Я другой анонимус, не тот, что
про винду говорил.
Так - добавление новых полей в конец структуры - делают
как раз не (только) в виндах. Это - стандартная практика.
Но как делают в виндах, я не знаю.

> А как насчет работы более новой версии программы на старой
> версии ядра?
Редко это нужно. Но прога легко может проверить версию
ядра и выругаться, если нужная ей фича отсутствует.
Всегда надо проверять наличие фич, которых может не быть.

смысл ? *собрал бисер*

те - выше все есть. что нужно.

>/proc вот-вот deprecated объявят, а они тут проснулись... File Systems -> Pseudo Filesystems -> /proc file system support(NEW) Ядро 2.6.25-gentoo-r6. Ну и где тут deprecated, Ы?

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

Нет. Труеюниксвей это когда на каждый чих надо писать прожку на си с вызовом определенного сисктл и переформатированием в текст шоб юзерь такиж увидел инфу не в байткоде, да?

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

Система где все через апи уже есть. Виндовс называется. В ем даже на васике красиво поскрипеть мона. Через всякие там говноконтейнеры добраться до системных параметров. Все проще нежели тупо сказать к примеру cat /proc/cpuinfo | grep "model name".

Не понравилось использование insmod/rmmod. Отправил пожелание использовать modprobe на основании мягкой рекомендации man страниц insmod и rmmod. Хотя не принципиально.