[ On Wed, December 21, 1994 at 00:06:54 (-0500), Niklas Hallqvist wrote: ]
> Subject: Re: Formal getty replacement yet?
>
> The idea is that a program waiting for dialin should open the device
> in blocking mode and a dialout program in non-blocking.  Now the
> device could allow both uses simultaneously by only allowing blocking
> opens to succeed when there is a carrier present *and* no non-blocking
> opens of the device has been honoured.  The non-blocking opens should
> only fail when a blocking open of the device has succeeded.  The idea
> is to save the blockingness of the open as an indication of whether
> the dialin or dialout functionality is wanted, instead of a bit in the
> minor device number.

Oh, right, that model!  I keep forgetting about it.  Just about as
complicated (and maybe more so, since I've seen more problems with
drivers implemented this way).

> My only reaction to this scheme is that stty's of lines opened with an
> outdialing program will fail, but the defenders of this model says
> that it's bad practice to let independent parties change port settings
> behind a communication program's back.  Possibly they are right, but
> nonetheless that's what's not backward compatible.

*Some* SysVr4's that I've worked with had drivers that permitted
multiple non-blocking opens after DCD came up, but held the original
non-blocking open(s) in stasis until DCD cycles again.  Yet more
complicated state information to maintain....

However, on good old AT&T SysVr3 it works similarly, except there's no
blocking status kept in the kernel.  It's up to the processes doing
non-blocking opens on the port to determine if they are the one that own
the port after the open returns successfully (i.e. by checking for a
lock file), otherwise all I/O, including ioctl()'s are fair game.

I still like this simpler model, since everything that I need to control
from user-land is already in user-land, and there's no messy state
machine in the kernel that can get stuck in the wrong state at the wrong
time.

K.I.S.S. and give me all the options in user-land (and all the rope).

We can quickly and easily write a set of library routines that handle
incoming and outgoing port access using a unified set of file locks, and
simply link that into applications as required, thus solving the other
philosophical issue of not re-inventing the wheel and using common tools.

> I have never seen this implemented anywhere but in Commodore's SVR4,
> anyone else?

As I said, there are variations of this approach in all SysVr4's that
I've seen (AT&T, NEC, Pyramid, Motorola, ESIX, CBM, IPL(sp? -- you know,
that British company that did the official Sparc port)).

-- 
						Greg A. Woods

+1 416 443-1734			VE3TCP		robohack!woods
Planix, Inc. <woods@planix.com>; UniForum Canada <woods@uniforum.ca>