Match the end-of-line after file extensions, so that *.[ch] files
with version numbers in their pathnames (e.g., libpcap-0.8.3/gencode.c)
do not match the manual-page regular expression.
we can append to it. Modify the code so that file_write is re-entrant,
even in the gnu long name/link hack.
The old code assumed that the buffer already contained the necessary
blocks to satisfy the read file request that contained the long
filename. This is not always the case, specially when we are dealing
with pipes which do shorter reads, thus having more probability
that a long file name will fall across a buffer boundary.
To reproduce, create a tar archive with a lot of gnu-long-names
(pkgsrc/devel/libsigc++2 is a good example), do a tar -tf to get
a list of filenames, compress it and do a tar -tzf to get another
list of the filenames. Notice that the two lists differ.
calls to ensure that the vnode lock state is as expected when the VOP
call is made. Modify vnode_if.src to set the expected state according
to the documenting lock table for each VOP. Modify vnode_if.sh to emit
the checks.
Notes:
- The checks are only performed if the vnode has the VLOCKSWORK bit
set. Some file systems (e.g. specfs) don't even bother with vnode
locks, so of course the checks will fail.
- We can't actually run with VNODE_LOCKDEBUG because there are so many
vnode locking problems, not the least of which is the "use SHARED for
VOP_READ()" issue, which screws things up for the entire call chain.
Inspired by similar changes in OpenBSD, but implemented differently.
provide f_frsize. It cannot be actually used to GNU C statvfs() bug
in f_frsize != f_bsize case, so just keep pretending we don't support it.
Update comments and explain the situation in detail there.
explicit size types - the structure definition is actually identical
on currently support COMPAT_LINUX archs, so no point to have 6 copies of it
in the tree
in the queue -- do not attempt to requeue it. We only poll in two cases:
1) We have a non-interrupting controller. In this case, execution of the
previous command should have left the queue empty. (Perhaps there should be
a KASSERT() to this effect.)
2) We're in the shutdown path, either doing a cache sync or a dump. In these
cases, the retry behavior is useless, because we will no longer get
interrupts to notify us that the earlier commands completed. Instead we
just spin for a few seconds and fail anyway. (XXX We should probably clear
the queue explicitly so that the shutdown/dump will succeed.)
snj