On Wed, 6 Nov 1996, der Mouse wrote:

> One idea is about dialin/dialout tty lines.  I think it would probably
> be possible to do proper dialin/dialout devices entirely in MI code,
> that is, in the generic tty code instead of in the port-specific
> drivers.

Sounds interesting and useful.

> What I imagine here is three devices per tty line: a dialin device, a
> dialout device, and a generic device.  You can either use the first two
> or the third one; attempts to use the generic device and one of the
> other two should probably fail.  (It might also be possible for the
> generic device to be the same one as the dialin device, but with CLOCAL
> cleared.) The generic device works the way ttys presently do.  The
> dialout device does not wait for carrier, and fails on open if anyone
> has the dialin device open; a process blocked waiting for carrier will
> not cause a dialout open to fail.  However, while the dialout device is
> open, any attempt to open the dialin device will block as if carrier
> were not present.  Indeed, a process that accesses just the dialin
> device cannot tell the difference between real lack of carrier and
> someone having the dialout device open.  This is how my NeXT does
> dialin/dialout, and it is quite pleasant to use.

Sounds good. I think the generic device should be worked into the scheme
somehow (the generic+one of the others == fail bit you mentioned).

How much code change to each driver would this feature require? Have you
gotten as far as sample code yet?

> Or, if you don't trust the kernel and would rather see userland locks,
> you use the generic device and ignore the other two.

A good compromise. :-)

> The second idea is to have only ptys be tty devices in the current
> sense (stty settings and all), with the hardware device drivers being
> optimized for high throughput to user-land and no tty goop.
> Interactive logins are then handled with a user-land daemon that
> interfaces between a hardware line device and a pty master half.

I'm not sure I see why we need to do this change. Wouldn't this change
mean a lot more data crossing the kernel/userland barrier? Multiple times?
I think a better way to get serial port performance up (that is the goal?)
would be to get moving on allowing the tty layer to receive multiple bytes
from the hardware drivers. It was on Charles's to-do list a while back,
and sounds good.

Take care,

Bill