free

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

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

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

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

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

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

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

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

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

вот скажем 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

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

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