> 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.

I like this setup just fine, with some caveats.

> 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.

This part I don't get.  Why would it succeed if another process has the
port open?

> 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.

I've always preferred to have O_NONBLOCK just be a way to force an
EWOULDBLOCK errno rather than a way to bypass carrier checking, but
I don't know how to get a tty device open (so I can set its CLOCAL)
if its carrier isn't up unless we use O_NONBLOCK on tty devices to
mean "ignore carrier when opening, but return EIO on read and write
unless either carrier is on or CLOCAL is on".  Maybe a new open flag
like O_IGNCARR?