Subject: Re: Formal getty replacement yet?
To: Niklas Hallqvist <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 12/20/1994 17:13:01
[ 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
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. <email@example.com>; UniForum Canada <firstname.lastname@example.org>