Я могу совместно использовать устройство из-под/dev через хосты?
Как насчет чего-то вроде этого:
src=/mnt/driveA
dst=/mnt/driveB
cd $src
find . -name <PATTERN> -type f >/tmp/srclist
cd $dst
find . -name <PATTERN> -type f >/tmp/dstlist
cat /tmp/srclist | while read srcpath; do
name=`basename "$srcpath"`
srcdir=`dirname "$srcpath"`
dstpath=`grep "/${name}\$" /tmp/dstlist`
mkdir -p "$srcdir"
cd "$srcdir" && ln -s "$dstpath" "$name"
done
Это предполагает, что названия файлов, которые Вы хотите синхронизировать, уникальны через целый диск: иначе нет никакого способа, которым это может быть полностью автоматизировано (однако, можно предоставить подсказку пользователю для выбора который файл выбрать, если существует больше что один.)
Сценарий выше будет работать в простых случаях, но может перестать работать если name оказывается, содержит символы, которые имеют особое значение для regexps. grep в списке файлов может также занять много времени, если существует партия файлов. Можно полагать, что перевод этого кода использует хеш-таблицу, которая отобразит имена файлов на пути, например, в Ruby.
Нет.
Можно экспортировать файл устройств через NFS или некоторые другие сетевые файловые системы. Но значение файла устройств зависит от машины, где Вы открываете его. Если Вы экспортируете /dev/video0 по NFS с машины сервера на клиентскую машину клиентская машина просто видит “устройство посимвольного ввода-вывода 81:0” и интерпретирует его как его собственное устройство видеосъемки. Клиентская машина не должна даже иметь того же присвоения номера устройства как сервер; например, клиент OpenBSD рассматривал бы тот же файл как драйвер псевдотерминала, потому что это - то, какой символ 81:0 находится под OpenBSD.
То, что Вы просите, было бы очень хорошо, но также и очень трудно. Каждый запрос на клиенте должен был бы быть передан к серверу и наоборот. В отдельных драйверах должна была бы быть определенная поддержка. Например, некоторые драйверы полагаются на общую память между процессом, и ядро, и поддерживающий прозрачно по сети было бы твердым и непомерно дорогим во многих случаях. Я не знаю, использует ли драйвер видеосъемки действительно общую память, но, учитывая, что это, вероятно, переведет большие объемы данных асинхронно, я ожидаю это к.
Linux имеет некоторую определенную поддержку сетевых блочных устройств. Они не полагаются на сетевую файловую систему; файл устройств существует только на клиенте, и демон на сервере эмулирует физическое блочное устройство (это могло бы передать операции к и от реального физического устройства, но часто это читает и пишет в файл изображения).
Необходимо искать решение, это характерно для видеосъемки. Попытайтесь выполнить такое количество информационно емкой части на машине, к которой присоединяется физическое устройство. Или найдите решение для виртуальной машины, которое поддерживает прямой доступ к физическому устройству из виртуальной машины (я не знаю, делает ли какое-либо решение для хоста/гостя; основанные на гипервизоре решения более вероятны).
В дополнение к ответу Gilles - пока Вы не намереваетесь сделать ioctls на файле, это - просто поток. Таким образом, если Вы работали от гостя
# mkfifo /dev/fakevideo0
# ssh host cat /dev/video0 > /dev/fakevideo0
/dev/fakevideo0 будет вести себя как буфер поэтому, если Вы будете читать из него, то Вы получите поток от камеры.
-
1Эта процедура работала бы на двойной путь связь? Например, я хотел бы сделать это с последовательным портом. – portforwardpodcast 05.02.2014, 03:10
-
2@portforwardpodcast, я не думаю, что он будет работать прямо - необходимо было бы, вероятно, перенестись, он в Unix передает по каналу, таким образом, Вы, возможно, должны были бы записать программу/сценарий с обеих сторон. – Maciej Piechotka 05.02.2014, 03:24
-
3Спасибо за обратную связь. Я просто нашел эту страницу, которая работает отлично для двойного направления, последовательного по tcp/ip dest-unreach.org/socat/doc/socat-ttyovertcp.txt – portforwardpodcast 05.02.2014, 04:27
-
4это не будет работать хорошо на видео, так как буфер канала по умолчанию является 4K – h4unt3r 19.08.2014, 01:48
Это не отвечает на вопрос OP, но есть этот инструмент, называемый netevent в https://github.com/Blub/netevent, который позволяет вам совместно использовать устройства ioctl, расположенные в /dev/input/event*, между машинами. Я лично пробовал это сам, и это сработало для меня.
ddдиск к другой машине, не используя отвертку. – Christian 08.03.2014, 16:18ssh root@othermachine cat /dev/sdb >/dev/sdc– Gilles 'SO- stop being evil' 08.03.2014, 16:25catс важными двоичными данными. Должна быть некоторая глубоко проложенная под землей травма, которую я сознательно не помню. И не, я не любитель собак; это не это. – Christian 08.03.2014, 16:55cat, и в любом случаеcatбудет работать над всеми существующими системами. Утилиты GNU (те на Linux) всегда рассматривали двоичные данные правильно, это была цель дизайна от запуска. Использованиеddпоскольку двоичные данные являются привычкой, наследованной со дней магнитных лент; в современных системах Linux, мало того, что это - бесполезная сложность, это даже имеет тенденцию быть медленнее. – Gilles 'SO- stop being evil' 08.03.2014, 17:11