Back out the attempt to use VTIME.

According to Matthias Drochner at
http://lists.lysator.liu.se/pipermail/lsh-bugs/2003q4/000151.html:

   I thought I'd give lsh a try, just to see how it compares to openssh...
   The client didn't work well on NetBSD, got a message like "unexpected
   EWOULDBLOCK" on each keystroke.
   Looked a bit deeper and found that stdin is set to O_NONBLOCK and
   a raw tty mode with c_cc[VMIN] > 1 and c_cc[VTIME] > 0.
   I'll append a little test program which does the same. I've tried
   it on 3 operating systems (Linux, NetBSD, Digital UNIX), and it
   behaves differently on each:

   -on Linux, if a key is pressed, the read returns immediately with
    that one character
   -on NetBSD, the read returns with no data but EWOULDBLOCK
   -on D'UNIX, the poll() doesn't teturn before 4 keypresses are done;
    the read() returns these 4 characters

   Indeed, in SUSv2's termios page is a sentence which says that if
   both O_NONBLOCK and VTIME>0 are set, the behaviour is more or less
   undefined.

   I've solved my immediate problems by setting VMIN to 1 instead of 4
   in unix_interact.c:do_make_raw(), but VTIME is still pointless,
   so I wouldn't call this a clean solution.

All regression tests pass.

1 files changed, 0 insertions, 1 deletions

diff --git a/driver_nmea2000.c b/driver_nmea2000.c
index 4059dbee..d74233b4 100644
--- a/driver_nmea2000.c
+++ b/driver_nmea2000.c
@@ -1700,7 +1700,6 @@ const struct gps_type_t driver_nmea2000 = {
 #ifdef TIMEHINT_ENABLE
     .time_offset     = NULL,
 #endif /* TIMEHINT_ENABLE */
-    .minlength       = 0,		/* min packet length unknown */
 };
 /* *INDENT-ON* */