Same as for the scatter/gather pool. This also changes CCBs
to use condition variables instead of semaphores for completion,
which means they're now C++-only. A few C files still include
<SCSI.h>, but none use CCBs directly, so this works out fine.
A quick check with a compile benchmark didn't show a performance regression.
* add SOCK_NONBLOCK and SOCK_CLOEXEC
* also extends the type parameter on socketpair() and socket()
Change-Id: I73570d5bfb57c2da00c1086149c9f07547ba61ce
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8515
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Always declare FD_SET rather than conditionally. This matches
the behavior of the glibc, musl, FreeBSD headers.
* Simplify comments.
* Leave the custom FD_SETSIZE possibility in place for now. Neither
glibc nor musl permit this, but FreeBSD still does.
* 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>
They were ignored and unused; and in fact can't be made to work
properly since the block_cache always operates on exactly block-sized
buffers, and doesn't have contiguous buffers of multiple blocks
to hand out at all.
No functional change intended.
* Minor tweaks to POSIX sys/param.h for style.
* Don't redefine alignment macros in BSD sys/param.h even conditionally.
And add a few more macros from the real BSD sys/param.h, for convenience.
(Most of these are also declared in musl and glibc's sys/param.h)
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...
This breaks kernel C++ ABI.
This mostly just changes the definition (not the size) of string types,
but in at least one case (daddr_t) it does change the size (from 32-
to 64-bit.)
_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.)
We automatically enable _DEFAULT_SOURCE if _GNU_SOURCE is defined.
Rather than having even more optional methods undefined unless
_GNU_SOURCE manually is, just change all remaining guarts to
use _DEFAULT_SOURCE instead.
Fixes #19095.
Change-Id: I5c7baf40b7fb37913e24279589fc1ae706448a45
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8330
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
The names chosen (e.g. "B_UNCACHED_MEMORY") follow the existing naming
conventions for memory-related constants, of putting the type at the end
of the name: B_KERNEL_BLOCK_ADDRESS, B_FULL_LOCK, B_READ_AREA, etc.
Resolves a very old TODO. No functional change intended.
Change-Id: I31491f6b3abc1e95f915aa302b9f2fb2af14774c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8316
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* 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>
