Page 1 of 1
serial port passthrough is too fragile
Posted: 12. Jun 2015, 16:38
by tempest766
I am debugging, in a win7 VM, code that requires comm ports be available (aviation navigation quality GPS software). I'm passing the commports to the linux host as unix domain sockets.
The funcionality of this feature is way too fragile. No matter what I do on the linux host side my client reader can terminate and leave the socket connection dangling...and this regardless of what kind of atexit() or signal() handlers I build into the client. Then the only way to fix the problem is to reboot the VM, which I'm having to do way too frequently.
There needs to be a vboxmanage option to reset the pipes, while the VM is running and no client program attached, instead of having to reboot it so frequently.
I'd also challenge the developers to support SOCK_DGRAM sockets instead of just SOCK_STREAM.
Now for the necessary supplement...NO, I'm not interested in passing the data through socat. That is an intermediate step that complicates my test harness.
What are the chances of actually getting the "pipe reset while VM running" feature added?
Re: serial port passthrough is too fragile
Posted: 12. Jun 2015, 17:13
by noteirak
Devs don't talk about their plans but this is an issue I might qualify as a bug. If you want a faster answer, I would suggest describing your issue on the dev mailing list first, see how the devs react to it.
You can always post a ticket on the bug tracker of course. See
here for links to both.
Re: serial port passthrough is too fragile
Posted: 12. Jun 2015, 21:29
by michaln
tempest766 wrote:There needs to be a vboxmanage option to reset the pipes, while the VM is running and no client program attached, instead of having to reboot it so frequently.
You could always contribute it yourself. That tends to be the best option for things that you consider important and pretty much no one else does.
Of course the reality is that debugging Windows VMs on a Windows host is about 10 times more productive, even if everything on your wishlist was implemented... but that's a separate issue.
Re: serial port passthrough is too fragile
Posted: 14. Jun 2015, 03:41
by tempest766
You could always contribute it yourself. That tends to be the best option for things that you consider important and pretty much no one else does.
<sarcasm on>Yeah, I'll get right on that.<sarcasm off>
Of course the reality is that debugging Windows VMs on a Windows host is about 10 times more productive, even if everything on your wishlist was implemented... but that's a separate issue
So sad for you...You drank the cool-aid!!!
Re: serial port passthrough is too fragile
Posted: 14. Jun 2015, 03:53
by tempest766
noteirak wrote:Devs don't talk about their plans but this is an issue I might qualify as a bug. If you want a faster answer, I would suggest describing your issue on the dev mailing list first, see how the devs react to it.
You can always post a ticket on the bug tracker of course. See
here for links to both.
Tried sending an email inquiry to their list and was rejected because I didn't subscribe to the list. I simply will not subscribe to every list or forum for the 2400+ packages that exist where I might find a bug or pose a question. They could at least receive and individually approve messages from non-subscribers instead of requiring subscription to even present a question.
Re: serial port passthrough is too fragile
Posted: 14. Jun 2015, 09:38
by mpack
This thread seems to be pointless, and pointlessly antagonistic. If you want help in future I suggest that you try a more diplomatic approach, and do remember that your worth to us is measured in how much you paid for the software (impresses the devs), plus the number of helpful posts on these forums (impresses us users). Someone who scores zero on both counts needs to at least be polite.
Re: serial port passthrough is too fragile
Posted: 14. Jun 2015, 14:12
by michaln
tempest766 wrote:So sad for you...You drank the cool-aid!!!
Perhaps you mean "Kool-Aid"?
At any rate, I prefer to not waste time more than necessary, which this thread unfortunately turned out to be. I agree with mpack, and I'll rephrase what he said a bit: If you want something for nothing, you should choose your words carefully.