This is only going to confuse things, but you asked for it...

> The system of pending opens where getty's open() can continue to block while
> tip's open() succeeds suits me just fine.  Can we rewind this conversation to
> that point and have somebody explain just why that's a bad thing?

It wouldn't necessarily be a bad thing.  I assume what you're
referring to is the alternative interpretation of ISOPEN/WOPEN that I
elected not to mention before -- namely:

* getty opens a port in blocking mode, causing WOPEN to be set.

* tip/cu/whatever opens the port in non-blocking mode, causing ISOPEN
  to be set.

* When carrier is raised, since ISOPEN is set, processes waiting for
  carrier in the open routine are *not* woken up -- the assumption
  being that something else is already using the port.

* Only when tip/cu/whatever closes the port (clearing ISOPEN) will
  getty again be able to notice that carrier is high and finish
  opening the port.

The problem with this is that it's highly dependent on timing.  If
getty starts to open the port while tip is running and has
successfully connected, it succeeds.  This is bad.

Effectively what you're doing here is using the presence or absence of
O_NONBLOCK to distinguish between dialin and dialout use (as opposed
to a bit in the minor number, in SunOS and some other systems).  The
two methods are more or less isomorphic, except that the actual
implementation of the O_NONBLOCK method in 4.4 was completely broken
and didn't actually work.