map. SunOS ypservers maps place the host name in the key and the val,
but HP-UX and NetBSD ypservers maps place the hostname only in the
key, leaving the val empty. Since there is no clear standard for this map,
best to play it safe.
a boot string for firmware that can do this, such as the SPARC and
the sun3 models. It is currently silently ignored on all other
hardware now, however. The MD function "boot()" has been changed to
also take a char *.
started if the directory /var/yp exists. Now, ypbind, ypserv, and
rpc.yppasswdd are started like other daemons; there are flags variables
for these programs. To disable them, set the variables to "NO", otherwise,
their contents are passed as flags.
YP server. This is required if the passwd database is to stay in sync
if this program is run on the YP server. Note, local passwd database
operations can still be performed by passing the -l flag.
YP server. This is required if the passwd database is to stay in sync
if this program is run on the YP server. Note, local passwd database
operations can still be performed by passing the -l flag.
Also, some minor cleanup and RCS id police.
allocation calls in the event the caller does not wish to utilize those
features of extent map allocation.
Suggested by Matthew Green <mrg@eterna.com.au>
Some cleanup of the remote tape interface, but a lot more is needed.
Ideally, we'd have a "rmt" library which provides a remote tape API
including open, read, write, close, and ioctl. This is useful not
only for mt, but also for programs like tar, cpio, pax, backup and
restore.
mapping code. (instead of using a "slot" and multiplying by 4 and adding the
pin number later to get the IRQ, just use base IRQ value and add the pin
number.)
comment immediately preceding it: We have to take the most significant
"numbits" from the returned value "ph", and the rest from our addr. The
addition used previously introduced a carry which was causing great
difficulty in determining the correct PA of the framebuffer VA passed in
by the booter.
values, i.e. 0xfffffffe and 0xffffffff respectively. The changed
definitions were incorrect, according to the PCI Local Bus Specification
(Revision 2.0). Further rationale and a workaround for the broken
devices that instigated the change provided in a message to
current-users@netbsd.org, dated Mon, 05 Aug 1996 22:06:58 -0400,
message ID 16773.839297218@ux2.sp.cs.cmu.edu>.
mrg