Date: Tue, 25 Jul 95 14:33:06 MDT From: terry@cs.weber.edu (Terry Lambert) To: bde@zeta.org.au (Bruce Evans) Cc: ache@astral.msk.su, bde@zeta.org.au, hackers@freebsd.org, harry@hgac.com, jkh@violet.berkeley.edu Subject: Re: dial up at > 9600 baud Message-ID: <9507252033.AA16998@cs.weber.edu> In-Reply-To: <199507251406.AAA32521@godzilla.zeta.org.au> from "Bruce Evans" at Jul 26, 95 00:06:04 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >> >No. "... opening a terminal device file with the O_NONBLOCK flag clear > >> >shall cause the process to block until the terminal device is ready and > >> >available. The CLOCAL flag can also affect open()." [Opening terminal > >> >device files with O_NONBLOCK set is supposed to always work if the file > >> >permissions allow it. We probably break this by returning EBUSY for > >> >some exclusive access and bidirectional cases.] > > >A non-blocking open of the regular device when the calling unit > >device is in use is to return EWOULDBLOCK. > > Not allowed by POSIX (apart from EWOULDBLOCK not existing in POSIX), but > better than EBUSY. Well, techincally, calling units are not allowed by POSIX. They want you to use the partial open hack. 8-). > >A blocking open is to block until the calling unit is not busy > > Except blocking opens of the calling unit should block unit the non-calling > unit is not busy. Yes, of course. Sorry, that was supposed to be implied in "interlock". It's an issue of how device multiplexing into a tty and a calling unit occur. But you knew that already. 8-). > We currently return EBUSY. Yah. This is broken. The correct mechanism is to alarm out of the open in the comms software if the outgoing call is supposed to be partially or fully interactive. This is actually a requirement for a source change to the comms software -- not something that should be entered into lightly. Or, better, to handle the EWOULDBLOCK after attempting a blocking open. This used to be necessary because the open used to be with O_NDELAY which caused the same effect as a vmin of 0 and a vtime of 0 on pre TERMIOS tty devices. Now that we have fcntl() to unset the "no delay" for reads, we're fine. The vmin/vtime method is the correct way to handle block protocols anyway. The one remaining issue is that the partial open unsetting of NDELAY needs to still work for device binary compatability for things like IBCS2. > >It seems the interpretation of POSIX above is being used incorrectly. > >The flag in question is on the tty struct, *not* on the open. The > >O_NONBLOCK flag on the open is in a different section of the standard. > > No. No. Yesbut. :-) The flag is on the open and lives in the file > struct, *not* in the tty struct. The 2 sections of the standard say > much the same thing. The section on open() says that for cdevs that > "support nonblocking opens": (1) O_NONBLOCK shall cause permissible > opens to succeed immediately. (2) !O_NONBLOCK shall cause permissible > opens to block. The section on opening "Terminal Devices Files" says > (2). Apparently "Terminal Device Files" "support nonblocking opens" > (although I don't know where if anywhere that is specified explicitly) > so (1) should apply too. Yeah, they didn't want to standardize anyone out of existing practice, especially the SVR4 geeks, so the made it rather ambiguous. It's possbile to be less ambiguous, but only by dictating implementation (something else they wanted to avoid). The "right thing" is to "make it work" and "don't break existing software as much as possible". Oh, and keep your head down, or you'll catch shrapnel. Maybe what we need to do is document existing practice and then document a specific implementation model. And then make anyone else who writes serial drivers stick to it. Lotta work, that. 8-(. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9507252033.AA16998>