the login_cap and login.access checks for whether a user/host is allowed
access to the system for users other than root. But since we currently don't
have a similar check in the ssh2 code path anyway, it's um, "okay".
Submitted by: gshapiro
and bump __FreeBSD_version to 500012 to mark the occasion.
setproctitle() is prototyped in unistd.h as opposed to stdlib.h
where OpenBSD and NetBSD have it.
Reviewed by: peter
machines. The patch uses an existing global variable in place of the
newbus accessor to get at use_bwx.
This is a quick fix to get miatas booting again; somebody
with more newbus skills than I can muster will have to correct it.
Matt Jacob's description of the problem from the -alpha list:
The IVAR accessor stuff for pcib is incompletely specified for CIA. There's
only one accessor defined, and that's to get the BUS instance number.
<..>
The device methods that try and get at the use_bwx get overriden because
there's only one ivar for CIA's pcib, and that's for hose #, and it's always
zero.
the link and activity LED control bits in CSR15 in order for the
controller to drive the LEDs correctly. This was largely done for the
ZNYX multiport cards, but should also work with the DEC DE500-BA
and other non-MII cards.
enable bit hasn't been set in the command register, set the bit and
honour the register. It seems that quite a few lazy BIOS writers
aren't bothering to do this, which upsets the existing code and causes
us to miss out on properly-configured devices.
pcib instance is initialized because accesses to PCI_Config region can
occur during ACPI initialization.
Note that this is a short term solution, more consideration will be
required in order to integrate ACPI into the newbus probe sequence.
change channel interface - kobj implementation coming soonish
make pcm_makelinks not panic if modular
add pcm_unregister()
these changes support newpcm kld unloading, but this is only implemented
by ds1.c
datagram embedded into ICMP error message, not with protocol
field of ICMP message itself (which is always IPPROTO_ICMP).
Pointed by: Erik Salander <erik@whistle.com>
rather than implementing its own {uid,gid,other} checks against vnode
mode. Similar change to linprocfs currently under review.
Obtained from: TrustedBSD Project
fields between host and network byte order. The details:
o icmp_error() now does not add IP header length. This fixes the problem
when icmp_error() is called from ip_forward(). In this case the ip_len
of the original IP datagram returned with ICMP error was wrong.
o icmp_error() expects all three fields, ip_len, ip_id and ip_off in host
byte order, so DTRT and convert these fields back to network byte order
before sending a message. This fixes the problem described in PR 16240
and PR 20877 (ip_id field was returned in host byte order).
o ip_ttl decrement operation in ip_forward() was moved down to make sure
that it does not corrupt the copy of original IP datagram passed later
to icmp_error().
o A copy of original IP datagram in ip_forward() was made a read-write,
independent copy. This fixes the problem I first reported to Garrett
Wollman and Bill Fenner and later put in audit trail of PR 16240:
ip_output() (not always) converts fields of original datagram to network
byte order, but because copy (mcopy) and its original (m) most likely
share the same mbuf cluster, ip_output()'s manipulations on original
also corrupted the copy.
o ip_output() now expects all three fields, ip_len, ip_off and (what is
significant) ip_id in host byte order. It was a headache for years that
ip_id was handled differently. The only compatibility issue here is the
raw IP socket interface with IP_HDRINCL socket option set and a non-zero
ip_id field, but ip.4 manual page was unclear on whether in this case
ip_id field should be in host or network byte order.
not alias `ip_src' unless it comes from the host an original
datagram that triggered this error message was destined for.
PR: 20712
Reviewed by: brian, Charles Mott <cmott@scientech.com>
This provides support for the Adaptec SCSI RAID controller family,
as well as the DPT SmartRAID V and VI families.
The driver will be maintained by Mark and Adaptec, and any changes
should be referred to the MAINTAINER.
