Can I share a device from under /dev across hosts?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












7















Here's the situation. I have a video device /dev/video0 on a VMware Server and I want to access this device from within a virtual machine. However for whatever reason I can't connect the device directly to the VM, it must be connected to the host.



Since under unix philosophy everything really is just a file, can I share a device under /dev using NFS, Samba, sshfs or some other protocol between two hosts, so that a linux on one server can access devices on a different server?










share|improve this question

















  • 3





    One of the few cases where my first thought is: "This would be easier if you were using Plan 9"

    – Steven D
    Dec 18 '10 at 20:16











  • @Steven D: That was essentially my first thought as well :-)

    – SamB
    Dec 19 '10 at 6:25















7















Here's the situation. I have a video device /dev/video0 on a VMware Server and I want to access this device from within a virtual machine. However for whatever reason I can't connect the device directly to the VM, it must be connected to the host.



Since under unix philosophy everything really is just a file, can I share a device under /dev using NFS, Samba, sshfs or some other protocol between two hosts, so that a linux on one server can access devices on a different server?










share|improve this question

















  • 3





    One of the few cases where my first thought is: "This would be easier if you were using Plan 9"

    – Steven D
    Dec 18 '10 at 20:16











  • @Steven D: That was essentially my first thought as well :-)

    – SamB
    Dec 19 '10 at 6:25













7












7








7


1






Here's the situation. I have a video device /dev/video0 on a VMware Server and I want to access this device from within a virtual machine. However for whatever reason I can't connect the device directly to the VM, it must be connected to the host.



Since under unix philosophy everything really is just a file, can I share a device under /dev using NFS, Samba, sshfs or some other protocol between two hosts, so that a linux on one server can access devices on a different server?










share|improve this question














Here's the situation. I have a video device /dev/video0 on a VMware Server and I want to access this device from within a virtual machine. However for whatever reason I can't connect the device directly to the VM, it must be connected to the host.



Since under unix philosophy everything really is just a file, can I share a device under /dev using NFS, Samba, sshfs or some other protocol between two hosts, so that a linux on one server can access devices on a different server?







nfs devices






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Dec 18 '10 at 18:00









JoshJosh

3,77664365




3,77664365







  • 3





    One of the few cases where my first thought is: "This would be easier if you were using Plan 9"

    – Steven D
    Dec 18 '10 at 20:16











  • @Steven D: That was essentially my first thought as well :-)

    – SamB
    Dec 19 '10 at 6:25












  • 3





    One of the few cases where my first thought is: "This would be easier if you were using Plan 9"

    – Steven D
    Dec 18 '10 at 20:16











  • @Steven D: That was essentially my first thought as well :-)

    – SamB
    Dec 19 '10 at 6:25







3




3





One of the few cases where my first thought is: "This would be easier if you were using Plan 9"

– Steven D
Dec 18 '10 at 20:16





One of the few cases where my first thought is: "This would be easier if you were using Plan 9"

– Steven D
Dec 18 '10 at 20:16













@Steven D: That was essentially my first thought as well :-)

– SamB
Dec 19 '10 at 6:25





@Steven D: That was essentially my first thought as well :-)

– SamB
Dec 19 '10 at 6:25










3 Answers
3






active

oldest

votes


















9














No.



You can export a device file through NFS or some other network filesystems. But the meaning of the device file is dependent on the machine where you open it. If you export /dev/video0 over NFS from a server machine to a client machine, the client machine just sees “character device 81:0”, and interprets it as its own video capture device. The client machine doesn't even need to have the same device number assignment as the server; for example an OpenBSD client would see the same file as the pseudo-terminal driver, because that's what char 81:0 is under OpenBSD.



What you're asking for would be very nice, but also very hard. Every request on the client would have to be forwarded to the server and vice versa. There would have to be specific support in individual drivers. For example some drivers rely on shared memory between the process and the kernel, and supporting transparently across the network would be hard and prohibitively expensive in many cases. I don't know if the video capture driver does use shared memory, but given that it's likely to transfer large amounts of data asynchronously, I expect it to.



Linux has some specific support for network block devices. They do not rely on a network filesystem; the device file exists only on the client, and a daemon on the server emulates a physical block device (it might relay the operations to and from a real physical device, but often it reads and writes to an image file).



You should look for a solution that's specific to video capture. Try to run as much of the data-intensive part on the machine to which the physical device is attached. Or find a virtual machine solution that supports direct access to the physical device from inside the virtual machine (I don't know if any host/guest solution does; hypervisor-based solutions are more likely to).






share|improve this answer























  • Network block device. Thanks for that tip! Exactly what I was searching for. It's a great way to kinda dd a disk to another machine without using a screwdriver.

    – Christian
    Mar 8 '14 at 14:18







  • 1





    @Christian ssh root@othermachine cat /dev/sdb >/dev/sdc

    – Gilles
    Mar 8 '14 at 14:25






  • 1





    I know it's stupid but somehow I don't trust cat with important binary data. Must be some deeply buried trauma that I don't consciously remember. And no, I'm not a dog person; that's not it.

    – Christian
    Mar 8 '14 at 14:55







  • 2





    @Christian Some older Unix systems had text processing tools that didn't treat binary data correctly, but I doubt that ever applied to cat, and in any case cat will work on all current systems. GNU utilities (the ones on Linux) have always treated binary data correctly, it was a design goal from the start. The use of dd for binary data is a habit inherited from the days of magnetic tapes; on contemporary Linux systems, not only is it a needless complication, it even tends to be slower.

    – Gilles
    Mar 8 '14 at 15:11











  • Ok, maybe I will actively work against my irrational objections then ;)

    – Christian
    Mar 8 '14 at 15:17


















5














In addition to Gilles answer - as long as you do not intend to do ioctls on file it is simply a stream. So if you ran from guest



# mkfifo /dev/fakevideo0
# ssh host cat /dev/video0 > /dev/fakevideo0


/dev/fakevideo0 will behave as a buffor so if you read from it you will get stream from camera.






share|improve this answer























  • Would this procedure work for dual way communications? For instance I would like to do this with a serial port.

    – portforwardpodcast
    Feb 5 '14 at 1:10






  • 1





    @portforwardpodcast I don't think it will work straightforwardly - you would probably need to wrap it in unix pipe so you might need to write a program/script on both sides.

    – Maciej Piechotka
    Feb 5 '14 at 1:24






  • 1





    Thanks for the feedback. I just found this page which works great for dual direction serial over tcp/ip dest-unreach.org/socat/doc/socat-ttyovertcp.txt

    – portforwardpodcast
    Feb 5 '14 at 2:27











  • this won't work well for video, since the default pipe buffer is 4K

    – h4unt3r
    Aug 18 '14 at 22:48


















0














This doesn't answer OP's question but there is this tool called netevent at https://github.com/Blub/netevent which allows you to share ioctl devices located in /dev/input/event* between machines. I've personally tried it myself and it worked for me.






share|improve this answer























  • The OP’s original question about /dev/video is long since irrelevant ;) I have long moved in from that old setup. But netevent looks interesting for other situations...

    – Josh
    Feb 24 at 15:58










Your Answer








StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f4976%2fcan-i-share-a-device-from-under-dev-across-hosts%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























3 Answers
3






active

oldest

votes








3 Answers
3






active

oldest

votes









active

oldest

votes






active

oldest

votes









9














No.



You can export a device file through NFS or some other network filesystems. But the meaning of the device file is dependent on the machine where you open it. If you export /dev/video0 over NFS from a server machine to a client machine, the client machine just sees “character device 81:0”, and interprets it as its own video capture device. The client machine doesn't even need to have the same device number assignment as the server; for example an OpenBSD client would see the same file as the pseudo-terminal driver, because that's what char 81:0 is under OpenBSD.



What you're asking for would be very nice, but also very hard. Every request on the client would have to be forwarded to the server and vice versa. There would have to be specific support in individual drivers. For example some drivers rely on shared memory between the process and the kernel, and supporting transparently across the network would be hard and prohibitively expensive in many cases. I don't know if the video capture driver does use shared memory, but given that it's likely to transfer large amounts of data asynchronously, I expect it to.



Linux has some specific support for network block devices. They do not rely on a network filesystem; the device file exists only on the client, and a daemon on the server emulates a physical block device (it might relay the operations to and from a real physical device, but often it reads and writes to an image file).



You should look for a solution that's specific to video capture. Try to run as much of the data-intensive part on the machine to which the physical device is attached. Or find a virtual machine solution that supports direct access to the physical device from inside the virtual machine (I don't know if any host/guest solution does; hypervisor-based solutions are more likely to).






share|improve this answer























  • Network block device. Thanks for that tip! Exactly what I was searching for. It's a great way to kinda dd a disk to another machine without using a screwdriver.

    – Christian
    Mar 8 '14 at 14:18







  • 1





    @Christian ssh root@othermachine cat /dev/sdb >/dev/sdc

    – Gilles
    Mar 8 '14 at 14:25






  • 1





    I know it's stupid but somehow I don't trust cat with important binary data. Must be some deeply buried trauma that I don't consciously remember. And no, I'm not a dog person; that's not it.

    – Christian
    Mar 8 '14 at 14:55







  • 2





    @Christian Some older Unix systems had text processing tools that didn't treat binary data correctly, but I doubt that ever applied to cat, and in any case cat will work on all current systems. GNU utilities (the ones on Linux) have always treated binary data correctly, it was a design goal from the start. The use of dd for binary data is a habit inherited from the days of magnetic tapes; on contemporary Linux systems, not only is it a needless complication, it even tends to be slower.

    – Gilles
    Mar 8 '14 at 15:11











  • Ok, maybe I will actively work against my irrational objections then ;)

    – Christian
    Mar 8 '14 at 15:17















9














No.



You can export a device file through NFS or some other network filesystems. But the meaning of the device file is dependent on the machine where you open it. If you export /dev/video0 over NFS from a server machine to a client machine, the client machine just sees “character device 81:0”, and interprets it as its own video capture device. The client machine doesn't even need to have the same device number assignment as the server; for example an OpenBSD client would see the same file as the pseudo-terminal driver, because that's what char 81:0 is under OpenBSD.



What you're asking for would be very nice, but also very hard. Every request on the client would have to be forwarded to the server and vice versa. There would have to be specific support in individual drivers. For example some drivers rely on shared memory between the process and the kernel, and supporting transparently across the network would be hard and prohibitively expensive in many cases. I don't know if the video capture driver does use shared memory, but given that it's likely to transfer large amounts of data asynchronously, I expect it to.



Linux has some specific support for network block devices. They do not rely on a network filesystem; the device file exists only on the client, and a daemon on the server emulates a physical block device (it might relay the operations to and from a real physical device, but often it reads and writes to an image file).



You should look for a solution that's specific to video capture. Try to run as much of the data-intensive part on the machine to which the physical device is attached. Or find a virtual machine solution that supports direct access to the physical device from inside the virtual machine (I don't know if any host/guest solution does; hypervisor-based solutions are more likely to).






share|improve this answer























  • Network block device. Thanks for that tip! Exactly what I was searching for. It's a great way to kinda dd a disk to another machine without using a screwdriver.

    – Christian
    Mar 8 '14 at 14:18







  • 1





    @Christian ssh root@othermachine cat /dev/sdb >/dev/sdc

    – Gilles
    Mar 8 '14 at 14:25






  • 1





    I know it's stupid but somehow I don't trust cat with important binary data. Must be some deeply buried trauma that I don't consciously remember. And no, I'm not a dog person; that's not it.

    – Christian
    Mar 8 '14 at 14:55







  • 2





    @Christian Some older Unix systems had text processing tools that didn't treat binary data correctly, but I doubt that ever applied to cat, and in any case cat will work on all current systems. GNU utilities (the ones on Linux) have always treated binary data correctly, it was a design goal from the start. The use of dd for binary data is a habit inherited from the days of magnetic tapes; on contemporary Linux systems, not only is it a needless complication, it even tends to be slower.

    – Gilles
    Mar 8 '14 at 15:11











  • Ok, maybe I will actively work against my irrational objections then ;)

    – Christian
    Mar 8 '14 at 15:17













9












9








9







No.



You can export a device file through NFS or some other network filesystems. But the meaning of the device file is dependent on the machine where you open it. If you export /dev/video0 over NFS from a server machine to a client machine, the client machine just sees “character device 81:0”, and interprets it as its own video capture device. The client machine doesn't even need to have the same device number assignment as the server; for example an OpenBSD client would see the same file as the pseudo-terminal driver, because that's what char 81:0 is under OpenBSD.



What you're asking for would be very nice, but also very hard. Every request on the client would have to be forwarded to the server and vice versa. There would have to be specific support in individual drivers. For example some drivers rely on shared memory between the process and the kernel, and supporting transparently across the network would be hard and prohibitively expensive in many cases. I don't know if the video capture driver does use shared memory, but given that it's likely to transfer large amounts of data asynchronously, I expect it to.



Linux has some specific support for network block devices. They do not rely on a network filesystem; the device file exists only on the client, and a daemon on the server emulates a physical block device (it might relay the operations to and from a real physical device, but often it reads and writes to an image file).



You should look for a solution that's specific to video capture. Try to run as much of the data-intensive part on the machine to which the physical device is attached. Or find a virtual machine solution that supports direct access to the physical device from inside the virtual machine (I don't know if any host/guest solution does; hypervisor-based solutions are more likely to).






share|improve this answer













No.



You can export a device file through NFS or some other network filesystems. But the meaning of the device file is dependent on the machine where you open it. If you export /dev/video0 over NFS from a server machine to a client machine, the client machine just sees “character device 81:0”, and interprets it as its own video capture device. The client machine doesn't even need to have the same device number assignment as the server; for example an OpenBSD client would see the same file as the pseudo-terminal driver, because that's what char 81:0 is under OpenBSD.



What you're asking for would be very nice, but also very hard. Every request on the client would have to be forwarded to the server and vice versa. There would have to be specific support in individual drivers. For example some drivers rely on shared memory between the process and the kernel, and supporting transparently across the network would be hard and prohibitively expensive in many cases. I don't know if the video capture driver does use shared memory, but given that it's likely to transfer large amounts of data asynchronously, I expect it to.



Linux has some specific support for network block devices. They do not rely on a network filesystem; the device file exists only on the client, and a daemon on the server emulates a physical block device (it might relay the operations to and from a real physical device, but often it reads and writes to an image file).



You should look for a solution that's specific to video capture. Try to run as much of the data-intensive part on the machine to which the physical device is attached. Or find a virtual machine solution that supports direct access to the physical device from inside the virtual machine (I don't know if any host/guest solution does; hypervisor-based solutions are more likely to).







share|improve this answer












share|improve this answer



share|improve this answer










answered Dec 18 '10 at 19:53









GillesGilles

543k12811001618




543k12811001618












  • Network block device. Thanks for that tip! Exactly what I was searching for. It's a great way to kinda dd a disk to another machine without using a screwdriver.

    – Christian
    Mar 8 '14 at 14:18







  • 1





    @Christian ssh root@othermachine cat /dev/sdb >/dev/sdc

    – Gilles
    Mar 8 '14 at 14:25






  • 1





    I know it's stupid but somehow I don't trust cat with important binary data. Must be some deeply buried trauma that I don't consciously remember. And no, I'm not a dog person; that's not it.

    – Christian
    Mar 8 '14 at 14:55







  • 2





    @Christian Some older Unix systems had text processing tools that didn't treat binary data correctly, but I doubt that ever applied to cat, and in any case cat will work on all current systems. GNU utilities (the ones on Linux) have always treated binary data correctly, it was a design goal from the start. The use of dd for binary data is a habit inherited from the days of magnetic tapes; on contemporary Linux systems, not only is it a needless complication, it even tends to be slower.

    – Gilles
    Mar 8 '14 at 15:11











  • Ok, maybe I will actively work against my irrational objections then ;)

    – Christian
    Mar 8 '14 at 15:17

















  • Network block device. Thanks for that tip! Exactly what I was searching for. It's a great way to kinda dd a disk to another machine without using a screwdriver.

    – Christian
    Mar 8 '14 at 14:18







  • 1





    @Christian ssh root@othermachine cat /dev/sdb >/dev/sdc

    – Gilles
    Mar 8 '14 at 14:25






  • 1





    I know it's stupid but somehow I don't trust cat with important binary data. Must be some deeply buried trauma that I don't consciously remember. And no, I'm not a dog person; that's not it.

    – Christian
    Mar 8 '14 at 14:55







  • 2





    @Christian Some older Unix systems had text processing tools that didn't treat binary data correctly, but I doubt that ever applied to cat, and in any case cat will work on all current systems. GNU utilities (the ones on Linux) have always treated binary data correctly, it was a design goal from the start. The use of dd for binary data is a habit inherited from the days of magnetic tapes; on contemporary Linux systems, not only is it a needless complication, it even tends to be slower.

    – Gilles
    Mar 8 '14 at 15:11











  • Ok, maybe I will actively work against my irrational objections then ;)

    – Christian
    Mar 8 '14 at 15:17
















Network block device. Thanks for that tip! Exactly what I was searching for. It's a great way to kinda dd a disk to another machine without using a screwdriver.

– Christian
Mar 8 '14 at 14:18






Network block device. Thanks for that tip! Exactly what I was searching for. It's a great way to kinda dd a disk to another machine without using a screwdriver.

– Christian
Mar 8 '14 at 14:18





1




1





@Christian ssh root@othermachine cat /dev/sdb >/dev/sdc

– Gilles
Mar 8 '14 at 14:25





@Christian ssh root@othermachine cat /dev/sdb >/dev/sdc

– Gilles
Mar 8 '14 at 14:25




1




1





I know it's stupid but somehow I don't trust cat with important binary data. Must be some deeply buried trauma that I don't consciously remember. And no, I'm not a dog person; that's not it.

– Christian
Mar 8 '14 at 14:55






I know it's stupid but somehow I don't trust cat with important binary data. Must be some deeply buried trauma that I don't consciously remember. And no, I'm not a dog person; that's not it.

– Christian
Mar 8 '14 at 14:55





2




2





@Christian Some older Unix systems had text processing tools that didn't treat binary data correctly, but I doubt that ever applied to cat, and in any case cat will work on all current systems. GNU utilities (the ones on Linux) have always treated binary data correctly, it was a design goal from the start. The use of dd for binary data is a habit inherited from the days of magnetic tapes; on contemporary Linux systems, not only is it a needless complication, it even tends to be slower.

– Gilles
Mar 8 '14 at 15:11





@Christian Some older Unix systems had text processing tools that didn't treat binary data correctly, but I doubt that ever applied to cat, and in any case cat will work on all current systems. GNU utilities (the ones on Linux) have always treated binary data correctly, it was a design goal from the start. The use of dd for binary data is a habit inherited from the days of magnetic tapes; on contemporary Linux systems, not only is it a needless complication, it even tends to be slower.

– Gilles
Mar 8 '14 at 15:11













Ok, maybe I will actively work against my irrational objections then ;)

– Christian
Mar 8 '14 at 15:17





Ok, maybe I will actively work against my irrational objections then ;)

– Christian
Mar 8 '14 at 15:17













5














In addition to Gilles answer - as long as you do not intend to do ioctls on file it is simply a stream. So if you ran from guest



# mkfifo /dev/fakevideo0
# ssh host cat /dev/video0 > /dev/fakevideo0


/dev/fakevideo0 will behave as a buffor so if you read from it you will get stream from camera.






share|improve this answer























  • Would this procedure work for dual way communications? For instance I would like to do this with a serial port.

    – portforwardpodcast
    Feb 5 '14 at 1:10






  • 1





    @portforwardpodcast I don't think it will work straightforwardly - you would probably need to wrap it in unix pipe so you might need to write a program/script on both sides.

    – Maciej Piechotka
    Feb 5 '14 at 1:24






  • 1





    Thanks for the feedback. I just found this page which works great for dual direction serial over tcp/ip dest-unreach.org/socat/doc/socat-ttyovertcp.txt

    – portforwardpodcast
    Feb 5 '14 at 2:27











  • this won't work well for video, since the default pipe buffer is 4K

    – h4unt3r
    Aug 18 '14 at 22:48















5














In addition to Gilles answer - as long as you do not intend to do ioctls on file it is simply a stream. So if you ran from guest



# mkfifo /dev/fakevideo0
# ssh host cat /dev/video0 > /dev/fakevideo0


/dev/fakevideo0 will behave as a buffor so if you read from it you will get stream from camera.






share|improve this answer























  • Would this procedure work for dual way communications? For instance I would like to do this with a serial port.

    – portforwardpodcast
    Feb 5 '14 at 1:10






  • 1





    @portforwardpodcast I don't think it will work straightforwardly - you would probably need to wrap it in unix pipe so you might need to write a program/script on both sides.

    – Maciej Piechotka
    Feb 5 '14 at 1:24






  • 1





    Thanks for the feedback. I just found this page which works great for dual direction serial over tcp/ip dest-unreach.org/socat/doc/socat-ttyovertcp.txt

    – portforwardpodcast
    Feb 5 '14 at 2:27











  • this won't work well for video, since the default pipe buffer is 4K

    – h4unt3r
    Aug 18 '14 at 22:48













5












5








5







In addition to Gilles answer - as long as you do not intend to do ioctls on file it is simply a stream. So if you ran from guest



# mkfifo /dev/fakevideo0
# ssh host cat /dev/video0 > /dev/fakevideo0


/dev/fakevideo0 will behave as a buffor so if you read from it you will get stream from camera.






share|improve this answer













In addition to Gilles answer - as long as you do not intend to do ioctls on file it is simply a stream. So if you ran from guest



# mkfifo /dev/fakevideo0
# ssh host cat /dev/video0 > /dev/fakevideo0


/dev/fakevideo0 will behave as a buffor so if you read from it you will get stream from camera.







share|improve this answer












share|improve this answer



share|improve this answer










answered Dec 18 '10 at 20:06









Maciej PiechotkaMaciej Piechotka

11.3k84278




11.3k84278












  • Would this procedure work for dual way communications? For instance I would like to do this with a serial port.

    – portforwardpodcast
    Feb 5 '14 at 1:10






  • 1





    @portforwardpodcast I don't think it will work straightforwardly - you would probably need to wrap it in unix pipe so you might need to write a program/script on both sides.

    – Maciej Piechotka
    Feb 5 '14 at 1:24






  • 1





    Thanks for the feedback. I just found this page which works great for dual direction serial over tcp/ip dest-unreach.org/socat/doc/socat-ttyovertcp.txt

    – portforwardpodcast
    Feb 5 '14 at 2:27











  • this won't work well for video, since the default pipe buffer is 4K

    – h4unt3r
    Aug 18 '14 at 22:48

















  • Would this procedure work for dual way communications? For instance I would like to do this with a serial port.

    – portforwardpodcast
    Feb 5 '14 at 1:10






  • 1





    @portforwardpodcast I don't think it will work straightforwardly - you would probably need to wrap it in unix pipe so you might need to write a program/script on both sides.

    – Maciej Piechotka
    Feb 5 '14 at 1:24






  • 1





    Thanks for the feedback. I just found this page which works great for dual direction serial over tcp/ip dest-unreach.org/socat/doc/socat-ttyovertcp.txt

    – portforwardpodcast
    Feb 5 '14 at 2:27











  • this won't work well for video, since the default pipe buffer is 4K

    – h4unt3r
    Aug 18 '14 at 22:48
















Would this procedure work for dual way communications? For instance I would like to do this with a serial port.

– portforwardpodcast
Feb 5 '14 at 1:10





Would this procedure work for dual way communications? For instance I would like to do this with a serial port.

– portforwardpodcast
Feb 5 '14 at 1:10




1




1





@portforwardpodcast I don't think it will work straightforwardly - you would probably need to wrap it in unix pipe so you might need to write a program/script on both sides.

– Maciej Piechotka
Feb 5 '14 at 1:24





@portforwardpodcast I don't think it will work straightforwardly - you would probably need to wrap it in unix pipe so you might need to write a program/script on both sides.

– Maciej Piechotka
Feb 5 '14 at 1:24




1




1





Thanks for the feedback. I just found this page which works great for dual direction serial over tcp/ip dest-unreach.org/socat/doc/socat-ttyovertcp.txt

– portforwardpodcast
Feb 5 '14 at 2:27





Thanks for the feedback. I just found this page which works great for dual direction serial over tcp/ip dest-unreach.org/socat/doc/socat-ttyovertcp.txt

– portforwardpodcast
Feb 5 '14 at 2:27













this won't work well for video, since the default pipe buffer is 4K

– h4unt3r
Aug 18 '14 at 22:48





this won't work well for video, since the default pipe buffer is 4K

– h4unt3r
Aug 18 '14 at 22:48











0














This doesn't answer OP's question but there is this tool called netevent at https://github.com/Blub/netevent which allows you to share ioctl devices located in /dev/input/event* between machines. I've personally tried it myself and it worked for me.






share|improve this answer























  • The OP’s original question about /dev/video is long since irrelevant ;) I have long moved in from that old setup. But netevent looks interesting for other situations...

    – Josh
    Feb 24 at 15:58















0














This doesn't answer OP's question but there is this tool called netevent at https://github.com/Blub/netevent which allows you to share ioctl devices located in /dev/input/event* between machines. I've personally tried it myself and it worked for me.






share|improve this answer























  • The OP’s original question about /dev/video is long since irrelevant ;) I have long moved in from that old setup. But netevent looks interesting for other situations...

    – Josh
    Feb 24 at 15:58













0












0








0







This doesn't answer OP's question but there is this tool called netevent at https://github.com/Blub/netevent which allows you to share ioctl devices located in /dev/input/event* between machines. I've personally tried it myself and it worked for me.






share|improve this answer













This doesn't answer OP's question but there is this tool called netevent at https://github.com/Blub/netevent which allows you to share ioctl devices located in /dev/input/event* between machines. I've personally tried it myself and it worked for me.







share|improve this answer












share|improve this answer



share|improve this answer










answered Feb 24 at 11:44









ritiekritiek

1113




1113












  • The OP’s original question about /dev/video is long since irrelevant ;) I have long moved in from that old setup. But netevent looks interesting for other situations...

    – Josh
    Feb 24 at 15:58

















  • The OP’s original question about /dev/video is long since irrelevant ;) I have long moved in from that old setup. But netevent looks interesting for other situations...

    – Josh
    Feb 24 at 15:58
















The OP’s original question about /dev/video is long since irrelevant ;) I have long moved in from that old setup. But netevent looks interesting for other situations...

– Josh
Feb 24 at 15:58





The OP’s original question about /dev/video is long since irrelevant ;) I have long moved in from that old setup. But netevent looks interesting for other situations...

– Josh
Feb 24 at 15:58

















draft saved

draft discarded
















































Thanks for contributing an answer to Unix & Linux Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f4976%2fcan-i-share-a-device-from-under-dev-across-hosts%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown






Popular posts from this blog

How to check contact read email or not when send email to Individual?

Displaying single band from multi-band raster using QGIS

How many registers does an x86_64 CPU actually have?