is generic to any threading system. This commit does not link this
file to the build yet, nor does it remove these functions from their
current location in kern_thread.c. (that commit coming up after further review)
distinguish files from dirs (trailing '/' indicated a dir). Since
POSIX.1-1987, this convention is no longer necessary. However, there
are current tar programs that pretend to write POSIX-compliant
archives, yet store directories as "regular files", relying on this
old filename convention to save them. <sigh> So, move the check for
this old convention so it applies to all tar archives, not just those
identified as "old."
Pointed out by: Broken distfile for audio/faad port
it sees a truncated input the first time it gets called.
(In particular, files shorter than 512 bytes cannot be tar archives.)
This allows the top-level archive_read_next_header code to
generate a proper error message for unrecognized file types.
Pointed out by: numerous ports that expect tar to extract non-tar files ;-(
Thanks to: Kris Kennaway
an existing symlink (as might happen if you extract an archive twice).
Also, if we remove the offending link, then we've removed the problem
and can safely go forward with the extraction.
Pointed out by: print/adobe-cmaps port (whose distfile has
duplicate entries for the same symlinks)
Thanks to: Kris Kennaway (for using ports as a testbed for bsdtar)
--exclude='pattern'.
I should have added this a long time ago, since it's so useful for testing.
In particular, it allows me to select a few entries from a troublesome
archive so that I can easily focus my debugging efforts:
bsdtar -czf new.tgz --include='*foo*' @old.tgz
files to rotate. The new order will first rotate all files that need
to be rotated, and then send a single signal to each process which
needs to be signaled, and finally it will compress all the files which
were rotated.
This means daemons will be signaled once per run of newsyslog, instead
of once per file rotated. Also, files will be compressed in order of
file-size (smallest to largest). Also, it waits for each file to be
completely compressed before starting the next one (effectively as if
the 'w' flag is specified for all entries in newsyslog.conf). This
avoids the situation of having 10 gzip's going at the same time (each
with a log.0 and a log.0.gz file active), and it also means that file
attributes can be reliably set on files after they are compressed.
NOTE: This commit does define NEWORDER (which you could get rid of if
you really don't trust this), but it does not flip the "-D neworder"
switch. So, at the moment none of these changes happen unless you
request them (perhaps by adding '<debug> neworder' in newsyslog.conf).
PR: bin/25070 inspired some parts of this
Submitted by: parts from bin/25070 done by Helge Oldach
MFC after: 14 days
the newsyslog.conf file. Rename one size-related variable, and move
another one from the stack into conf_entry. Add a routine to change
file-attributes (chown, chmod, chflags), instead of having several
places doing the same sequence of system-calls. A few cosmetic/style
changes.
These should not effect any users. Most of these probably look
pointless, but they are the "insignificant parts" of a much larger
update that I'll be committing soon. Doing these as a separate update
should make that update easier to read.
MFC after: 14 days
(and not thread) scope is to be displayed, use KERN_PROC_ALL and
accrue CPU% ourselves, as the kernel makes no attempt to do so.
Of course, this doesn't make most stats any less bogus when displaying
threaded processes, but at least the CPU time is added up and not just
always 0.00%. There are still issues with SCHED_ULE in top(1) that
cause other processes to display 0.00% CPU when they in fact have used
more.
Dividing by 0 in order to check for irq13/exception16 delivery apparently
always causes an irq13 even if we have configured for exception16 (by
setting CR0_NE). This was expected, but the timing of the irq13 was
unexpected. Without CR0_NE, the irq13 is delivered synchronously at
least on my test machine, but with CR0_NE it is delivered a little
later (about 250 nsec) in PIC mode and much later (5000-10000 nsec)
in APIC mode. So especially in APIC mode, the irq13 may arrive after
it is supposed to be shut down. It should then be masked, but the
shutdown is incomplete, so the irq goes to a null handler that just
reports it as stray. The fix is to wait a bit after dividing by 0 to
give a good chance of the irq13 being handled by its proper handler.
Removed the hack that was supposed to recover from the incomplete shutdown
of irq13. The shutdown is now even more incomplete, or perhaps just
incomplete in a different way, but the hack now has no effect because
irq13 is edge triggered and handling of edge triggered interrupts is
now optimized by skipping their masking. The hack only worked due
to it accidentally not losing races.
The incomplete shutdown of irq13 still allows unprivileged users to
generate a stray irq13 (except on systems where irq13 is actually used)
by unmasking an npx exception and causing one. The exception gets
handled properly by the exception 16 handler. A spurious irq13 is
delivered asynchronously but is harmless (as in the probe) because it
is almost perfectly not handled by the null interrupt handler.
Perfectly not handling it involves mainly not resetting the npx busy
latch. This prevents further irq13's despite them not being masked in
the [A]PIC.
Removed paragraph about "new experimental feature" the hw.ata.tags
which sysctl -a knows nothing about.
Fix typos while I'm here.
PR: docs/66493
Submitted by: Julien Gabel <jpeg@thilelli.net>
It does not appear to be possible to cross-build arm from i386 at the
moment, and I have no ARM hardware anyway. Thus, I'm sure there are
bugs. I will gladly fix these when the arm port is more mature.
Reviewed by: standards@
features appear to work, subject to the caveat that you tell gcc you
want standard rather than recklessly fast behavior
(-mieee-with-inexact -mfp-rounding-mode=d).
The non-standard feature of delivering a SIGFPE when an application
raises an unmasked exception does not work, presumably due to a kernel
bug. This isn't so bad given that floating-point exceptions on the
Alpha architecture are not precise, so making them useful in userland
requires a significant amount of wizardry.
Reviewed by: standards@
