which was missed due to a sticky tag in my local tree.
pointed by Izumi Tsutsui.
> remove uvm_map_protect from cpu_startup of several ports.
> - they shouldn't be needed with the current fault handler.
> - they causes assertion failure with the recent vm_map implementation.
>
> discussed on tech-kern@. reviewed by Chuck Silvers.
> PR/29179 from Julio M. Merino Vidal.
determine if we are willing to wait for memory to come from the
diskqueuedata (dqd) and bufpool pools. Cleanup the mess related to
code calling rf_CreateDiskQueueData() with different expectations
(and/or blatent disregard) of what might happen if there were
insufficient pool resources.
- they shouldn't be needed with the current fault handler.
- they causes assertion failure with the recent vm_map implementation.
discussed on tech-kern@. reviewed by Chuck Silvers.
PR/29179 from Julio M. Merino Vidal.
the build step. Catches things like binutils which do a bunch of configures
on the build step and lose possibly. Fixes issues from PR#29197 for lex
not being picked up here.
define and use vm_map_set{min,max}() for modifying these values.
remove the {min,max}_offset aliases for these vm_map fields to be more
namespace-friendly. PR 26475.
argument as it is no longer required (but is retained as a no-op for
backward compatibility).
the behaviour is now what is expected and intended:
- when the pkg argument is path (absolute or relative) to a
binary pkg, pkg_info operates on it.
- when no pkg argument is given, or the argument is not a
binary pkg path, pkg_info operates on the installed packages.
`pkg_info foo-1.0.tgz', `pkg_info /path/to/foo-1.0.tgz', etc. now work
correctly when foo-1.0.tgz is in the cwd.
bump PKGTOOLS_VERSION to 20050210.
Will allow INSTALL_TINY to fit back in its designated space.
Since the calling code doesn't allow a snapshot mount to fail, this code
will output a warning and delete any snapshots it finds.
This only happend on rw mounts - snapshots don't seem to be created
when mounting ro.
The whole way the snapshots gets mounted is a PITA anyway, the superblock
'last mounted' time should be used to validate that the fs hasn't been
mounted elsewhere.
which indicates that Task Priority Messages might
be disabled. Not relevant for the kernel for now
(related to interrupt distribution on the APIC bus
afaict), but present on one of my boxes.
Being here, also recognise the future "Vanderpool"
extension.
