On Thu, 26 Dec 1996, Michael Richardson wrote:

>   Now, I run mgetty on a 486.
> ...
>   DTR up to answer, and ATS0=1 just don't pass these days anymore. I
> want to recognize fax calls. I want to grab caller id strings, I want
> to know what the kind of call it is on the ISDN.

These are the sort of things that mgetty is designed for.

>   I'd rather see "POTS" domain sockets, with "connect(2)" being the
> interface to dialing the phone, rather than dialin/dialout devices. In
> my mind, Mouse's three devices are:

The problem here is that you're moving something fairly large and
complex into the kernel. I can see several reasons not to do this:

1. It's going to be rather big.

2. It needs access to userland data, such as /etc/modemcap or
whatever you use to describe and configure modems. (I would think
that looking at the NetBlazer modemcap would give you a good idea
of where to start on this.) Then of course things get interesting
if those data aren't present, or are corrupt. The other, even less
desirable, option is to compile all your modem types into the
kernel.

3. Some people are not in a position to use this system, anyway.
If you have a (very) old modem that doesn't support AT commands,
or if you have an unknown brand of modem that your modem layer
can't identify, you need to be able to do the `DTR up to answer'
thing. Or maybe you just don't want the hassle.

4. It doesn't offer an easy choice of which scheme you want to use.
Currently, you can use the standard getty, my uugetty (which is
nearly as simple), mgetty, or something completely different
(hylafax, for example). Once you've compiled this stuff into the
kernel you loose some of that choice.

I've been putting off committing the locking code to getty for
several reasons. The big one is that I keep having machines wanting
care and feeding arrive on my doorstep on a regular basis. Another,
was that I wanted to see if anyone was actually interested enough
in the kernel locking schemes that they were arguing for actually
to write code for it. (Apparently not.) So I do intend to commit
the userland uugetty locking stuff at some point in the future,
probably within the next few weeks.

cjs

Curt Sampson    cjs@portal.ca		Info at http://www.portal.ca/
Internet Portal Services, Inc.	
Vancouver, BC   (604) 257-9400		De gustibus, aut bene aut nihil.