They have been in BeBuild.h since BeOS days, but as this file
is included everywhere in the base system headers, it causes
a bunch of unnecessary POSIX namespace pollution. So, instead,
put them in a config header, and include it from SupportDefs.h,
which should only ever be included by Be/Haiku API headers.
It's a non-standard header we inherited from BeOS. According to the
POSIX specification, size_t should be declared from including stddef.h
and/or sys/types.h, and ssize_t from sys/types.h.
It comes with AVX, so enable it if we've enabled AVX.
This also adjusts altcodepatch_replace to explicitly set NOPs
for the remainder of the patch area.
Change-Id: Ia07549851d86836ff5428635b580c751b4e5b2a3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10867
Reviewed-by: waddlesplash <[email protected]>
Reviewed-by: Jérôme Duval <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Enabled by default, but can be disabled via a new settings window
option (which is saved and remembered across runs.)
Change-Id: Ifd49cd734dcf5e4a5e5b3625d23bc2778fa1fa55
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10850
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Putting all the per-CPU messages in one array means they'll all
be on the same cache lines. The cpu_ent structure is cache-line-aligned,
so this means they'll be on separate cache lines.
TCPEndpoint::_NotifyReader() calls notify(READ, _AvailableData()),
which after a close will be negative, so this will set DISCONNECTED
in that case.
Drop the unnecessary duplication from TCPEndpoint::_HandleReset:
the net_socket layer sends READ|WRITE notifications in this case.
Fixes#19969.
Change-Id: I0e10c0280f3c84276b486b0375000153a117246d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10581
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
* Implement the TODO about needing to place stubs in executable
memory. This fixes basic ltrace operations.
* Place traces behind a TRACE ifdef.
* Get rid of the "patched table" and find the PatchEntry
using fixed offsets, to improve efficiency.
* Add a "bool trace" to PatchEntry. This paves the way for
tracing only specific methods.
Using LD_PRELOAD_ADDONS=...ltrace_stub.so, trace entries are now
printed on x86_64. However, it seems that the trace stub is clobbering
something, as BWindows don't work correctly when traced.
On a 64-bit nightly, it appears we're already using 16 out of the 20
slots for kernel_args ranges. On a 32-bit bootstrap build with symbols
enabled, we exhaust them (due to the network drivers that the bootstrap
build adds to the boot set).
The kernel_args are later freed by the kernel, so this shouldn't "leak"
any memory unnecessarily. With this size, we only need one chunk with
symbol loading disabled.
We never send it to the kernel but always free it. The kernel_args
allocator is very simple and can't handle frees besides the most recent
data, so this avoids "leaking" some kernel_args memory (it should all
be freed by the kernel later, though, so that only matters for
the bootloader itself.)
Nothing uses it (not even DEBUG_PAGE_QUEUE, it appears),
and it will need to be managed a different way for the
multiple ModifiedPageQueues, if we really do need it.
Use strchrnul instead of strchr, and increment at the end of the loop.
This avoids needing to call _ParseExportVariable in two separate places.
The invocation of line.Append(chunk, bytesRead) was also incorrect,
as bytesRead would be past the end of chunk if chunk had been
incremented. But this wasn't really a problem because BString
does strnlen() on the passed arguments.
Inspired by a change seen in a fork of the Haiku repository on
GitHub.
Also drop the long-double files from architectures where long-double
support is (currently) disabled in glibc config.h.
Should fix#19589 and other long-double related problems on
RISC-V and ARM64.
Change-Id: Ia33ce2791d812eb143b719fb61e69dbf8b70ce79
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10815
Reviewed-by: waddlesplash <[email protected]>
Reviewed-by: Sam Roberts <[email protected]>
Otherwise we just spends lots of CPU time sending silence.
This also paves the way for stopping the output when all
outputs disconnect, but that's not implemented just yet.
Since this forces a wait inside the mixer for the destination
to actually start, it may help with problems like #19074.
At least in testing, without that block, I got similar symptoms
and crashes, due to the initial 0 value being used to compute
the performance times, and winding up with very incorrect times.
Note that this changes the MultiAudioNode to not really start its
timesource when it gets a TIMESOURCE_START message. Instead it waits
until it gets a regular B_START (via StartNode) message to do that.
Change-Id: I1716e347537c88dcc76163a515e7fbb8c5ccdecb
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10643
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
This makes for much faster lookups, and avoids the need
to allocate an array.
sizeof(BWindow) is unchanged (on x86_64, 504; on x86, 376)
so this should not break ABI/API.
Quick benchmark in Tracker:
501 lookups, before: ~488 usec
501 lookups, after: ~284 usec
Change-Id: Ica2c728f0c5957380add53e14a826a4aade52df0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10720
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
If the shortcut is not available (due to the menus not being active),
then this will make sure we handle the key regardless. If the shortcut
is active, then it'll get eaten by BWindow, and we won't get here.
Change-Id: Id6c3ae590f596481f9dfb720aa088238ccc6413c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10718
Haiku-Format: Haiku-format Bot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: John Scipione <[email protected]>
This is now a POSIX method which was widely supported even before
its addition to POSIX, so using it here (including on the build
platform) should be OK.
This takes mimeset -F of the whole src/ hierarchy from around 2.8
seconds to around 2.1 (user time goes from ~1.2s to ~0.6s.) It seems
I/O is a lot of the remainder now.
Also drop the TODO comment; we don't want partial matching like that,
as the sniffing rules would not expect it.
All tests still pass.
Change-Id: Ibb190f6f9f5e73ed027e052ef665b177d3fd6f86
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10688
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Another slight optimization. The time doesn't seem to decrease much,
but this paves the way for a much more optimized scan.
Change-Id: I0fb65544524fbc9606fd84ef521b706bd9dc4d02
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10687
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Jérôme Duval <[email protected]>
This will allow them to perform some more upfront optimizations.
Note that this change includes a slight compatibility breakage with
BeOS R5: it applies an "-i" flag in a disjunction to all patterns in
the disjunction, not just all patterns following the "-i" (I checked.)
However, as far as I can see, this feature of R5 was undocumented
(sniff rules are described in the "Release Notes" section of the Be Book
only, and "-i" isn't discussed there), and the only pattern on R5 that
appears to use them at all was the "text/html" pattern. The behavior to
apply case-insensitivity to all patterns seems unexpected, so I think
it should be OK to break compatibility in this slight way.
Change-Id: I0556d53e602bc68ae14ac21c9e226403061043a0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10686
Reviewed-by: Adrien Destugues <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Otherwise, we send them out before the file is actually renamed,
and so we could send notifications with stale name values in them
(in the case of B_ENTRY_CREATED and B_ENTRY_REMOVED), or before
the file's name actually changed as visible in stat(). This way,
we send the notification only after updating the entries.
I noticed when profiling the system with ActivityMonitor running
that most of ActivityMonitor's time was spent initializing these
for the Memory view. So, instead, cache the formatters to avoid
needing to reinitialize them so often.
With the old code, if the currentErrno hadn't changed, but was in
fact re-assigned more recently than the local errno was, then we
would wind up incorrectly return the local value instead of the
system value. This was the cause of the build mimeset not working
properly when run in recursive mode on Haiku.
So, instead, create a wrapper struct to make assignment of the
local errno always pass through to the system one, so they never
get out of sync in the first place.
* Move the logic to build_cross_tools, as some scripts use this
directly.
* Use gnu89 standard instead of disabling specific warnings.
* Reduce optimization level used to compile GCC, to try and stave
off possible bugs.
* Explain why 32-bit is used for GCC 2. (With some hacks,
GCC 2 compiled in 64-bit mode can be used to build an image
that does get to the desktop, though.)
Tested with GCC 14.2.
This avoids an allocation, copy, and deallocation every single
test of every single pattern, which was unbelievably inefficent
and one of the worst performance hits to the MIME sniffer.
Before this change, "mimeset -F src/" in the Haiku repository
took 20-40+ seconds. After this, it takes around 3 seconds.
All tests still pass (and indeed the tests caught some bugs in
the initial version of this change.)
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.)
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 fixes a long-standing TODO, and a major inconsistency
that for different caches, "commitment" reserves from different
pools, so any two aren't necessarily convertible.
The new system introduces a virtual method "TakeCommitmentFrom",
which allows the VM's cut_area routine to behave as it did
previously.
They mostly contained descriptions of functions' operations, not
what they're for, so they weren't so useful. I've added some of
the remarks they had (or ones with a similar purpose) inline
as documentation comments, and deleted the rest.
The documentation file hadn't been updated in a very long time,
and referred to locks and paradigms that have long since been
dropped (e.g. sMappingLock was removed in 2010, in
afed2658f4ef3e3df5ff8390d1d7a51b5b897a9e.)
Add a few "protected by" comments in VMArea to clarify things,
but otherwise this document looks entirely obsolete (I went
through all of it.)
EV_ADD implies ENABLE, so this isn't needed, but a lot of applications
try to specify it anyway. So this extends source compatibility.
If in the future we ever implement EV_DISABLE, we can just add a
real definition for it then, and since ADD implies ENABLE existing
applications shouldn't break.
If the source area is now mapped write-combining, so will the
target area.
May fix some problems or slowness that occurred after the
framebuffers refactor commits.
This allows the guarded heap to be used in a much more targeted way,
if it's suspected specific object_caches have problems.
Enabled by default for KDEBUG. The new safemode/kernel option is
"guarded_heap_for_object_caches". This accepts a comma-separated
list of quoted strings, optionally with * at beginning and/or end
(but not middle.) Examples:
mbufs* # matches caches starting with "mbufs"
*jumbo9* # matches caches containing "jumbo9"
"*jumbo9 chunks","mbufs*" # matches caches ending with "jumbo9 chunks"
# or starting with "mbufs"
This should help with diagnosing #19973, among others, without needing
to compile custom versions of drivers or anything like that.
Unfortunately it is not possible to use this mechanism to selectively
replace parts of the slab malloc. The slab malloc free() relies on
the MemoryManager to figure out what cache an object belongs to, which
doesn't work if objects of some size classes aren't known to the
MemoryManager at all.
Before this commit, swap space was committed entirely orthogonally
from memory commitments. This was not handled at all correctly
when cutting areas (the area cutting logic tries to migrate commitments
between caches, but in the case of swapping caches, it didn't,
and couldn't, take the separate fCommittedSwapSize into account.)
Even without that problem, totally separate swap and memory commitments
caused other problems. For instance, suppose a setup with 4GB of RAM
and 4GB of swap. Many caches are created, and all 4GB of swap gets
reserved, but the caches with this swap reserved have no or few pages
in them. Then, all 4GB of RAM gets used up. The page daemon runs, and
looks for things to swap out, but it can't find anything because all
our swappable caches with pages have no swap reservations, so all it
can do is flush out cached pages, which just degrades performance.
Or, consider what would happen if the 4GB of swap was released, but
the 4GB of RAM was still in use, and then the kernel tried to
allocate memory. It would get OOM errors, because none of the
caches have swap commitments and so nothing can be written out.
Under this new system, the specific swap space reservation only happens
just before the page is first written out, so both these cases should
be handled smoothly, and swap should be used in a much more sensible
fashion overall.
This change seems to be more in line with what other OSes do (Windows
Task Manager's "Committed" clearly is RAM+swap, for instance.)
The only potential downside to this change is that swappable caches
may temporarily go over their commitment when reading or writing
out pages to swap, before the page daemon has a chance to come by
and free the page or the swap space. But as that is a temporary state
and should always be resolved by the page daemon, I think it's
probably an acceptable trade-off.
Change-Id: I928f4b4cacbec26ed6315179476eaff1a7f626c8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10305
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
This begins paving the way for removal of user access to kernel
address space.
After the previous commits, BDirectWindow and BWindowScreen
still function properly.
Part of #19990.
Change-Id: I8477e43cd517ba67383755a4cb60b00bc117f5d7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10559
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
This will be useful in the case of cloned device caches based
around physical memory, e.g. for framebuffers.
Change-Id: If2b864208e86f436e91379b73c4b866b0bd5e1d7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10558
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
It can't work if the framebuffer is mapped per-application.
Instead, use the accelerant hook to get the framebuffer.
The BScreen methods this disables were deprecated and marked
private already, so no Haiku applications should be affected.
(If really necessary they could be reimplemented with BWindowScreen.)
Remove first _GetCardInfo in BWindowScreen; we invoke it
later, closer to where the buffer is actually used.
Tested with ParticlesII (which uses BWindowScreen) on VESA
with the new user-only-mapping accelerant.
Change-Id: I405bcfa8cb1eb2d0c346fafbc6233bef15196134
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10572
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
This paves the way for accelerants to map the framebuffer in
user memory, not kernel memory. It uses the ServerMemoryAllocator
in order to avoid mapping the framebuffer multiple times in
client applications.
While at it, clean up some names.
Tested with DirectWindowStars and GLTeapot, both work.
Change-Id: I4e0c003fae99891044af0a5e6e1d6a4506da6430
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10571
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Instead of the kernel heap being a compile-time parameter, make it
a runtime parameter (if DEBUG_HEAPS is specified, at least; otherwise
we're hardwired to the slab heap as before.)
This is similar to what's done in userland: there LD_PRELOAD and
MALLOC_DEBUG control the heaps, here "kernel_malloc" and then
"guarded_heap_options" kernel settings control the heap.
While at it, apply fixes to the guarded and debug heaps to ensure
a minimum alignment of sizeof(void*), if no specific alignment
is requested.
Tested with a lot of build configurations (DEBUG_HEAPS 0, 1;
DEBUG_HEAPS_DEFAULT slab, guarded; USE_DEBUG_HEAPS_FOR_OBJECT_CACHE
0, 1) and with various parameters specified in the bootloader.
Augustin Cavalier