Date: Mon, 24 Jul 95 21:08:01 MDT From: terry@cs.weber.edu (Terry Lambert) To: bde@zeta.org.au (Bruce Evans) Cc: bde@zeta.org.au, ache@astral.msk.su, hackers@freebsd.org, harry@hgac.com, jkh@violet.berkeley.edu Subject: Re: dial up at > 9600 baud Message-ID: <9507250308.AA12964@cs.weber.edu> In-Reply-To: <199507241904.FAA28245@godzilla.zeta.org.au> from "Bruce Evans" at Jul 25, 95 05:04:34 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >> >It's also broken because the wait for DCD on the blocking open is > >> >only in effect when the open count is 0. After one open as a > >> >non-blocking open, the reference count is one, and subsequent opens > >> >are not *supposed* to block. > >> > >> I disagree. POSIX requires it to block. Not blocking would cause > >> stupid behaviour such as `stty -f /dev/ttyd0' unblocking any getty > >> sleeping in open for /dev/ttyd0. Once the open has completed it is > >> hard to recover. > > >No, it wouldn't do this. > > >That's because the open in process is already past the flag check > >and is sleeping on the address tickled by the driver's DCD off-to-on > >processing. > > New blocking opens have to sleep on that address too. I thought you > meant to wake everything up. Why do the wrong thing for new opens but > not for old opens? It causes more obscure states that depend on > ancient history. The same sleep address is used for DCD transitions > and all input events in 2.x. Processes sleeping on it get woken up > unnecessarily and have to go back to sleep if DCD and CLOCAL are > still clear. Once the non-blocking-open flag has been set on the tty, it is not reset until the final close. The flag for this is on the tty or the calling unit, not in the driver. Otherwise you'd have to dup massive amounts of code to support a new serial card into the card-specific driver. This would be bad. The sleep addresses must be different for the tty and the calling unit because of this. Since comms outgoing and getty incoming use the calling unit and the tty respectively, the sleeping open by the getty is not woken up by the DCD going high nor by a retrofitted signal as a result of the flag bit in the calling unit having been changed. > >> 1.1.5 fiddles with the open count to make blocking work. There > >> can be any number of processes sleeping in open() and any number > >> of processes with it open (having opened it in nonblocking mode). > > >This i the wrong thing to do. Probably it was done because the > >calling unit and non-calling unit devices were not being treated > >as logically seperate entities for that code. > > I did it in vfs because it can't be done in the driver. The calling > and non-calling unit were and remain as logically separate as possible. > They have to block each other. I agree that they have to block each other, but this is done seperately at the vfs level. The signals processing is at the bottom end of the VFS level, but it should still be at the VFS level. The VFS level needs to treat signal change notificcations from the serial driver as events, an the processing of those events will cause a wakeup to be sent, but the wakeup will be only to the one or the other of the calling unit or the tty. Otherwise, your getty open will complete on the tty when the DCD goes high on the outbound call. If you are using the blocking to arbitrate whether the signal is acted upon rather than whether the signal is sent, then the sleep addresses have been confused. In effect, state changes are in fact soft interrupts with two potential but only one active delivery vector. With this in mind, I think that modem control, if not arbitrated by a minor number bit, should also be in the /etc/rc.serial with the RTS/CTS controls. Can't kill that damn thing. 8-(. But at least we can relegate it to controlling things that on a Sun machine would require a kernel rebuild with a new flags variable. If you're in there, the RI signal would be a nice option for the open complete instead of the DCD so we can write our own mgetty and get it right (no lock file cruft for incoming connections, PERIOD). 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?9507250308.AA12964>