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.... Message-ID: <19970603000950.CW64363@uriah.heep.sax.de> In-Reply-To: <199706022051.QAA00272@bmcgover-pc.cisco.com>; from Brian McGovern on Jun 2, 1997 16:51:26 -0400 References: <199706022051.QAA00272@bmcgover-pc.cisco.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970603000950.CW64363>