The BeBook indicates SetTarget() can return B_OK, B_BAD_VALUE or B_MISMATCHED_VALUES,
which are the result values of the BMessenger constructor.
Change-Id: I30f8aa84d4fb0e065a56555889a6fc3f3882d8c7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10594
Reviewed-by: waddlesplash <[email protected]>
Haiku-Format: Haiku-format Bot <[email protected]>
Tested-by: Commit checker robot <[email protected]>
This is how BeOS does it, and changing it break things.
The regression was in 42df4f9689.
Previously this was broken in d2d239f4c4
and fixed again in de9c53f8f5.
Add a comment explaining that it is done this way for BeOS
compatibility, hopefully this will avoid future regressions.
Fixes#19803.
Change-Id: I03d9f0aa379b2a0c729e1e0a2b148d88c7949376
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10181
Haiku-Format: Haiku-format Bot <[email protected]>
Reviewed-by: nephele nephele <[email protected]>
Reviewed-by: John Scipione <[email protected]>
Tested-by: Commit checker robot <[email protected]>
mingw EDK2 gives us a memory map containing a one-page-long
entry that happens to be TTBR1. Because we were bailing out
in map_range, we couldn't update that page after entering
the kernel
Change-Id: Ie38fc593da268ab2a1f3ca98f3bffce36a6a6964
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10658
Reviewed-by: waddlesplash <[email protected]>
Haiku-Format: Haiku-format Bot <[email protected]>
* SCTLR register definitions made 64-bit
* isb added after writing to SCTLR, to ensure we don't execute
instructions requiring the MMU prior to the MMU being enabled
* GICv2 has per-cpu registers for IRQs < 32, so enabling or
disabling those IRQs needs to be done on all cores
* MMU setup code in kernel and bootloader made per-cpu
* Signiture of arch_smp_boot_other_cpus is now the same on all
architectures, with an addr_t page table
Change-Id: I13bef7ca4efc5504d643833664560a9a6a6a6964
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10649
Reviewed-by: waddlesplash <[email protected]>
Without, grep would do its own file type check, which could clash
with the one done by our own FileIterator, based on MIME type.
Improve a bit overall performance.
Change-Id: Ib0ef814e89b076b93e2e7b215f079cad8137128f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10630
Reviewed-by: nephele nephele <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Add AddPosesCompleted() override in DesktopPoseView.
Better Desktop checking (by use passed in param).
Add an IconAttrChanged() convenience method that checks for icon
attribute changes only. AttrChanged() calls this and then checks
a couple of other attributes.
Change-Id: Id7d399eaea3ca2f97083c93ebfb9157327ae4f0d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10638
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
This means that the Trash icon will no longer appear
on the boot volume, only on Desktop. It's still there
just invisible and should not have been visible.
Change-Id: I1c95b39667af1603d8114b29185a352b047787cb
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10421
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Previously, we would increment the jmp_buf pointer in x0
while storing registers and then pass that adjusted pointer
to __setjmp_save_sigs, which would clobber whatever
happened to be after the jmp_buf
Change-Id: I5c466dbc6aa4fa9c69535ad5a5044af46a6a6964
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10642
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
We use BString in the build platform, so we need it to work
everywhere. Add a fallback for non-Haiku targets (though glibc and
others do have memrchr and so could keep this, if we added some
more logic here.)
This is what other architectures do :)
Previously, we only handled signals after system
calls, which could result in a funny sequence of events:
- Thread gets spawned with spawn_thread
- Thread gets resumed with resume_thread, which sends
SIGNAL_CONTINUE_THREAD
- Thread's very first syscall is a read(), which promptly
gets interrupted by SIGNAL_CONTINUE_THREAD and the thread
has no idea why, and doesn't bother to read() again since
it never expected to receive a signal
^^^ PtyReader fell victim to this and Terminal was broken
Change-Id: I32c4c73be21c60cab97add2bb7052dc56a6a6964
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10608
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
* Ensure some bits in TCR have known values, since the bootloader
might have configured something weird which causes problems for us
(such as configuring a virtual address space that's smaller than
we expect).
* ==NULL check in VMSAv8TranslationMap::UnmapPage was backwards
* Don't receive the number of syscall parameters from userspace. We were
previously reading twice as many arguments as needed when handling
a syscall.
* Save FP/SIMD registers as early as possible, since we can't know when
they might get used
* Reset iframe stack index to 0 upon arch_thread_enter_userspace.
Otherwise, when we exec, we push an iframe and never pop it off
again
Change-Id: I4bc7dcc9303b9103a97226cd7ece4c9b6a6a6964
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10607
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
It turns out PAGE_ACCESS assertions could be tripped in other cases,
e.g. when resizing a cache while pages were being read in. So,
properly unset ACCESS (and just leave 'busy' set) in the places
where pages are read in, and re-enable the check.
Change-Id: I22ac5c8cb432c87613bb85e82703a0c1aeb55d86
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10627
Reviewed-by: waddlesplash <[email protected]>
Since we unlock the cache at various points in this loop,
we need to periodically recheck the size here, as otherwise
we might try to insert pages past the end.
This amends 4f8eaff87f. Re-tested
using the case described in that commit.
Change-Id: Id65e309f986a9b7f3e701d2b99c4f318a4eefbd3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10626
Reviewed-by: waddlesplash <[email protected]>
This allows the VMCache to remove these pages pending the I/O
completion.
Combined with the following commits, confirmed to fix#18390.
Change-Id: I9630a00d70a9d6ac5b36e6de70475a6032390806
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10591
Reviewed-by: waddlesplash <[email protected]>
Previously, busy-writing pages just stayed in the cache until
I/O finished. This wasn't right, as they should've been unmapped
(and removed) immediately, as a TODO in the PageWriteWrapper noted.
Now they are, and they're moved into a queue on the cache pending
the I/O completing.
This paves the way for fixing #18390.
Change-Id: I51778ba1cfc1d26f34dd44f1ee293381be59937f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8627
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Before, it just used a hardcoded Element::link member. Now,
it uses whatever one is specified based on the template
arguments.
No source compatibility breakage intended.
Change-Id: I62128921766df0b705488eb64402f902334f2ed0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10589
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Haiku-Format: Haiku-format Bot <[email protected]>
This prevents a hang when the kernel tries to remap
its own pages later, during a break-before-make on
what appears to be a page containing jump vectors.
(In the exception frame, ELR points there.)
Change-Id: Idd516c73a7702c2995fe914204d587df6fc713fc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10600
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Sam Roberts <[email protected]>
* Prevent bringing Tracker windows to the foreground when moving the mouse
over them with a button held but not actually dragging a file.
* Fix a regression caused by changing window->Dragging() calls to
IsDragging().
Fixes#19683
Change-Id: Ife55885e72d4682b857baf4103d144f49b765693
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10601
Reviewed-by: nephele nephele <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
X512