Subject: Re: Formal getty replacement yet?
To: Mark P. Gooderum <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 12/19/1994 17:28:14
[ 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. <email@example.com>; UniForum Canada <firstname.lastname@example.org>