rev 1.27 ("iso8601" option keyword) revs 1.12/1.10/1.5/1.4 ($CVSHeader$
support) rev 1.2 ($CVS_LOCAL_BRANCH_NUM support for local commit
feature of cvsup) into version 1.11.22.
Note rev 1.21 ("-D date" checkout bug relating to 1.1.1.1 vs 1.1
revisions), rev 1.13 (allow -D'date' with -r'branch' on a checkout),
rev 1.6 (use xstrdup rather than strdup) are fixed in the vendor sources
rev 1.17 (environtmental var "CVS_OPTIONS"), rev 1.14 ('-g' option to
support shared-group access), rev 1.7 ('-R' read-only repository mode),
rev 1.6 (support for checking out from a read-only repository),
revs 1.4 & 1.5 ("tagexpand=") into version 1.11.22.
Merge rev 1.14: comprehensive -T CVS/Template support, rev 1.9: new long
flag that causes cvs to ignore the CVSROOT/passwd file, rev 1.3: support
for checking out from a read-only repository, rev. 1.2: support for local
$Id$ keyword into cvs 1.11.22.
Note that rev 1.4 (make verifymsg extra useful) is OBE.
rev 1.4: flip the default for CVS_RSH to "ssh", rev 1.2: fix a problem
sometimes seen when doing checkouts from a local repo and committing
via remote cvs (a cvs -d override of the mismatched CVS/Root files was
missing) into cvs 1.11.22.
disk image. In some cases this can be a significant speed-up, if
most of the image can be kept in RAM while being populated.
On the 2GB image I'm currently working with, the build time,
excluding buildworld/buildkernel, goes from ~17 minutes to ~6
minutes.
This is not enabled by default, as it might have the opposite effect
on low-memory systems.
- During the generation of the image file be a bit more verbose in the
log file so it is possible to see what's being done.
- Add a NANO_DISKIMGDIR variable which makes it possibly to place the
final images somewhere other than ${MAKEOBJDIRPREFIX}. The default
value for NANO_DISKIMGDIR is $MAKEOBJDIRPREFIX.
Go for it: phk
zone code. The GPE handler method (i.e. _L00) generates various Notify
events that need to be run to completion before the GPE is re-enabled.
In ACPI-CA, we queue an asynch callback at the same priority as a Notify
so that it will only run after all Notify handlers have completed. The
callback re-enables the GPE afterwards. We also changed the priority of
Notifies to be the same as GPEs, given the possibility that another GPE
could arrive before the Notifies have completed and we don't want it to
get queued ahead of the rest.
The ACPI-CA change was submitted by Alexey Starikovskiy (SUSE) and will
appear in a later release. Special thanks to him for helping track this
bug down.
MFC after: 1 week
Tested by: jhb, Yousif Hassan <yousif / alumni.jmu.edu>
zone code. The GPE handler method (i.e. _L00) generates various Notify
events that need to be run to completion before the GPE is re-enabled.
In ACPI-CA, we queue an asynch callback at the same priority as a Notify
so that it will only run after all Notify handlers have completed. The
callback re-enables the GPE afterwards. We also changed the priority of
Notifies to be the same as GPEs, given the possibility that another GPE
could arrive before the Notifies have completed and we don't want it to
get queued ahead of the rest.
The ACPI-CA change was submitted by Alexey Starikovskiy (SUSE) and will
appear in a later release. Special thanks to him for helping track this
bug down.
MFC after: 1 week
Tested by: jhb, Yousif Hassan <yousif / alumni.jmu.edu>
memcpy/memset/memcmp and friends from libkern/arm to arm/arm/support.S, and so
I did, but in the process, I didn't add the appropriate copyrights.
This is a major oversight from me, and I apology to the NetBSD people for it.
MFC After: 1 day
included in the kernel by default. Remove reference to this option
from defaults/rc.conf and rc.conf(5).
PR: conf/119098
Submitted by: Beat Gaetzi
MFC after: 1 week
more carefully inspecting the return value from sysctl(3). [1]
- Use calloc instead of malloc+memset of zero.
Submitted by: Alexander Chernikov <admin su29 net> [1]
PR: bin/119581
MFC after: 2 weeks
via a new socket during an NFS operation as that reconnect takes place in
the context of an arbitrary thread with an arbitrary credential. Ideally
we would like to use the mount point's credential for the entire process
of setting up the socket to connect to the NFS server. Since some of the
APIs (sobind(), etc.) only take a thread pointer and infer the credential
from that instead of a direct credential, work around the problem by
temporarily changing the current thread's credential to that of the mount
point while connecting the socket and then reverting back to the original
credential when we are done.
Reviewed by: rwatson
Tested on: UDP, TCP, TCP with forced reconnect
of fpget*() and fpset*()).
The i386 fpget*() were efficient but a bit obfuscated (using macros
and a case statement to demultiplex them through a single inline).
The demultiplexing mainly gave smaller source code.
The i386 fpset*() were obfuscated in the same way and were very
inefficient due to the case statement not having enough cases or
complexity so all cases used the FP environment.
This also fixes a harmless bug in rev.1.12. fpsetmask() extracted the
old value from the bit-field twice, but the doubled shift was harmless
since the shift count is 0.
All fp*() interfaces are now inline functions on i386. They used to
be macros that call (a different set of) inline functions. This is a
small ABI change which shouldn't cause problems since cases where
inlining fails (mainly -O0) only give (working) static functions.
others can be replaced cleanly by the amd64 versions. There is no
current amd64 version to merge, but there is an old one which is
similar.
Fix the following bugs in fpresetsticky():
- garbage args clobbered non-sticky bits in the status register
- the return value was usually garbage since it was masked with the
arg instead of with the field selector.
Optimize fpresetsticky() to avoid using the environment as in
feclearexcept() (use only fnclex() if possible) and also to avoid
using fnclex() for null changes. The second of these optimizations
might not be so good since its branch might cost more than it saves.
