References from GDB to "printf" and various other functions would
find the versions in the dynamic linker itself, rather than the
versions in the program's libc. This fix moves the GDB link map
entry for the dynamic linker to the end of the search list, where
its symbols will be found only if they are not found anywhere else.
It was suggested by Doug Rabson, though I implemented it a little
differently.
I personally would prefer to leave the dynamic linker's entry out
of the GDB search list altogether. But Doug argues that it is
handy there for such things as setting breakpoints on dlopen().
So it stays for now, at least.
Note, if we ever integrate the dynamic linker with libc (which has
several important benefits to recommend it), this whole problem
goes away.
minus the NULL pointer dereference in rev. 1.33. Also simplify
things somewhat by eliminating one traversal of the VM map entries.
Finally, eliminate calls to vm_map_{un,}lock_read() which aren't
needed here. I originally took them from procfs_map.c, but here
we know we are dealing only with the map of the current process.
only. Previously, if the device was chmoded 644, someone could open it
with the O_RDONLY flag and issue any ioctl to the device.
Reviewed by: imp, gibbs
segments (except memory-mapped devices) in the ELF core file. This
is really nice. You get access to the data areas of all shared
libraries, and even to files that are mapped read-write.
In the future, it might be good to add a new resource limit in the
spirit of RLIMIT_CORE. It would specify the maximum sized writable
segment to include in core dumps. Segments larger than that would
be omitted. This would be useful for programs that map very large
files read/write but that still would like to get usable core dumps.
dynamic linker itself dynamically allocated. All of them are
supposed to be dynamically allocated, but we cheated before. It
made gdb unhappy under some circumstances.
Kazu writes:
The VESA support code requires vm86 support. Make sure your kernel
configuration file has the following line.
options "VM86"
If you want to statically link the VESA support code to the kernel,
add the following option to the kernel configuration file.
options "VESA"
The vidcontrol command now accepts the following video mode names:
VESA_132x25, VESA_132x43, VESA_132x50, VESA_132x60, VESA_800x600
The VESA_800x600 mode is a raster display mode. The 80x25 text will
be displayed on the 800x600 screen. Useful for some laptop computers.
vidcontrol accepts the new `-i <info>' option, where <info> must be
either `adapter' or `mode'. When the `-i adapter' option is given,
vidcontrol will print basic information (not much) on the video
adapter. When the `-i mode' option is specified, vidcontrol will
list video modes which are actually supported by the video adapter.
Submitted by: Kazutaka YOKOTA yokota@FreeBSD.ORG
committed a fix for in 2 days and 3 different people have forgotten
to update this file. GRRR! What's it going to take, electrodes to
the sensitive bits, people?? :-)
===================================
HARP | Host ATM Research Platform
===================================
HARP 3
What is this stuff?
-------------------
The Advanced Networking Group (ANG) at the Minnesota Supercomputer Center,
Inc. (MSCI), as part of its work on the MAGIC Gigabit Testbed, developed
the Host ATM Research Platform (HARP) software, which allows IP hosts to
communicate over ATM networks using standard protocols. It is intended to
be a high-quality platform for IP/ATM research.
HARP provides a way for IP hosts to connect to ATM networks. It supports
standard methods of communication using IP over ATM. A host's standard IP
software sends and receives datagrams via a HARP ATM interface. HARP provides
functionality similar to (and typically replaces) vendor-provided ATM device
driver software.
HARP includes full source code, making it possible for researchers to
experiment with different approaches to running IP over ATM. HARP is
self-contained; it requires no other licenses or commercial software packages.
HARP implements support for the IETF Classical IP model for using IP over ATM
networks, including:
o IETF ATMARP address resolution client
o IETF ATMARP address resolution server
o IETF SCSP/ATMARP server
o UNI 3.1 and 3.0 signalling protocols
o Fore Systems's SPANS signalling protocol
What's supported
----------------
The following are supported by HARP 3:
o ATM Host Interfaces
- FORE Systems, Inc. SBA-200 and SBA-200E ATM SBus Adapters
- FORE Systems, Inc. PCA-200E ATM PCI Adapters
- Efficient Networks, Inc. ENI-155p ATM PCI Adapters
o ATM Signalling Protocols
- The ATM Forum UNI 3.1 signalling protocol
- The ATM Forum UNI 3.0 signalling protocol
- The ATM Forum ILMI address registration
- FORE Systems's proprietary SPANS signalling protocol
- Permanent Virtual Channels (PVCs)
o IETF "Classical IP and ARP over ATM" model
- RFC 1483, "Multiprotocol Encapsulation over ATM Adaptation Layer 5"
- RFC 1577, "Classical IP and ARP over ATM"
- RFC 1626, "Default IP MTU for use over ATM AAL5"
- RFC 1755, "ATM Signaling Support for IP over ATM"
- RFC 2225, "Classical IP and ARP over ATM"
- RFC 2334, "Server Cache Synchronization Protocol (SCSP)"
- Internet Draft draft-ietf-ion-scsp-atmarp-00.txt,
"A Distributed ATMARP Service Using SCSP"
o ATM Sockets interface
- The file atm-sockets.txt contains further information
What's not supported
--------------------
The following major features of the above list are not currently supported:
o UNI point-to-multipoint support
o Driver support for Traffic Control/Quality of Service
o SPANS multicast and MPP support
o SPANS signalling using Efficient adapters
This software was developed under the sponsorship of the Defense Advanced
Research Projects Agency (DARPA).
Reviewed (lightly) by: phk
Submitted by: Network Computing Services, Inc.
the MFS size of net and isp floppies.
Add comment to crunch.conf on how to prepare the ucd-snmp port to work
with the build process.
Submitted by: Jim Flowers <jflowers@ezo.net>
