From owner-freebsd-hackers Mon Jun 2 15:22:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA16564 for hackers-outgoing; Mon, 2 Jun 1997 15:22:36 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id PAA16556 for ; Mon, 2 Jun 1997 15:22:32 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA04590; Tue, 3 Jun 1997 00:22:23 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id AAA13002; Tue, 3 Jun 1997 00:09:50 +0200 (MET DST) Message-ID: <19970603000950.CW64363@uriah.heep.sax.de> Date: Tue, 3 Jun 1997 00:09:50 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Cc: mcgovern@spoon.beta.com Subject: Re: Need help with O_NONBLOCK and pppd in FreeBSD.... References: <199706022051.QAA00272@bmcgover-pc.cisco.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199706022051.QAA00272@bmcgover-pc.cisco.com>; from Brian McGovern on Jun 2, 1997 16:51:26 -0400 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Brian McGovern wrote: > However, then we look at line 396, which reads: > if (fcntl(fd, F_SETFL, initfdflags | O_NONBLOCK) == -1) { > syslog(LOG_ERR, "Couldn't set device to non-blocking mode: %m"); > die(1); > } > > Which seems to tell me to set O_NONBLOCK, reguardless of whether we want to > use modem control lines or not. Once in a non-blocking state, pppd is free > to spin completely out of control. There's no reason why it should spin out of control. Non-blocking mode doesn't mean to not obey the modem control signals (that's things like stty crtscts what you mean), it only means the next attempted IO operation should not block if the device is unavailable (e.g. no carrier). Since all potential IO is triggered by a previous select() call, the device should ideally always be ready. If not, the read() call is supposed to just return immediately with 0. The initial `nonblock' seems only to be there to cause the open() to immediately return, regardless of the carrier state. This is normally not necessary for BSD with the split callin/callout devices, but shouldn't harm either. Note that pppd manages things like CLOCAL apparently in set_up_tty(), before handing out control to the dial utility. You seem to confuse this with the O_NONBLOCK behaviour. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)