FIFO, as required by SUSv3. No specific privilege check is performed
in this case, as FIFOs may be created by unprivileged processes
(subject to the normal file system name space restrictions that may be
in place).
Unlike the Apple implementation, we reject requests to create a FIFO
using mknod(2) if there is a non-zero dev argument to the system call,
which is permitted by the Open Group specification ("... undefined
..."). We might want to revise this if we find it causes
compatibility problems for applications in practice.
PR: kern/74242, kern/68459
Obtained from: Apple, Inc.
MFC after: 3 weeks
fifos, as this is required by the Single UNIX Specification, although
not currently implemented on FreeBSD.
While here, fix a bug in the directory timestamp checking test by
sleeping after querying the starting timestamp, rather than before.
performed. Otherwise if ruleset is used by given mountpoint and is empty
it's freed by devfs_ruleset_reap and pointer becomes bogus.
Submitted by: Mateusz Guzik <mjguzik@gmail.com>
PR: kern/124853
some time now so collapse calls accordingly.
o Given that gem_load_txmbuf() is allowed to fail resulting in a packet
drop also for quite some time now implement the functionality of
gem_txcksum() by means of m_pullup(9), which de-obfuscates the code
and allows to always retrieve the correct length of the IP header.
o Add missing BUS_DMASYNC_PREREAD when syncing the control DMA maps in
gem_rint() and gem_start_locked().
o Correct some bus_barrier(9) calls to do a read/write barrier as we
do a read after a write. Add some missing ones in gem_mii_readreg()
and gem_mii_writereg().
o According to the Apple GMAC driver, the GEM ASIC specification and
the OpenSolaris eri(7D) the TX FIFO threshold has to be set to 0x4ff
for the Gigabit variants and 0x100 for the ERI in order do avoid TX
underruns.
o In gem_init_locked():
- be conservative and enable the RX and TX MACs,
- don't clear GEM_LINK otherwise we don't ever mark the link as up
again if gem_init_locked() is called from gem_watchdog(),
- remove superfluous setting of sc_ifflags.
o Don't bother to check whether the interface is running or whether its
queue is empty before calling gem_start_locked() in gem_tint(), the
former will check these anyway.
o Call gem_start_locked() in gem_watchdog() in order to try to get
some more packets going.
o In gem_mii_writereg() after reseting the PCS restore its configuration.
GMAC testing: grehan, marcel
MFC after: 2 weeks
on the amd64 architecture. The amd64 architecture requires kernel code and
global variables to reside in the highest 2GB of the 64-bit virtual address
space. Thus, the memory allocated during bootstrap, before the call to
kmem_init(), starts at KERNBASE, which is not necessarily the same as
VM_MIN_KERNEL_ADDRESS on amd64.
PowerPC/AIM. Consequently, it should not be used to determine the maximum
number of kernel map entries. Intead, use VM_MIN_KERNEL_ADDRESS, which marks
the start of the kernel map on all architectures.
Tested by: marcel@ (PowerPC/AIM)
KERNBASE and VM_MIN_KERNEL_ADDRESS are no longer the same, the physical
memory allocated during bootstrap will be offset from the low-end of the
kernel's page table.
file into a separate file (instead of embedding it in the C code)
and use later timestamps (timestamps too close to the Epoch fail
predictably on systems that lack timegm(), whose mktime() doesn't
support dates before the Epoch and which are running in timezones
with negative offsets from GMT). The goal here is to test the ISO
extraction, not the local platform's time support.
operation) and not ARCHIVE_WARN, since we don't actually open the file.
Both bsdtar and bsdcpio will try to copy file contents after an ARCHIVE_WARN,
which will fail loudly.
link, just ignore the -l option and copy the file instead.
In particular, this should fix the COPYTREE_* macros used in the
ports infrastructure which use -l to preserve space but often get
used for cross-device copies.
address space on the amd64 architecture. The amd64 architecture
requires kernel code and global variables to reside in the highest 2GB
of the 64-bit virtual address space. Thus, KERNBASE cannot change.
However, KERNBASE is sometimes used as the start of the kernel virtual
address space. Henceforth, VM_MIN_KERNEL_ADDRESS should be used
instead. Since KERNBASE and VM_MIN_KERNEL_ADDRESS are still the same
address, there should be no visible effect from this change (yet).
That said, kris@ has tested crash dumps under the full patch that
increases the kernel virtual address space on amd64 to 6GB.
Tested by: kris@
noticed that a "whereis -qs qemu" matched the distfiles subdir of qemu
rather than /usr/ports/emulators/qemu.
It now ignores all dot entries in /usr/ports, plus all entries
starting with a capital letter (maintenance stuff like Templates, but
also includes subdir CVS), plus /usr/ports/distfiles which is simply a
magic name in that respect.
address space on the amd64 architecture. The amd64 architecture
requires kernel code and global variables to reside in the highest 2GB
of the 64-bit virtual address space. Thus, KERNBASE cannot change.
However, KERNBASE is sometimes used as the start of the kernel virtual
address space. Henceforth, VM_MIN_KERNEL_ADDRESS should be used
instead. Since KERNBASE and VM_MIN_KERNEL_ADDRESS are still the same
address, there should be no visible effect from this change (yet).
