Problems while using divecomputer-simulator for linux

[Jef Driesen]

On 2014-03-30 22:14, Linus Torvalds wrote:
> On Sun, Mar 30, 2014 at 12:56 PM, Dirk Hohndel <dirk at 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