I like the three device idea, though I don't really see the need for the
generic device, considering that the dial-out device should always have
carrier up upon open to allow for out bound dialing.
	As some of you may remember, I implemented a SunOS style dual-device
scheme for the I386 on NetBSD 1.0.  One of the reasons it never made it
into the tree, I believe, was that it diddled with bits in the machine
dependent driver, and getting it to work on all ports was a non-trivial
exercise.  So, lately, I've been considering whether or not I could get a
similar scheme to work by adding bits to the tty structures, and some code
in kern_tty.c to do the interlocking/checking for simultaneous use.  In
theory, this code would be machine independent, and would only require a
one or two line change to the machine dependent drivers.
Any thoughts or comments?
-Brian

On Nov 7, 12:58pm, Bill Studenmund wrote:
} Subject: Re: serial line ideas
} 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
} 
>-- End of excerpt from Bill Studenmund