the C library "private" versions. Doing so results in unresolved
symbols the next time a dynamically linked program is run after the
new C library is installed.
XID confusions with servers that cache them over a long period and
with clients that reboot quickly.
Problems: because of the sanity check that is done by comparing the system
time with filesystem time, XIDs will start at 0 until root is mounted,
which means it isn't completely safe for diskless setups. But it's clearly
better than it was. It would also be cleaner if all XID handling (more
generally, all RPC handling) within the kernel went through the
same functions.
matic media detection on Sun4m machines which support multiple media
(UTP and AUI). New function lenocarrier() switches media type when called
if no link? flags are set.
Redefine link flags for Lance ethernet (le):
<none>: switch between media as needed to find carrier (autodetect)
Preference to whatever the PROM is using (AUI if not booted
from the network)
link0: use UTP port only
link1: use AUI port only
This allows Sun4m machines with dual media Lance ethernet adapters to
boot from the network on the UTP port.
function is called when carrier is lost in lieu of a console message.
This is used by the sparc port to switch media types on Sun4m machines
if the appropriate link flags are set by ifconfig (see following commit
message). Should not affect ports that do not use sc_nocarrier().
we managed to kill the following SCSI-driver bugs for the Falcon:
- The Byte_Count_zero bit of the falcon DMA controller does not always
tell the truth! This caused the SCSI-driver to choke on devices that
disconnected in the middle of a DMA-transfer (mostly removables).
- Printing debug info about the 5380 on the Falcon is *only* permitted
when DMA is not active.
- Some functions forgot to remove possibly pending sofware interrupts
- Some debug options didn't allow debugging a single target while they
could easily be made to do so. This is fixed.
passed to the execl(), execle(), and execlp() functions are in the form
of the argument vector to be passed to execve(). On these architectures,
it is unnecessary to count the number of arguments, allocate space on
the stack, copy the arguments, etc. The vector already on the stack
can be used instead.
When some arguments are passed in registers (like most RISC CPU's), it
should be possible to allocate stack space adjacent such that the
registers can be copied to that memory. After that, the same
approach described above can be used.
This change takes advantage of this on the i386, m68k, and ns32k. It
is probably true on the vax, but I am unable to check. RISC CPU's
probably need assembly language implementations to ensure everything
is placed exactly as needed when registers are copied to the stack...
cgd