On 2014-03-30 22:14, Linus Torvalds wrote:
On Sun, Mar 30, 2014 at 12:56 PM, Dirk Hohndel dirk@hohndel.org wrote:
Should libdivecomputer ignore the error when on a PTY?
Yeah, I don't see any better approach.
In fact, I'd suggest that libdivecomputer get rid of all those checks entirely, and get rid of the whole "ENABLE_PTY" thing. Maybe the errors can be logged to the log-file, but they should be considered at most warnings, not errors.
Some settings just don't make sense for all serial lines. Maybe they are pty's. Maybe there is some glibc idiocy. Maybe they are some emulated other thing that doesn't do a complete job, but works well enough otherwise. Who cares? Making the errors fatal just make things *worse*.
And hiding them under ENABLE_PTY doesn't really help anything, just adds configuration complexity and makes the code uglier.
To be honest, I don't feel comfortable removing the error checking for the syscalls, and not just because omitting error checking is usually the wrong thing to do.
First of all, this only seems to be a problem for pty's and not the real thing. The use of pty's is basically a hack to make the simulator work. For that purpose I'm happy with the --enable-pty option. Only a libdivecomputer developer will ever need it.
For real serial ports, the settings that are used by libdivecomputer should always be supported by the underlying hardware. If some communication protocol requires for example RTS/DTR lines, then it makes no sense to use a piece of hardware that doesn't support that. That can never work, and returning an error is perfectly acceptable if you ask me.
But what worries me a lot more is that trying to communicate with a real device using the wrong settings may actually harm the device. This has already happened in the past with the Mares Icon HD and Matrix. Both use the same protocol, but trying to talk to a Matrix with the Icon HD baudrate will cause the device to lock up completely. Luckily there was no permanent damage and the device could be revived by removing the batteries. But that's pretty scary and something I want to avoid at all cost. This Mares problem is now gone, but that doesn't mean it can't happen for others.
So I'm not convinced ignoring the return value of a syscall, and hoping for the best, is the right solution here. For pty's I'm fine with that, but not for real serial ports.
BTW, the reason why we have the --enable-pty option, and not some autodetection at runtime, is that I couldn't find an easy way to tell the difference between a pty and a real serial port. No doubt it can be done some way (e.g. the major number for pty's?), but I need something that works on other unix like systems too.
Jef