* Add kDeleteSelection command alias in Commands.h, keep kDelete.
* Add kMoveSelectionToTrash and use it in place of kMoveToTrash.
- kMoveToTrash in kept in tracker_private.h for use outside.
* Create a new constant kRestoreSelectionFromTrash for Tracker.
- Move kRestoreFromTrash to tracker_private.h
Change-Id: I3cdefe97e8359fb53bacfc3319b046b051c6f7db
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8225
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Previously, there was only platform_init_heap/platform_release_heap,
which allocated a single static heap region for the heap to use,
and any subsequent heap allocations had to go through the standard
platform_allocate_region, which allocates regions visible both
to the bootloader and the kernel.
But as mentioned in previous changes, it isn't always easy to
release regions allocated that way. And besides, some bootloaders
(like EFI) use a completely separate mechanism to allocate
bootloader-local memory, which will never get "leaked" into
the kernel.
So instead, refactor all platforms to instead provide two
new methods: platform_{allocate,free}_heap_region. On EFI
this is easy to implement; on most other platforms we have
logic based more on the old platform_init_heap or allocate_region.
(On the BIOS loader in particular, we can only fully release
the memory if it's the last thing we allocated in the physical
addresses. If the "large allocation" threshhold is lowered
back to 16 KB, then we are unable to do this enough times
that we will run past the end of the 8 MB identity map and
thus fail to boot. But with the larger threshhold, we don't
leak nearly as much, and don't hit the threshhold.)
This should further reduce the amount of bootloader memory
permanently "leaked" into the kernel's used memory, though
on some platforms it may still be nonzero.
Change-Id: I5b2257fc5a425c024f298291f1401a26ea246383
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8440
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Will be used in following commits.
Change-Id: Ica89d28cbf6980aca8dc347dfdcb200a0e637e9a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8442
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
page_num_t is typedef'd to phys_addr_t, so it's 64-bits on 32-bit
platforms with PAE. In fact it's been so since the introduction
of phys_addr_t, so this comment was obsolete from the start...
_BEOS_R5_COMPATIBLE_ was defined in ArchitectureRules while
__HAIKU_BEOS_COMPATIBLE is defined in HaikuConfig.h (which is
in the include path for sys/types, SupportDefs, and other
base headers.)
* This is needed in order to support syscalls and other exceptions
that need to be able to inspect/modify userspace register contents.
Change-Id: I8a638c0c40dd44ed882adad0591ae3bf5493a6b9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8329
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Using the page attribute table to set the memory type on a per page
mapping basis is the more modern and flexible approach to physical
memory type handling compared to using MTRRs.
Most of the needed infrastructure was already in place, as setting the
page table entry attributes was already done for uncachable and
write-back memory types. Using the PAT now also allows to set the last
remaining memory type of write-combining through the PTE flags. The PAT
is configured to have entry 4 mean write-combining and the PAT bit in
the PTE is set to point to that.
When PAT is supported and not disabled, MTRRs are completely ignored
and left as set up by the system firmware, where the basic uncachable
and RAM ranges are supposed to be set up. These configurations are then
overridden by the PTE flags as needed.
Change-Id: I0a74b3fc7d3ba9fa384251290ce41621b69d3a02
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8340
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
We allow requesting an explicit memory type when calling
map_physical_memory but default to the uncached B_MTR_UC when not given.
When called without an explicitly requested memory type, allow
arch_vm_set_memory_type to modify and return an effective memory type.
When an overlapping range already exists, the effective memory type is
set to the one of the existing mapping. If there is an explicit memory
type request that conflicts with an existing range, or if multiple
overlaps with conflicting types would be produced, the mapping is
disallow (and a panic is triggered under KDEBUG).
This effectively detects and panics when conflicting aliases of physical
memory would be created. This is also useful on an MTRR based setup,
as such overlaps cannot be properly represented.
When using the page attribute table (PAT) to set the memory type on a
per page virtual memory mapping basis, this is needed to prevent
aliasing of the same physical memory with different types. As per the
specs, such aliasing is unsupported and may result in undefined
operations that lead to system failure.
The mechanism is extended to the general arch_vm_set_memory_type as such
aliasing prevention also seems to apply to other architectures (at least
on ARM, aliasing is also strongly discouraged).
Change-Id: I7aaf6ea8415e92e74cd1643b67793a6857619eea
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8339
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This reverts commit 0caf23319cb4e9f9c8a2ecd30e133e98a1d2b989.
This change is not safe because changing MAIR may invalidate
early mappings. It's also not clear if it's needed, as e.g.
FreeBSD does not use Device GRE mappings.
Change-Id: I95a904ee928281d44989ce707ed1ac59985a308d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8268
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: Milek7 Milek7 <me@milek7.pl>
This breaks kernel ABI on KDEBUG builds (but not non-KDEBUG builds),
but it does so in order to resolve a long-standing incompatibility
between them: until now, any kernel add-ons built against one which
made use of these lock facilities could not be run on the other;
instead you would get hangs and/or crashes.
After this change, kernel add-ons built with a KDEBUG configuration
should work on a non-KDEBUG kernel, while add-ons built with a
non-KDEBUG configuration will fail to load on a KDEBUG kernel
with unresolved symbols, preventing incorrect and broken operation.
Previously BString::HashValue() had an identical hash to the one
in StringUtils::HashValue(), but now it uses hashdjb2, so this
means Debugger will now use that also.
Tested basic Debugger functionality, seems to still work.
Change-Id: Ia341daa56249967a494df46e6e0a69a74c8b5fe2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8266
Reviewed-by: Rene Gollent <rene@gollent.com>
If we just use the kernel entry time, then the pre-syscall tracing
routine (with a debugger message send) will be counted in the syscall's
runtime.
Makes the output of timing in strace and strace -c much more accurate,
however it won't include the "syscall overhead" (time spent in the
syscall entry routines, etc.) But we already can't account for time
spent in the userland-to-kernel transition, so that should probably
be measured some other way if knowing it is desired.
In fact, on architectures which used the generic syscall dispatcher
(e.g. RISC-V), this is the behavior that already existed. So this just
makes x86 consistent with them.
Change-Id: I8cef6111e478ab49b0584e15575172eea77a8760
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8240
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The DPLL selection registers have changed again somewhere between
Skylake and Tiger Lake. Our code was trying to read/write the Skylake
registers on hardware where they don't exist anymore.
Introduce the new Tiger Lake registers and implement enough of it to get
things working on my machine (but probably only on my machine). Also
add a bit of specialization of DisplayPort which I think was not done
correctly on previous hardware either: for DisplayPort, the link rate is
selected from a handful of allowed frequencies, instead of closely
matching the pixel clock.
Things left TODO:
- Write a proper PLL allocation system to ensure each display gets
assigned its own PLL (unless multiple displays use the same timings).
For now it is hardcoded to what I want on my machine.
- Fix the DisplayPort PLL computation to use the values from Intel
datasheets, not the ones used by my machine which are somehow
different.
- Fix the DisplayPort PLL computation to select one of the several
available frequencies, allowing resolutions higher than Full HD which
require higher clocks.
- Fix DisplayPort link training or whatever must happen after the PLL is
set up, since changing the PLL results in a non-working display and we
don't get it back.
Unfortunately this still isn't enough to bring up both displays to life
at the same time. I think it is not very far, but the secondary display
(as decided by the BIOS) remains off for now even after successfully
setting it all up.
Early testing on other machines is welcome.
Change-Id: I37209bb14f32c99944bdc8ef6eef75e2550e18ed
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7367
Reviewed-by: Alexander von Gluck <alex@terarocket.io>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
On my development VM, there were over 300,000 calls to malloc()
from EntryAttributeHandler::HandleAttribute() alone, which had
the most out of any AttributeHandler, but the others were still
significant (over another 10,000 at least.) On systems with more
packages and more attributes, there would be of course more calls
to malloc().
Since the Handlers are allocated and freed in a "stack"-like
configuration, we can use a simple "bump" allocation strategy
with the AttributeHandlerContext to avoid calling malloc() at all.
In my testing, the most memory that was used appeared to be around
2 KB or so (and the smallest was 216 bytes), so a single slab
should suffice for this.
AttributeHandlerContext seems to be created/destroyed around 530 times
during the boot process on my test machine; allocating and freeing the
allocator's slab page that many times should be negligible (allocations
that large still go through the block allocator.)
Performance-wise, the total time we spend with AttributeHandlerContext
objects "alive" goes from around ~172ms to ~156ms. So, not as much an
improvement as one might hope, but that just goes to show that our
kernel malloc() is pretty efficient. And this change will also keep
short-lived objects off the heap during a period when we are allocating
many long-lived objects, anyway.
Change-Id: I810888434aad788511f2af30143335009b34ee78
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8230
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
A basic bump allocator that can handle arbitrary amounts of allocations,
so long as all are allocated and freed in a "stack"-like manner.
(Actually it could be extended to support non-stack-like operation,
but that would require more logic that isn't needed at the moment.)
Change-Id: I47077146ea282600130778d312f7d86bd8c032e0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8238
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Michael Lotz <mmlr@mlotz.ch>
Ensure that allocated queues can hold the amount of descriptors that
were previously communicated to DMAResources in virtio_block and
virtio_scsi. The queue allocations will now fail with B_BUFFER_OVERFLOW
if the requested size cannot be provided.
When requestedSizes are set to 0, no requirement is placed and the queue
is sized to its advertised maximum. The requestedSizes argument can be
NULL which implies all 0.
Change-Id: Ifb1e032d48f8c07aedfe2bf941f32783842c8c12
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8220
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
This can be used to replace mutex_trylock/mutex_unlock pairs. Once the
locker has been created, the success of the locking attempt needs to be
checked via locker.IsLocked().
Change-Id: Iba4b4ce21cac5059a3577a84a6eebe28d2cc4058
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8179
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
So that it has the same naming as DoublyLinkedList.
No functional change. It seems there aren't any users
of this API in the default build at the moment.
* This is the closest thing ARM has the semantics of write-combining
MTR on x86.
Change-Id: I12a1582e0af871e2ab729262e90695ffe928c85b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8223
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Implemented using __builtin_clz where available, otherwise using
an algorithm derived from "Bit Twiddling Hacks" which is similar
to the one ramfs uses. GCC and Clang seem to unroll the loop on
x86 at least (but it doesn't matter there as the builtin exists,
implemented using the "bsr" instruction.)
These are architecture-specific routines, so they deserve proper
architecture-specific naming. The user memory access routines are
already under arch_cpu (arch_cpu_user_memcpy, etc.), and the methods
usually change a CPU flag, so it makes sense to put these there too.
RISC-V had get_ac but nothing else defined or used it, so it's removed.
No functional change intended.
Change-Id: Id4715214e32f73d4a93bc7ba8249411a0878d174
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8106
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: X512 X512 <danger_mail@list.ru>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
So we need to check that it didn't when creating areas.
Change-Id: I4342463113046b543722faa7a51ca269ed67e8bf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8137
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Enhance the warning message and return a more relevant error code.
Fixes #19017.
Change-Id: I13d01ce206a27e5c9a35debc8081219422bfb10a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8136
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
- This key code is inherited from BeOS, where it was used for the power
key on Apple ADB keyboards
- Since then, we have introduced a new system for "multimedia" keys,
that uses HID key codes directly instead of defining our own mappings
- The PS2 driver was using the HID keycode, but the USB driver was still
using the BeOS defined one
- Japanese keyboards, which have a few more keys than US and European
ones, reused the same keycode for something else
Since the power key does not need to be mapped by the keymap, move it
out of the way by using the HID keycode (key codes larger than 0x7f
cannot be mapped to UTF8 symbols). Remove all mentions of the use of
0x6b as a keycode for the power key, but add a note in the documentation
that BeOS did this.
To avoid further confusions, complete the documentation of extra
keycodes, and remove some definitions from keyboard_mouse_driver.h that
should have been in InterfaceDefs.h.
While researching this, I also found that some keys specific to Korean
keyboards were declared in the wrong place, as mapped codes instead of
unmapped ones (checked that by looking at the HID driver, which emits
these raw keycodes, and confirming that the mapped ones are not used in
any keymaps. Also added a note about the mapping of the extra modifier
keys in Japanese keyboards, which I think may be a problem since these
map to invalid UTF-8 byte sequences, but this is what the existing
keymap does, so leaving it as is for now until we can determine if this
can be changed or if we have to keep it that way.
Change-Id: I6a198a0840cba7739bdc78e0c65e5d8fd23956c9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8047
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
According to the ARMv7 Reference Manual, "Wait for Interrupt" is supported only through the WFI instruction on ARMv7.
The currently used ARMv6 equivalent may not work on ARMv7 and newer CPUs.
Fixes #18520
Change-Id: I69a136870654be33c0c789004e08bf610db3dd97
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8044
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
ramfs needs to create caches that are both temporary and unmergeable,
so add another flag to make this state possible.
Otherwise, mmap'ed files from ramfs might wind up in VMCache
trying to merge the caches when the last one is closed, which
we don't want.
The IORequest internally likes to deal with transferEndOffset
not transferredBytes because of sub-requests potentially being
prepared all at once (in some paths in the I/O scheduler),
thus fTransferSize can get incremented in Advance() before we have
actually executed that transfer.
But external consumers much prefer just knowing transferredBytes
not transferEndOffset. And many of them actually named their
variables that (or "bytesTransferred") and just passed the
transferEndOffset through to variables with that name! That's
obviously wrong, and it's surprising it wasn't discovered before now.
The problem was uncovered by repeated KDLs in PrecacheIO.
That method used the "bytesTransferred" value as a count of
pages transferred, which would then run past the end of the array
if the transfer start offset was not 0 (which the majority
of the time it would be, since this method gets called on
the first mmap() of a file, probably before any pages are read in.)
Most other consumers of this API did not check the value, it seems,
or otherwise had some mitigating factor that prevented it from
causing more problems. An exception is the page code, which
may have spuriously considered writes as successful when they
really weren't.
May fix some of the "invalid concurrent access to page" KDLs.
We can't allow applications to reference/unreference cursors,
this is a safety/security violation, and it being done improperly
lead to the reference counts becoming incorrect on the app_server
side.
Change AS_REFERENCE_CURSOR to AS_CLONE_CURSOR and adjust the Cursor
code appropriately. (In the future, copying BCursor without Clone'ing
the data in the case of custom cursors could be accomplished with
client-side reference counting.)
Then rework CursorManager to remove cursors at once on team deletion,
and otherwise clean up cursor reference management to let the
reference counting handle things.
