serial port virtualization

Под готовыми решениями понимается url, или то, что можно получить через apt, или то, чему можно сказать wget/make

А может вам еще и ключ от квартиры где деньги лежат?

Головой хоть подумайте - имеющие контекст устройства (а устройство за ком-портом именно оно и есть) не превращаются в совместно используемые без плясок с бубном. А уж когда устройство открыто и заблокировано - тем более.

Именно ей я и думал, прежде чем написать в лор - больше доверяю :)

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

Я даже более того скажу - это было в мобильном оффтопике для шаринга GPS, а под линуксом вдруг невозможно? Пичалька :)))

Как я вижу, то в линуксе даже эту операцию упростили разделением. Хотя на самом деле ни у кого пока не возникало потребности в чем-то отличном от:
Сначала заснифать порт, для этого сдублировать, видимо, нужно вывод с помощью tee в какие-то файлы по количеству нужных портов.
Дальше socat'ом файлы превратить в виртуальные порты.

а, вот, лучше снифать slsnif, там должно и бинарный сирф нормально писать.

>прочие программы параллельно

Т.е. получатель сам разберётся, что ему байты вперемешку от разных отправителей приходят? Или какая параллельность имеется ввиду?

в мобильном оффтопике для шаринга GPS

а в линуксе gps daemon открывает последовательный порт для связи с GPS и TCP сокет для подключения клиентов. Т.е. есть посредник, который [не гарантирую, но] отвечает за сортировку команд к GPSу (если они там вообще есть, хотя частота посылки данных типа 1 раз/с, 5 раз/с должна настриваться если не ошибаюсь). Ну а ответ от GPS (псевдо)параллельно отправляется потом всем клиентам.

Спасибо, примерно это и вертелось в голове. Про socat уже начал читать, но не дочитал.

> Т.е. получатель сам разберётся, что ему байты вперемешку от разных отправителей приходят? Или какая параллельность имеется ввиду?

Был один реальный ком порт -> стало несколько виртуальных. Каждый клиент получает по виртуальному ком порту в ридонли моде. Таким образом, клиенты параллельно работают с одними и теми же данными.

gpsd здесь не очень подходит.

> Про socat уже начал читать, но не дочитал

Дочитали? Думаю, нужно открыть несколько (по кол-ву клиентов) пар виртуальных последовательных портов (чтение/запись). Потом постоянно читать из реального порта и по поступлению данных в цикле проходить по всем портам (на запись), и посылать туда полученные данные.

Вроде да.

socat /dev/ttyS0,raw,echo=0,crnl /dev/ttyS1,raw,echo=0,crnl

или

socat -d -d pty,raw,echo=0 «exec:myprog ...,pty,raw,echo=0»

Если сам ваяю что-то, выкидывающее данные в стдаут.