Чтение и запись в /sys на Сях

Конечно можно сделать по тупому, но наверняка есть какие-то функции для этого?

Весь смысл псевдо-ФС типа sys или proc заключается в том, чтобы использовать те же open/read/write/close, что и для файлов.

$100500

Заранее хочу предупредить о подводном камне: inotify не работает с /sys (по крайней мере с некоторыми файлами).

Обязательно на C? Да ещё с таким владением ЯП, что даже читать и писать файлы не можешь?

Да. Могу, но я просто думал, что такое делается через стандартные библиотечные функции. После МК мне пока сложно писать под компы.

но наверняка есть какие-то функции для этого?

fopen, fscanf, fprintf, fclose

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

Именно через стандартные библиотечные функции это и делается, функции есть в стандартной библиотеке. Не знать этого, зная C...

После МК мне пока сложно писать под компы.

Под компы писать проще. В ОС и библиотеках всё за тебя уже сделано, знай только дергай что тебе нужно.

Лучше по-моему брать функции open, read, write, close. Низкоуровневей

для некоторых файлов в /proc есть аналоги в виде функций

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

Все правильно объяснил.

для некоторых файлов в /proc есть аналоги в виде функций

А может быть всё было наоборот? :)

Лучше уж тогда posix функции юзать, open, read, write, close.

Да зачем? Вы странные какие-то. Юзайте посиксный sbrk вместо malloc, умники. Есть удобные текстовые файлы, есть удобная стандартная библиотека, зачем велосипеды городить?

Например затем, что fwrite добавит ненужную буферизацию, так что в конце надо будет еще fflush делать.

Весь смысл псевдо-ФС типа sys или proc заключается в том, чтобы использовать те же open/read/write/close, что и для файлов.

Весь смысл псевдо-ФС типа sys или proc заключается в том, чтобы создать жуткий оверхед при элементарном вызове функции драйвера. Этот оверхед в свою очередь должен вызывать повышенное излучение тепла процессорами под управлением GNU Linux, которое приведёт к потеплению климата и вымиранию человеков, ниша которых наконец-то будет заполнена роботами. Каждый раз обращаясь к sys или proc ты вбиваешь очередной гвоздик в гроб для всего человечества.

Каждый раз обращаясь к sys или proc ты вбиваешь очередной гвоздик в гроб для всего человечества.

Не расстраивайся. Вот тебе нека.

Есть setvbuf. А ОПу достаточно fclose в конце. А от самого буфера никуда не деться: что snprintf+write, что просто fpritnf.

sbrk не является аналогом malloc, он сегмент данных просто удлинняет. Чтобы из него сделать аналог malloc надо еще какие-то обертки клепать над ним. Кроме того его из позикса выкинули еще в 2001 году. Вот что в мане написано

4.3BSD; SUSv1, marked LEGACY in SUSv2, removed in POSIX.1-2001.

Более точным аналогом malloc будет mmap c флагами MAP_PRIVATE MAP_ANONYMOUS.

Да знаю я.

А от самого буфера никуда не деться: что snprintf+write, что просто fpritnf.

Можно использовать open с флагами O_DIRECT и O_SYNC

А теперь подумай какой толк от них на /sys

На /sys толку может и не быть, но если например куда-нибудь в /proc/pid/mem к чужому процессу надо залезть и что-то там переписать, или через /dev/mem ядро налету пропатчить, это может иметь смысл. Но это уже особые извращения

через /dev/mem ядро налету пропатчить

А ты шутник :3

И как это спасет от буферизации, которая по факту у тебя есть, так как snprintf ?

А от этой буферизации с произвольным snprintf и спасаться-то не надо, т.к. она - добро. Хотя в особых случаях вместо snprintf+write эффективнее будет использовать writev.

таким образом иногда реализуются юзерспейс дрова... хак по крайней мере известный в определенных кругах ;)

ВАИСТЕНУ!!!!

В линуксе есть еще особые сисколы sendfile и splice, которым даже такой буфер не нужен, все делается из пространства ядра

Круто, конечно, но не по теме. :)

/proc нужен для убунтушных bash хакеров. там где важна произвдодительность, используют другие интерфейсы