Как в linux создать устройство типа буферизированного файла?

Question

[pixik]

Добрый день!
Ситуация такая, что написано некоторое количество программ, которые что то пишут в обычный файл. Сейчас появилась необходимость данные передавать специальным образом -- писать в файл 1Кб и делать задержку в 100мс. Есть ли в Linux способ сделать это без изменения кода уже рабочих программ?
Я предположил, что можно создать устройство в linux, в которое можно писать примерно следующее:

cat > /dev/mydev 
или
ofstream of("/dev/mydev");
или
cat ofile > /dev/mydev

.
А уже это устройство на своей стороне будет буферизировать и писать порциями по 1 Кб в нужный файл с необходимой задержкой. Возможно ли это?
Спасибо за внимание:)

Answer 1

[Aves]

Есть buffer
cat file | buffer -s 1k -u 100000 -o outfile

Comments

[pixik]

вау.... слов нет)

[Олег Цилюрик]

pixik: есть то он есть, но в большинстве дистрибутивов он не установлен, и его нужно дополнительно инсталлировать пакетным менеджером.

[pixik]

правда почему то у меня нету buffer (fedora 22)
bash: buffer: command not found...
Где его можно найти?

[pixik]

Олег Цилюрик: как в воду))

[pixik]

правда это решило проблему лишь отчасти... Изначально задача была немного в другом.
Нужно, чтобы программа не заметила, что я что то с файлом сделал. а в случае buffer я никак его применить не могу( Хотя вещь безусловно полезная)

[Олег Цилюрик]

pixik: непонятно совершенно в чём состоит "немного в другом".

[Aves]

pixik: для этого можно создать fifo, направить в него вывод программы, а уже вывод из него направить в buffer

[Aves]

Олег Цилюрик: в арче его и в стандартных репах нет, только в AUR

[Aves]

В любом случае готовое решение лучше шаманства с устройствами.

[pixik]

Олег Цилюрик: Все нужные программы пишут данные в файлы. Все что я могу малой кровью, это указать файл в программе. В худшем случае мне нужно в каждую программу писать один и тот же код.

[Aves]

pixik:

mkfifo pipe
cat file > pipe &
buffer -s 1k -u 100000 < pipe

[pixik]

Aves: Спасибо, красивое решение, но в моем случае оно неприменимо.
Я его себе на заметку взял)

[pixik]

Aves:
Для чего нужен '&' в конце строки?
cat file > pipe &

[Aves]

pixik: '&' нужен для перевода записи в pipe в фоновый режим, чтобы можно было чтение в том же терминале запустить. Без него чтение нужно запускать в другом терминале.
И почему неприменимо?

[pixik]

Aves: для того, чтобы это работало, программы должны выводить данные в stdout, туда уже всякие логи направлены, придётся тогда потом еще и чистить.

[Aves]

pixik: с чего это вдруг? Хотя бы попробовать можно было, прежде чем глупость писать.
fifo это обычный файл.

[pixik]

Aves: Да, не попробовал. Спасибо)
но требования уже изменились))

Answer 2

[Олег Цилюрик]

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

> А уже это устройство на своей стороне будет буферизировать и писать порциями по 1 Кб в нужный файл с необходимой задержкой.
Вообще то, устройство (из ядра) никуда уже далее не пишет.
В принципе, и это можно сделать ... но это уже извращение ... в идеологии Linux.

Comments

[pixik]

Вот простенькая статейка, которая показывает принцип создания устройства.

[Олег Цилюрик]

pixik: ну это слишком ... "простенькая", да ещё и ... старенькая.
Вот здесь можете взять не простенько, но всё что для этого требуется - Драйверы и модули ядра Linux: mylinuxprog.blogspot.com/2015/01/linux.html

Answer 3

[Saboteur]

" Сейчас появилась необходимость данные передавать специальным образом -- писать в файл 1Кб и делать задержку в 100мс. "

Вы уверены что необходимость появилась именно в записи с задержкой в 100 мс?
Может вы опишете зачем нужна такая необходимость, и решение найдется гораздо более адекватное?

Comments

[pixik]

Возможно)
раньше данные писались в файл, сейчас нужно их гнать по полудуплексному модему. Если я буду передавать данные постоянно, то я не смогу их удалённо остановить с другого модема. По этому, я принял решение выдавать данные большим буфером с небольшой задержкой. Во время задержки я могу принимать сигнал, а следовательно и прервать будующую передачу. Точность "до пакета" мне не нужна. Но возможность удаленного управления очень важна.
Модем на 433Мгц. Ни одно распространенное радиоустройство не подошло для проекта по тем или иным причинам, кроме этого модема.

[Saboteur]

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

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

[Saboteur]

pixik: по поводу разрезания файла - готовая служба rotate может это делать для вас, и программа, которая пишет в файл, про это даже не заподозрит.

[pixik]

Сергей: я немного подумаю и отвечу. Спасибо за интересные мысли!

[pixik]

Сергей:
Я подумал, пришёл к выводу, что дешевле всего мне обойдётся в программах немного подписать и отправлять пакеты данных на loopback (в некоторых программах это меняется в конфиге, а в некоторых дописанием нескольких строчек).
Напишу программку - сервер, который будет принимать пакеты с loopback, творить с ними любую магию типа сжатия итп, и оптарвлять нужным способом по COMу. Так же, у сервера в отдельном потоке будет крутиться листенер COMа на предмет команд.
Если есть критика против такого решения, я буду рад!

[Saboteur]

pixik: Основная проблема, что все, что вы пишете, кажется немного костылем на костыле, потому что вы не описали глобальный смысл этого.

У вас связь между двумя точками организована по модему, и нет возможности связать эти две точки, а инфу нужно гнать? Или у вас странное устройство, которое может только получать данные по ком-порту, а эти данные нужно гнать дальше?

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

[pixik]

Сергей: Проблема решилась. Заказчик сообщил мне дургие данные по плотности передаваемого потока. Дело в том, что изначально мне сообщили, что плотность потока по модему будет максимальной, на сколько модем сможет передвать. На что я ответил -- тогда устройство принимать команды по этому модему не сможет, потому что модем постоянно шлёт без пауз, а так как он полудуплексный, то ничего не примет, пока отправляет. Мне сказали, решай сам. Я предложил такое решение, а в итоге оказалось, что поток будет примерно в половину от пропускной способности модема... может и еще меньше. Теперь этой проблемы не существует, так как я после передачи пакета с устройства смогу ожидать приёма команды.

[Saboteur]

pixik: Я когда прочитал ваш самый первый вопрос, сразу предположил, что надо на проблему посмотреть на один уровень абстракции выше, ибо техническое решение это частный случай бизнес-решения :)