This file describes the layout of the L.sys and L-devices files.

Here's my interpretation of L.sys:
	Site When Caller Class CallCode Login

The nominal value for Caller is ACU, but it can be the code for any
device that places calls, e.g., micom, datakit, ethernet, etc.  The
CallCode field contains the dope needed by the caller to complete the
connection, e.g., for an ACU, CallCode is the phone number, while for,
say, a micom, CallCode is the micom code for Site.  Class is nominally
speed, but circumstances sometimes make it necessary to encode other
information here.  E.g., at Bell Labs many sites distinguish centrex and
dimension.  Some use it to identify sites that answer vadic only.

For ACU Callers, this is the old interpretation.  Some examples:
	lento Any ACU	   D1200  MHd7464	 ...
	lento Any ACU	   C1200  MH2057	 ...
	lento Any MICOM    9600   lento 	 ...
	lento Any DK	   unused mh/tempo/lento ...
	lento Any UNET	   lento  33		 ...
	lento Any DIR	   9600   tty42 	 ...
	lento Any DIR	   2400	  tty43		 ...

i.e., to get to lento, dial on an ACU, or open a micom port and whisper
"lento" down it, or open a datakit port and shout "mh/tempo/lento" down
it, or open Unet server 33 on Unet host 'lento', or call on tty42.

Here's my interpretation of L-devices:
	Caller	Line	Useful	Class	Dialer

Caller and Class are as above.  Line identifies the device on which the
call is placed.  The Useful field is a place to identify something else
needed to dial, e.g., the name of a dialing device, or a code to get
past a sentry.  The (new) Dialer field identifies the type of dialer
being used so that the right dialing function can be called.  Some examples:

	ACU	cul0	cua0	1200	dn11
	ACU	cul1	cua1	1200	dn11
	ACU	tty49	unused	1200	ventel
	ACU	tty49	unused	300	ventel
	ACU	tty48	unused	V1200	vadic
	ACU	tty47	unused	1200	hayes
	ACU	tty47	unused	300	hayes
	MICOM	micom	unused	9600	micom
	DIR	tty42	unused	9600	direct

If you wish to add another dialer/caller type, you must add a line to the
condevs structure definded in condevs.c.  There is a line in the condevs
table for each device type listed in the L-devices file.  The condev structure
looks like:
	struct condev {
		char *CU_meth;		/* method, such as "ACU" or "DIR" */
		char *CU_brand;		/* brand, such as "vadic" or "ventel" */
		int (*CU_gen)();	/* what to call to search for brands */
		int (*CU_open)();	/* what to call to open brand */
		int (*CU_clos)();	/* what to call to close brand */
		} condevs[];

The line for the Ventel might look like:
	{ "ACU", "ventel", Acuopn, ventopn, ventcls },
While the line for the UNET interface might look like:
	{ "UNET", "unet", unetopn, nulldev, unetcls },

There can be many 'brands' of the same kind of device, such as auto-dialers.
The condevs array is searched for a method that matches the one in the L.sys
file.  The string comparison is done without regard to case, so "Acu" will
match "ACU".  Once a match is found, the routine pointed to by CU_gen is
called.  It is passed a pointer to the flds array, the array of pointers to
strings derived from the L.sys entry.

Typically, the CU_gen vector goes through the L-device table looking for
a entry that is available, then trys to connect on that brand via the
CU_open vector.  If that fails, it might go on to the next brand.
When it succeeds in opening a line, it should assign the brand closing
vector (CU_clos) to the global symbol CU_end (i.e. CU_end = cd->CU_clos).
The routine pointed to by CU_end is called when the line is to be shutdown.
It is passed a file descriptor which it is to close.

Another ACU can be added by writing the code for the CU_open and CU_clos
and adding a line in the condevs[] table.  The routine pointed to by
CU_open is passed a pointer to the phone number; a pointer to the flds array;
and a pointer to the dev structure, which contains the information from the
L-devices entry.  It should return a file descriptor that can be used to
communicate with the other machine, or CF_DIAL if the connection was not made.