* Avoid showing read-only volumes as possible installation targets.
* Mark the menu item for the first suitable volume that was found.
* Removed no more needed debug output.
Fixes#5231. Thanks a lot!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36596 a95241bf-73f2-0310-859d-f6bbb57e9c96
I took the conservative approach and the penalty is really minimal if even not at all perceptible as i've measured. I decided to go this way as PoseView code is very fragile and depends on many of those "loose assertions" to be valid. This conservative approach also allows to confidently include the fix in alpha2:
+alphabranch
Besides those "wise" reasons, the thing is that i've wasted too many hours already this week and in the past due that VSPoseList/PoseList syncing fragility. I'm not willing to fix the optimisation of a broken design that i've already experimentally rewriten two times already, and that i (or any mentally sane person) will finally ditch sooner or later :)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36592 a95241bf-73f2-0310-859d-f6bbb57e9c96
Since we also force uncacheability via the PTEs, it is no longer necessary to
use MTRRs for uncacheable ranges. It is recommended, which is why we still do
it, if possible, but when we run out of MTRRs, the algorithm ignores
uncacheable ranges now -- iteratively it increases the minimum size of ranges
to drop until the available MTRRs suffice.
Should fix#5703 and #5865.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36591 a95241bf-73f2-0310-859d-f6bbb57e9c96
memory. This avoids implementation defined behavior on Pentium Pro/II when
intersecting with an write-combining or write-protected MTRR range.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36589 a95241bf-73f2-0310-859d-f6bbb57e9c96
* DefaultManager: added a lock around rescan thread start and exit:
this should fix the possible race condition spotted by Ingo.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36588 a95241bf-73f2-0310-859d-f6bbb57e9c96
as described in the BeBook when oneLevelOnly is false - only
BListView::SortItems() does ignore the hierarchy. So the work-arounds for
this are completely unnecessary. Removed now unused compare_list_items().
* The BOutlineListView sorting methods have a different comparison signature
as the other comparison functions: they point to the items directly. The
compare_typed_list_items() function did not take this into account, and
dereferenced them anyway, leading to #5883.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36587 a95241bf-73f2-0310-859d-f6bbb57e9c96
way.
* Use that newly exposed feature of taking the focus window to the new workspace
when using the Ctrl-Alt-Shift-Arrow shortcut.
* This fixes#5675.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36585 a95241bf-73f2-0310-859d-f6bbb57e9c96
PAT support (i.e. uncacheable, write-through, and write-back). Has pretty
much no effect ATM, as the MTRRs restrict the types to what is actually
requested.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36583 a95241bf-73f2-0310-859d-f6bbb57e9c96
implemented for any architecture yet.
* vm_set_area_memory_type(): Call VMTranslationMap::ProtectArea() to change the
memory type for the already mapped pages.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36574 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Don't set the VMArea's memory type in arch_vm_set_memory_type(), but let the
callers do that.
* vm_set_area_memory_type(): Does nothing, if the memory type doesn't change.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36573 a95241bf-73f2-0310-859d-f6bbb57e9c96
of consistency.
* Moved the B_OVERCOMMITTING_AREA flag from B_KERNEL_AREA_FLAGS to
B_USER_AREA_FLAGS, since we really allow it to be passed from userland.
* Most VM syscalls check the provided protection against B_USER_AREA_FLAGS
instead of B_USER_PROTECTION, now. This way they allow for
B_OVERCOMMITTING_AREA as well.
* _user_map_file(), _user_set_memory_protection(): Check the protection like
the other syscalls do and use fix_protection() instead of doing that
manually.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36572 a95241bf-73f2-0310-859d-f6bbb57e9c96
WebPositive. Gopher URL type remains the only one to refer Firefox.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36568 a95241bf-73f2-0310-859d-f6bbb57e9c96
* InitiateDrag() now makes sure that either a number of top-level items
or a group of subitems sharing the parent is being dragged - anything
else doesn't really make sense and results in mayhem and/or crashes
* LocaleWindow now tries harder to keep the language listview sorted
* when moving around items between the two listviews, they are no longer
copied (and partly leaked), but the same items are now just moved over
* cleanup here and there
This is still somewhat of a mess - I recommend splitting the two listviews at least (as they actually behave differently) - maybe it would be better to pick the available languages from a popup-menu instead of keeping them in a listview?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36561 a95241bf-73f2-0310-859d-f6bbb57e9c96
continuing to run. This must not happen since the thread is the boot CPU's
idle thread performing the early kernel initialization (before the scheduler
is started).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36560 a95241bf-73f2-0310-859d-f6bbb57e9c96
fixes the problem that the CPU initiating the call could make the next call
and reset sCpuRendezvous2 before the other CPUs have returned from their
smp_cpu_rendezvous(). Probably virtually impossible on real hardware, but I
could almost reliably reproduce it with qemu -smp 2 (would hang the late boot
process without ability to enter KDL).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36559 a95241bf-73f2-0310-859d-f6bbb57e9c96
boot CPU wait until all other CPUs are ready to wait. This solves a
theoretical problem in main(): The boot CPU could run fully through the early
initialization and reset sCpuRendezvous2 before the other CPUs left
smp_cpu_rendezvous(). It's very unlikely on real hardware that the non-boot
CPUs are so much slower, but it might be a concern in emulation.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36558 a95241bf-73f2-0310-859d-f6bbb57e9c96
for bezilla's and NetSurf's source archives, instead of defining a local
variable (as installoptionalpackage didn't like it). No functional change.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36557 a95241bf-73f2-0310-859d-f6bbb57e9c96
kernel from committing memory for all read-only segments until we're done
relocating. This allows Haiku to boot on machines with less RAM and swap
disabled. At least in qemu I could boot with 100 MB and start WebPositive.
Probably fixed#5822.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36552 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Commit(): Unreserve memory when asked to shrink the commitment.
* Fault(): The whole logic is flawed, since this is always called by
vm_soft_fault(), even, if the page is finally mapped from a lower cache.
Now we do at least limit our commitment to (page_count + 1) * B_PAGE_SIZE
instead of always reserving memory for another page.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36551 a95241bf-73f2-0310-859d-f6bbb57e9c96
maps. The new cache will be created in over-committing mode.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36550 a95241bf-73f2-0310-859d-f6bbb57e9c96
component of a 32 bit color is below 128 and returns the special CMAP8 index
for indicating transparency.
* Changed the WriteCMAP() color conversion function to expext a 32bit RGBA
value and use IndexForRGBA32().
* Adapted B_CMAP8 target color space case of ConvertBits() to the new
semantics.
This allows transparency in bitmaps when converting B_RGBA32 bitmaps to
B_CMAP8, tested only for this case and working as expected.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36549 a95241bf-73f2-0310-859d-f6bbb57e9c96
