[ On Mon, December 19, 1994 at 14:52:04 (-0600), Mark P. Gooderum wrote: ]
> Subject: Re: Formal getty replacement yet? 
>
> True, but if it works, it's much more bullet-proof.  Automatic cleanup
> of locks on process exit, etc.  It's also a fix in one place
> as opposed to a 1/2 dozen.  Having done both, I can say I prefer 
> bi-directional devices to lock file support.

I appreciate your point, but I think you've overlooked the complexity
factor.  If it's an order of magnitude easier to fix the external locks
(and assuming there's a library routine to use them, it's only one place
to fix), then even with kernel/driver source, do you want to dive in
there each time something doesn't work right?

Having worked on at least a dozen systems with each style of port access
control, I would vote 100%, 10 times out of 10, to keep the locks out of
the kernel, regardless of how much source code I have.  I admit that
working dial-in/dial-out devices make the user-level code trivial, but
as I say, I'd rather have that complexity at user-level than in the
kernel.  It is a user-level problem, after all.

This issue has also got to do with just how easy it is to determine the
current state of the system.  Wouldn't SyV-style IPC be soooo much
easier to deal with if every IPC related object had a name in the
filesystem that controlled and reported its state?

> But it's often easier to find out the software config than the
> hardware config and it is often easier for a system admin to
> have the hardware as standard as possible and adjust the system 
> config (you could argue the other way I'll grant in advance)..
> It's a matter of preference.

I'd say the level of complexity of getting the hardware right, vs.
having zillions of software support options speaks for itself, but then
I'm a soldering iron and screwdriver kinda guy....

> Also, the world will always be stuck supporting deficient hardware (modem 
> doesn't drive the lines correctly, the terminal is on the other end of
> an existing cable that isn't proper, etc).  Give the software 
> fix to the user/admin, let them use which they prefer.

There are always the sarcastic answers:  "get a *real* modem!", or "fix
the stupid cable!", etc....

> Admittedly though, my current solution is software, although it
> doesn't involve any Getty changes.  I use flexfax with great 
> success.  It only spawns Getty when it needs to, maintains the UUCP lock 
> files itself, and gives a nice status as well.  As long as
> your outgoing programs use/honor UUCP lock files (both tip and the latest 
> Kermit do), works great.  One part I like about flex-fax is it 
> gives me a single software point of control for the modem/line.  I can
> set the number of rings to answer on, whether the port supports login, etc,
> in one place.  No need to worry about setting the S0 reg (and saving
> it), etc. 

True enough -- a simple, and rather elegant software solution, with a
different way of looking at the problem.  I once thought long and hard
about this style of port control, but I think it's still overly complex.

If you have simple async ports, and properly configured software and
hardware, port access control is brain-dead simple, and there are
*always* manual work-arounds (that don't require re-boots) for any given
emergency.  Additional tools to support features like manually locking
ports, etc., are very simple to devise and use.

-- 
						Greg A. Woods

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