is now synchronized by a mutex, whereas access to user maps is still
synchronized by a lockmgr()-based lock. Why? No single type of lock,
including sx locks, meets the requirements of both types of vm map.
Sometimes we sleep while holding the lock on a user map. Thus, a
a mutex isn't appropriate. On the other hand, both lockmgr()-based
and sx locks release Giant when a thread/process blocks during
contention for a lock. This could lead to a race condition in a legacy
driver (that relies on Giant for synchronization) if it attempts to
kmem_malloc() and fails to immediately obtain the lock. Fortunately,
we never sleep while holding a system map lock.
calling getmicrouptime (but maintain the struct timeval-based calling
convention for compatibility)
o eliminate the use of timersub in ratecheck
Note that flood ping tests indicate ppsratecheck is inaccurate (but on the
conservative side) with this revised implementation. If more accuracy is
needed we'll have to introduce an alternate interface or increase the
overhead.
Reviewed by: silby, dillon, bde
to /dev/raidctl, don't set the group to operator. (This isn't a
storage device, it's a control device).
Also, since umask here is already restrictive, we don't need to
explicitly set the mode.
Submitted by: bde
implement ALT_BREAK_TO_DEBUGGER. The caller provides a pointer to a state
variable to allow different state to be maintained for separate instances of
a device.
- Use struct vm_map * instead of vm_map_t in db_break.h to avoid its users
needing to include vm headers.
Requested by: njl
for the raidctl device.
Select a more conservative default for the permissions for /dev/raidctl
since the operations are performed using ioctl() not read() and write().
Submitted by: kris
Reviewed by: scottl
Use BUS_SPACE_MAXSIZE_32BIT for the parent dma tags, and
(NSEGS - 1) * PAGE_SIZE for the data buffer tags. FreeBSD/sparc64 is
more strict about checking these values that other arches.
It is not complete (the LILO root= specification isn't passed to our
loader for instance), it has not been touched in over 2 years. Linux has
moved on to GRUB, so this is OBE now. If someone creeps up to work on it,
it could become a port.
handbook on sunsolve for hardware details.
- Clarify what's "fully" supported, and what's only partially supported or
not at all supported due to varying support for onboard devices.
- Update with new stuff that should work or has been tested.
were sometimes propagated using M_COPY_PKTHDR which actually did
something between a "move" and a "copy" operation. This is replaced
by M_MOVE_PKTHDR (which copies the pkthdr contents and "removes" it
from the source mbuf) and m_dup_pkthdr which copies the packet
header contents including any m_tag chain. This corrects numerous
problems whereby mbuf tags could be lost during packet manipulations.
These changes also introduce arguments to m_tag_copy and m_tag_copy_chain
to specify if the tag copy work should potentially block. This
introduces an incompatibility with openbsd which we may want to revisit.
Note that move/dup of packet headers does not handle target mbufs
that have a cluster bound to them. We may want to support this;
for now we watch for it with an assert.
Finally, M_COPYFLAGS was updated to include M_FIRSTFRAG|M_LASTFRAG.
Supported by: Vernier Networks
Reviewed by: Robert Watson <rwatson@FreeBSD.org>
Note that the original RFC 1323 (PAWS) says in 4.2.1 that the out of
order / reverse-time-indexed packet should be acknowledged as specified
in RFC-793 page 69 then dropped. The original PAWS code in FreeBSD (1994)
simply acknowledged the segment unconditionally, which is incorrect, and
was fixed in 1.183 (2002). At the moment we do not do checks for SYN or FIN
in addition to (tlen != 0), which may or may not be correct, but the
worst that ought to happen should be a retry by the sender.
SIZE_T_MAX characters in the header that reports block sizes. A field
width of 2^64 won't be needed until block sizes reach approximately 10^(2^64).
It really has nothing to do with supporting block sizes of 2^64.
As told by: bde
similar to "-h" on chown, chmod, etc, causing the operation to occur
on a final symlink in the provided path, rather than its target.
Obtained from: TrustedBSD Project
