Посмотрели бы исходник этой утилиты. Реализуется она через анализ файла /proc/meminfo. Реализацию можете взять из пакета procps, файл prox/sysinfo.c .

s/prox/proc

парсить /proc/meminfo конечно можно но неужели нет более прямого способа? наверняка же есть какой то системный вызов который вернет значение из переменной ядра из которой же и этот /proc/meminfo формируется

Это вам не фряха. Например, чтобы построить дерево процессов, надо анализировать содержание всего /proc (см. исходники того же procps) :)

А зачем собственно ядру такой системный вызов?

чтобы при необходимости получить эти данные не нужно было парсить текст /proc/meminfo

То есть ядру оно не нужно. А юзерспейс может и все pid'ы в proc'е обойти. Он никуда не торопится.

а зачем?

затем что эти данные все равно были и есть внутри ядра и из них формируется /proc/meminfo

Пошукайте в исходниках ядра. Можете добавить свой сисвызов, если так хочется.

И будет API как у ядра windows: более 10000 syscall'ов

Вот именно. Не понимаю, зачем по каждой мелочи дергать ядро, если можно все легко и просто сделать в userspace. Тем более, даже код писать не надо - выдрал один файл из procps, и пользуйся на здоровье.

Вот именно. Не понимаю, зачем по каждой мелочи дергать ядро, если можно все легко и просто сделать в userspace. Тем более, даже код писать не надо - выдрал один файл из procps, и пользуйся на здоровье.

Чтение из /proc - это тоже «дёрганье» ядра, просто немного другим способом.

затем что эти данные все равно были и есть внутри ядра и из них формируется /proc/meminfo

Я тоже пару лет назад думал примерно так же. Зачем сначала переводить бинарные данные в текстовые, если потом их снова надо будет перевести из текстовых в бинарные? А потом в один прекрасный момент я понял, что это удобно, и позволяет программам пространства пользователя никак не зависеть от низкоуровневого ABI ядра.

> позволяет программам пространства пользователя никак не зависеть от низкоуровневого ABI ядра.

зато добавляет привязку к определенному формату представления данных.

зато добавляет привязку к определенному формату представления данных.

Хочешь сказать, что если бы содержимое /proc/meminfo выдавалось системным вызовом в виде сишной структуры, то привязка была бы меньше?.

man sysinfo ?

>Хочешь сказать, что если бы содержимое /proc/meminfo выдавалось системным вызовом в виде сишной структуры, то привязка была бы меньше?.
меньше, ибо структура определена в /usr/include/linux/, а вот где определен формат вывода /proc/meminfo? Парсить /usr/src/linux/fs/proc/meminfo.c не лучший вариант.

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

вот только парсить meminfo-вый текст можно где и чем угодно, а сискол - только теми средствами, которые данные вызовы поддерживают

да, но только если этот сискол самому добавлять.
в данном конкретном случае это, видимо, не требуется.

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

меньше, ибо структура определена в /usr/include/linux/, а вот где определен формат вывода /proc/meminfo? Парсить /usr/src/linux/fs/proc/meminfo.c не лучший вариант.

А теперь представь, что разработчики ядра добавили в такую структуру пару дополнительных полей. Существующие парсеры /proc/meminfo продолжают работать (просто игнорируя новые поля), а программа, запрашивающая эту структуру через системный вызов, вываливается с сегфолтом.

один ноль лишний.

>много ты даже стандартных сисколов из шеловского скрипта напрямую дернуть сможешь?
это уже оффтопик :)
много ты С-программ можешь выполнить шеловским интерпретатором? :)
я тоже могу найти в твоём коде кучу всего, что не не запустится на лэптопе у юзера с какой-нибудь далёкой планеты...

если ее не перекомпилировать, то да, __в худшем случае__ свалится.
поэтому все поля в структуры добавляют в конец, а не в середину!

>вываливается с сегфолтом
то же самое произойдет и при переименовании нужного поля из /proc/meminfo

> много ты С-программ можешь выполнить шеловским интерпретатором? :)

не поверишь, все они в шэле запускаются

>не поверишь, все они в шэле запускаются

ты ничего не понял...

на самом деле, не понял ты. разговор был об универсальности представления данных. ничего более универсального, нежели plain text до сих пор не придумали.

facepalm

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

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

верх маразма - это при написании программы не задумываться о ее взаимодействии с остальным софтом.

опять-таки в данном случае plain text из /proc-а всё равно не более универсален, чем сисколл (указанный выше).

>верх маразма - это при написании программы не задумываться о ее взаимодействии с остальным софтом.

объясни мне каким образом использование сискола против обхода /proc может повлиять на «остальной софт»?

поправочка

s/не поддерживается шеллом/не доступен в шелл-скриптах/

> объясни мне каким образом использование сискола против обхода /proc может повлиять на “остальной софт”?

ядро предоставляет некий public api для доступа к своим структурам данных. для всех, а не только для тех, кто может заюзать int 80h. хочется сисколов - read/write тоже сисколы.

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

ответ не дан.
еще раз вопрос более четко:
в чем разница для “остального софта” между использованием уже существующего сисколла sysinfo против распознавания /proc/meminfo в конкретной Си программе?

>man sysinfo ?

спасибо, это то что нужно!

>вот только парсить meminfo-вый текст можно где и чем угодно, а сискол - только теми средствами, которые данные вызовы поддерживают

да, текстовое представление пригодиться для вывода человеку и для обработки какими либо скриптами, я же изнчально просил вызов для программы на C

>верх маразма - это при написании программы не задумываться о ее взаимодействии с остальным софтом.

вот скажем k3b он использует cdrecord насколько я знаю.
если он вызывает его напрямую то это явно не лучший путь, почему бы не разбить cdrecord на 2 части - libcdrecord и морду к ней cdrecord, тогда k3b будет общаться с ядром cdrecord на прямую что сулит более прямое и богатое взаимодействие, так и тут - я не предлагаю выбрасывать /proc/meminfo оно явно нужно, но нужен и более прямой способ получить то-же самое из программ на C

это linux way засирать VFS

можно более развернуто?

В линуксе все плохо.

Btw.
http://msdn.microsoft.com/en-us/library/aa366589%28v=VS.85%29.aspx

поэтому все поля в структуры добавляют в конец, а не в середину!

Этого не достаточно. Думаешь от хорошей жизни у каждой первой структуры в WinAPI есть поля типа dwVersion, dwSize, dwReserved123 и т.п.? =)

вываливается с сегфолтом

то же самое произойдет и при переименовании нужного поля из /proc/meminfo

Нормальный парсер не упадёт. На самом деле в данном случае неправильный парсер написать сложнее правильного.

> в чем разница для “остального софта” между использованием уже существующего сисколла sysinfo против распознавания /proc/meminfo в конкретной Си программе?

если есть уверенность, что sysinfo поддерживают все реализации libc под линуксом, то ничем. вот только у меня такой уверенности нет.

>Нормальный парсер не упадёт
ага! то бишь парсер, который умеет проверять полученные значения.
что также не помешает и в случае с сисколом.
разница только в том, что в одном случае придется парсер писать)
и возражения типа «это легко» данный факт не отменяют :))

>Думаешь от хорошей жизни у каждой первой структуры в WinAPI есть поля типа dwVersion, dwSize, dwReserved123 и т.п.? =)

WinAPI окостылено настолько, что страшно поддержку юникода в свои велосипеды включать.

В линупсе костылей тоже немало. Это участь всех больших систем, которые хоть как-то стараются поддерживать обратную совместимость(винда в этом смысле вообще пример для подражания).
Кстати, как раз в случае с юникодом там все отлично. Костыли начинают проявляться с 8битными строками и ссаной тучей локалей.

т.е. ты считаешь нормальным, что чтобы преодолеть рубеж «путь к файлу < 260 символов», надо в самом начале пути добавить «\\?\» ? причем такой финт ушами поддерживает только Wide-версия функций FileIO.

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