Adam Thompson <[email protected]> wrote: > On 2019-08-03 18:14, Theo de Raadt wrote: > > Adam Thompson <[email protected]> wrote: > > > >> Summary: I open cua0 with cu(1), quit cu(1), try to re-open with > >> cu(1) but now it immediately fails with EBUSY. *Usually* doesn't > >> happen with USB-to-serial (cuaU[0-9]) but have still seen it once or > >> twice. > [...] > > You are observing the forcing-down of DTR and RTS for a long enough > > period that the other side of the link notices the event. > > > > Therefore it is not suprising you are finding this behaviour very > > similar in many drivers and operating systems. > > Thanks! > I feel as though I'm seeing something that's slightly off (see below), > but I was focused on the open() end of things not the close() end - I > now need to do more reading. > > > FWIW, things that don't *feel* right about this: > * "long enough" doesn't typically describe multiple days, in DTE/DCE > signalling. Far-end device is the same when testing using cua00 > vs. cuaU0. > * isn't cua(4) supposed to be the device we use to ignore line > signals? Why would closing it fiddle with line status? Maybe I'm > reading too much into hupcl in stty(1) manpage... > * and now I'm wondering if cu(1) fiddles with [-]clocal and/or [-]hupcl > > As I said, more reading now you've given me a direction and I'll > probably come back with at least one or two of my own answers.
There are a few obvious races being avoided. If the cua node is closed, you don't want a getty to start immediately on a line with unknown condition. You want the signalling to settle, and you don't want a double open of cua and tty. You want the new process to not encounter a "strange line condition". I believe that is why this settling behaviour has been in the tty subsystem for nearly two decades, if not longer. Previous to that, our cua behaviour is a clone of the the behaviour in SunOS. That was a bit fishy right from the getgo, but we desperately needed such a thing without resorting to special flags to open(). I believe this is about giving the future open of a cua or tty a known condition, rather than the line condition during the close of the previous. A simplistic alternative would be to add the 2-second delay to open, but now that I've said that you'll know that's the wrong approach, and therefore this code is found in close. Anyways, look this is 20+ year old behaviour. If you ask questions and propose change to this, the onus is entirely on you to prove that the current situation is wrong and you have a better idea. This should not be done in english words, but with a diff which is then tested in a vast number of circumstances and only then can the impact be discussed.
