churn creates interesting code.
Fixes open(O_CREAT|O_TRUNC) on at least tmpfs and nfs to not fail
with ENOENT due to a racy removal of the newly created file.
Caught, as most bugs these days are, by a test run.
FUSE filesystem must be patched to #include <perfuse.h> in the source
files that open /dev/fuse and perform the mount(2) system call. The
FUSE filesystem must be linked with -lperfuse.
libperfuse(3) implements the FUSE kernel interface, on which libfuse or
any FUSE filesystem that opens /dev/fuse directly can be used.
For now, an external daemon called perfused(8) is used. This may change
in the future.
acpicpu0 at acpi0 (CPU0)
ACPI: Dynamic OEM Table Load:
Table [SSDT](id 00EB) - 13 Objects with 0 Devices 1 Methods 0 Regions
ACPI: Dynamic OEM Table Load:
: ACPI CPU
Thus, use ACPI_DEBUG_PRINT() instead of ACPI_INFO() when a table is loaded
dynamically.
for an unknown notify. (The ACPI drivers should really not print anything
as we now have a global notify handler that can catch the debug information.)
our SCSIPI driver stack. Currently we pretend to be a single CD
controller with an optional host file as the image, but I guess
the sky's the limit.
dmesg porn:
NetBSD 5.99.39 (RUMP-ROAST) #0: Mon Aug 23 11:38:16 CEST 2010
pooka@pain-rustique.localhost:/usr/allsrc/src/sys/rump/librump/rumpkern
total memory = unlimited (host limit)
timecounter: Timecounters tick every 10.000 msec
timecounter: Timecounter "rumpclk" frequency 100 Hz quality 0
root file system type: rumpfs
mainbus0 (root)
scsitest0 at mainbus0
scsibus0 at scsitest0: 2 targets, 1 lun per target
cd0 at scsibus0 target 1 lun 0: <RUMPHOBO, It's a LIE, 0.00> cdrom removable
check (today it was christos@' laptop), follow Linux and disable this rather
expensive sanity-check for the time being. A hypothesis about the cause of
the failures relates to the absence of cross-CPU coordination in the current
implementation.
will go backwards; K7 will not be supported already due doubts about
availability and reliability of ACPI during that era. Some unfortunate code
duplication is present (but not overly much). Thanks to cegger@ and jakllsch@
for patiently testing this.
