1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
|
.TH DKMGR 8
.CT 1 sa_auto
.SH NAME
dkhup, dkmgr, dkzap \- manage Datakit interface
.SH SYNOPSIS
.B /usr/ipc/mgrs/dkhup
[
.B -N
.I prefix
]
.br
.B /usr/ipc/mgrs/dkmgr
[
.B -N
.I prefix
] [
.B -m
.I outname
] [
.B -n
.I service
]
.br
.B /usr/ipc/mgrs/dkzap
[
.B -N
.I prefix
]
.SH DESCRIPTION
.I Dkhup
starts the common signaling channel protocol
for a Datakit interface.
Initially it sends several reset messages,
and tells the controller
to hang up all outstanding calls;
thereafter it simply keeps the signaling protocol running.
.PP
.I Dkmgr
receives and places Datakit calls.
Outbound calls may be placed by calling
.I ipcopen
.RI ( ipc (3))
with the
.I outname
specified by option
.BR -m ;
the default is
.BR dk .
.I Dkmgr
announces itself to the Datakit network
with the
.I service
name specified by option
.BR -n ;
the default is taken from
.FR /etc/whoami .
Inbound calls to
.I service
are connected to the local
.L login
service;
inbound calls to
Datakit address
.IB service . serv
are handed to local service
.IR serv .
.PP
.I Dkhup
and
.I dkmgr
are normally run once from
.IR rc (8).
Both programs must be running
to make the network available.
.PP
.I Dkzap
arranges for a KMC11-assisted Datakit interface
to be reset, reloaded, and restarted.
This should be done only if things are badly broken,
as it hangs up all existing calls through that interface.
.PP
Datakit devices are expected to have names of the form
.BI /dev/dk/dk nn
with
.I nn
a two-digit channel number.
If there are more than 100 channels,
the first digit overflows to lower-case letters:
channel 100 is
.LR a0 .
The common signaling control channel
is named
.BR /dev/dk/dkctl .
All three programs accept an option
.B -N
.I prefix
to change the naming convention;
for example,
.B -N /dev/kb/kb
means that the files have names like
.B /dev/kb/kb32
and
.BR /dev/kb/kbctl .
.PP
Support also exists for a less general naming convention:
there may be two sets of files,
named
.BI /dev/dk/dk0 nn
and
.BI /dev/dk/dk2 nn\c
,
with control channels
.B /dev/dk/dkctl0
and
.BR /dev/dk/dkctl2 .
.I Dkhup
and
.I dkzap
take the extra argument
.B 0
or
.B 2
to point at one or the other of the control names.
A separate copy of
.I dkhup
is needed for each name.
.I Dkmgr
takes an option
.B -u
.IR c ,
where
.I c
is
.B 0
or
.B 2
to use one set of files,
or
.B b
to use both simultaneously;
in the latter case,
.I service
is announced to both networks.
This scheme is obsolete and overdue for replacement;
the missing piece is something to pick an interface for outcalls.
.PP
.I Dkmgr
records its activity in file
.I service
in directory
.BR /usr/ipc/log ,
default
.BR /usr/ipc/log/dk .
.SH FILES
.F /dev/dk
.SH "SEE ALSO"
.IR con (1),
.IR kmc (8),
.IR svcmgr (8),
.IR ipc (3)
.SH BUGS
.I Dkhup
should be folded into
.IR dkmgr ;
it is separate for historic reasons.
|
