Problems while using divecomputer-simulator for linux

[Dirk Hohndel]

On Mon, 2014-03-31 at 10:36 +0200, Jef Driesen wrote:
> 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.

But instead of making the error fatal, how about you just log it and try
to keep going, anyway?

Think of it this way: "what's the worst that could happen?"
a) the error is real, communication will fail (same result as today)
b) the error is bogus, communication will succeed (winning!)

> 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.

That assumes there are no issues with the libraries used or the kernel
used and the specific serial device.

> 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.

Printing an error is, I agree. Forcefully aborting? I think we'll have
to agree to disagree here.

> 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.

But that wasn't a problem of RTS/DTR or other serial parameters. That
was a USB communication issue. And IIRC this wouldn't have been caught
by an error return, either.

> 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.

It's your library... I think it makes much more sense to try to keep
going and fail if the responses of actual communication make no sense,
not if something odd happens during the setup of the communication.

> 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.

I'm not aware of an easy way to do that, either. Linus?

/D