Date: Tue, 25 Jul 1995 05:04:34 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, terry@cs.weber.edu Cc: ache@astral.msk.su, hackers@freebsd.org, harry@hgac.com, jkh@violet.berkeley.edu Subject: Re: dial up at > 9600 baud Message-ID: <199507241904.FAA28245@godzilla.zeta.org.au>
next 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. >> 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. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199507241904.FAA28245>