ISA com driver no longer groks B0 as hangup

[ghost]

Metadata

• Number: 4123
• Originator: John Kohl <jtk@kolvir.arlington.ma.us>
• Arrived: Thu Sep 18 22:35:01 +0000 1997
• Last modified: Thu Feb 11 12:40:38 +0000 1999
• Environment: System: NetBSD kolvir.arlington.ma.us 1.2G NetBSD 1.2G (KOLVIR) Exabyte 8505 read/write of compressed high density tapes #22: Fri Sep 19 01:09:15 EDT 1997 jtk@kolvir.arlington.ma.us:/u4/sandbox/src/sys/arch/i386/compile/KOLVIR i386

Description

    The latest changes to the com driver to handle multiple
frequency multipliers seems to have broken the POSIX requirement that a
baud rate of B0 mean "hang up".  comparam() rejects a termios with a
speed of B0.

How to repeat

#include <termios.h>

main()
{
    struct termios t;

    tcgetattr(0, &t);
    cfsetispeed(&t, 0);
    cfsetospeed(&t, B0);
    if (tcsetattr(0, TCSANOW, &t) == -1)
    perror("tcsetattr");
}

Fix

    There's an #if 0 in comrate() which when converted to #if 1
seems to do the trick.  I'm not sure if that's quite right, though ...

Audit trail

Responsible-Changed-From-To: kern-bug-people->kleink 
Responsible-Changed-By: jtk 
Responsible-Changed-When: Thu Feb 11 04:40:07 PST 1999 
Responsible-Changed-Why:  
assigning to Klaus for standards comments 

From: "Charles M. Hannum" <root@ihack.net>
To: jtk@kolvir.arlington.ma.us
Cc: kleink@netbsd.org, gnats-bugs@gnats.netbsd.org
Subject: Re: kern/4123
Date: Wed, 28 Apr 1999 19:11:26 -0400 (EDT)

 I thought I had already appended this to the PR.

 One might assume that since I specifically turned that code off, that
 just turning it back on is not the right thing to do.

 As it turns out, there are multiple problems with it:

 * Turning on DTR on a baud rate change is clearly wrong; the `else'
   clause *must* be omitted.

 * The interaction between B0 and TIOCSDTR/TIOCCDTR is not well
   defined.

 * It's not clear whether `hang up' in the POSIX text means to cycle
   DTR, or to just leave it turned off.

 * What happens to the rest of the settings?  It's obviously not
   correct to *just* set the baud rate registers to some random value.
   Does hanging up mean that we should stop receiving data?  Stop
   sending?  Both?  The code doesn't deal with this.

 I asked Klaus to define the semantics for me more precisely so that I
 could implement it, but I don't think this ever happened.