AdoptSystemColors() tints document background color to match panel
color if uneditable.
Calling MakeEditable() will automatically apply or unapply uneditable
background tint if you have previously called AdoptSystemColors().
Parent BView::AdoptSystemColors() sets panel colors, we want document
colors here. Do not alter text color - only view, low and high colors
are changed.
Document AdoptSystemColors() and MakeEditable() in BTextView docs.
Change-Id: Ib215735f27bb01fc2f95fcf2fee0185e5fc83f70
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8263
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>
We don't have many etc and non-etc syscall pairs in this file
(the semaphores seem to be a notable exception), so drop
wait_for_thread and just call wait_for_thread_etc instead.
This breaks syscall ABI, but we've already broken it since beta5
anyway.
This solves some TODOs and allows image_debug_lookup_user_symbol_address
to be dropped entirely. It should also fix reading symbols from binaries
that have multiple TEXT regions, and most functions are not in the first.
* Reorder a few messages, and add base numbers so that messages
can be added in the future to all "sections" without breaking
previous ABI.
* Rename some messages for consistency.
It's been broken since clone_area was changed to block cloning of
areas without B_CLONEABLE_AREA set on them. We here introduce a
B_DEBUG_MESSAGE_CLONE_AREA debug nub message, which clones the areas
of the debugged team for the debugger.
Also fix some bugs in SymbolLookup::_FindLoadedImageAt methods:
they didn't work properly when *next was NULL, so they would
always fail when iterating over the full list.
Note that this technically breaks libdebug.so and the debugger
protocol ABI. However, nothing out-of-tree that I know of uses
the private libdebug.so, and while GDB does use the debugger
protocol, it doesn't actually use any of the messages past
the first block, so it should still work after this.
Fixes #15251.
Change-Id: I71ccbee4afd17dae30d5dacbc7590d1e2175a90e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8821
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This is more efficient and works most of the time. Additionally,
we can potentially join with a previous free chunk in the allocator,
avoiding extra fragmentation on the heap.
app_server (on x86_64) only has 1 "rld heap" area after this change
with a size of 0x50000 (320KB), whereas previously it had around 7
with a total size of 0x80000 (512KB).
The old define was really "check heap integrity", so it's split off.
In the userland test harness, this takes the total time spent in
the allocator from around 1ms to 14ms for all the allocations used
during a boot with "nightly" profile, so it seems acceptable to
enable it under KDEBUG.
Tested with both BIOS and EFI bootloaders, still works.
They were mostly copies of one another, save for the glue code
and a few other things. Now they're mostly unified, and this allows
the test to be greatly simplified, too, since it can avoid including
any bootloader code at all.
The heap implementation itself should have no behavioral changes
from before. Those will come in future commits.
They were hand-rolled singly-linked lists before. This adds 24 bytes
of size to the Team structure, but turns all the removal operations
in parent and process group into O(1) operations instead of O(N) ones.
Realistically, the Thread linked-lists should be converted as well,
but this is trickier due to interdependence on the Team structure.
At present there's only ever one global one, so we don't bother using
an array for multiple screens (and we don't support multiple screens
yet anyway.)
This fixes a very old TODO, and avoids sending a ~32 KB port message
on every application startup.
Note that this breaks the app_server protocol ABI.
We already didn't inherit FDs, which meant that the only thing we
did meaningfully inherit was the table size. That meant that basically
no applications actually had a table size of the default 256, but all
were at the kernel's 4096 (except Tracker and anything started by it,
as Tracker resets it to 512), and also that basically all applications
had FD tables allocated with the raw allocator instead of the block
allocator, which isn't very efficient.
Since this reduces the default FD table size, some applications
might encounter problems. However, build systems and other such
tools should already increase this by default as needed, and it's
easy enough to patch in calls to setrlimit() if it turns out
some applications needed a higher default after all.
Also remove a redundant call to vfs_exec_io_context. Calling
vfs_new_io_context with the second argument set to "true"
already skips cloning CLOEXEC FDs.
Zstd wants a ~90 KB scratch buffer to decompress our 64 KB chunks.
Rather than let it allocate that itself every time, pass in a 2*64KB
"scratch" buffer and statically allocate the working memory from it.
Pass it down using iovecs, and pass down the other buffers in the same
way, to reduce parameters.
Further, rework the object_cache used for heap decompression buffers
to contain objects sized as 4x64KB, so we only need to do one allocation
and deallocation for the compression/decompression and scratch buffers.
Set the minimum reserve to 1 so that the low-memory manager doesn't
reclaim this, as we'll need it when reading back data.
Improves packagefs I/O performance (and thus boot speeds at least a bit,
it appears.)
Change-Id: Id51f6f598b33b9d757a283184c533bb97049529f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8717
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
This adds some new parameters to UnmapPage and UnmapPages. The important
one is a "_flags" pointer to UnmapPage, which if specified will be
filled with the page flags instead of PageUnmapped() being called
(and Flush() won't be invoked, either.)
This removes the remaining PAGE_STATE_* changes from VM architecture code.
Change-Id: Iacbc424dd8a75a79986edcd7f04d15a10f773c87
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8728
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
An extra argument is added to allow the VMAreaMappings objects to
be added to a queue instead of freed directly (and the lock unlocked,
and so on.)
All architectures adjusted.
This means there is now only one place in each TranslationMap that
the page state and other data is directly adjusted (in UnmapArea).
Change-Id: I3ed2d6d969d1b1e235144a1035c90c750779af27
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8716
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: X512 X512 <danger_mail@list.ru>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Nothing uses it, and it isn't correct anyway: vm_page_num_free_pages()
now includes cached pages, too, while vm_available_memory() includes
not just available memory pages but also swap.
All the SIO... codes are in the 8900 range.
Change-Id: I7b319877d2430eba2573a0c8fd68cb7fc3b221d8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8693
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 reverts a8877df135.
Previously, the "unmergeable" flag was necessary for the RAMFS,
because if the last vnode reference was released while there
was still a consumer (as the old ordering of _RemoveConsumer
had), then the release of the cache reference when the vnode
was removed would result in the cache trying to merge with
its now-only consumer and sole referrer.
Now, instead, we remove the consumer before releasing the store
reference, so that there's no chance the cache will be merged
inside this method.
mmap_cut_tests still pass, web browsers using ramfs shared_memory
still seem to work.
Otherwise, platform loaders couldn't make heap allocations inside
platform_start_kernel(), which some loaders (e.g. EFI) do.
Implement calling heap_release() for the BIOS loaders at least.
This gets us back the ~1.5MB of bootloader heap memory there.
Fixes the code I introduced in hrev50114 for custom serial port
baudrates. The idea there was based on FreeBSD implementation, but I
missed a key detail: speed_t in BeOS (and Haiku) is only an 8 bit value.
Note that BeOS does not have c_ispeed and c_ospeed fields, instead they
are named c_ixxxxx and c_oxxxxx with a comment in termios.h saying that
they are not used. So the renaming and moving of these fields isn't a problem.
This means the previous code worked only for speed between 20 and 255
baud, quite the opposite of what I wanted to do, which is to enable
access to fast baudrates.
This new implementation exploits the fact that tcflag_t is 32 bit, but
we never actually use more than 16 bits. Therefore, the high bits of
each value were unused, and can be reclaimed to store the speed,
by changing tcflag_t to 16 bits. The speed is then inserted as two 16
bit values that can be combined as a 32 bit one. The flag bits are not
moved (on little endian systems), and the extra values are guaranteed to
be set to 0 by any previous code that was compiled with 32 bit tcflag_t.
Support for different speeds for input and output is now also possible
(POSIX specifies separate functions for setting the input and output
speeds, which is useful for some old terminals and modems, where it was
useful to have a high baudrate for data to display on the screen, but
things typed on the keyboard aren't quite as fast). If desired, we could
now properly implement this in our serial drivers, but it isn't done
here yet.
Additional changes:
- speed_t is now a 32bit type, allowing to pass large values to
cfset(i,o)speed
- fix some places where a baudrate enum value was incorrectly put in the
c_ispeed and c_ospeed fields, this is not how they were meant to be
used (it meant the default was to use a speed of 0, that means "hangup"
the line, which I think no serial driver really implemented).
- do not put baudrate enumeration values in c_iflag and c_oflag, they
are meant to be used in c_cflag only, and conflict with other bits.
Separate speeds for input and output can be done by setting the
c_cflag value to CBAUD (indicating custom baudrates) and then setting
the values in c_ispeed and c_ospeed.
Fixes #18483
Change-Id: If63a24b5ced5edf6d051d921197db194def0c614
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7068
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Overcommitted caches should only have commitments equal to the
number of pages they actually contain, so we should decommit
whenever pages are discarded.
This changes the API of VMCache::Discard to return an ssize_t
of the size of pages that were discarded (or a negative error on
failure.) Nothing checked the return value besides things in VMCache
itself, it appears; but it apparently never fails, so that's fine.
Also add asserts to Commit() that the new commitment at least
encompasses all pages the cache actually contains.
Follow input_device_type above: we don't have _TYPE or _SUBTYPE on
the end, but _POINTING in the middle, because these aren't in a global
"subtype" enumeration, but a B_POINTING_DEVICE-specific enumeration.
Also don't bother adding the UNKNOWN type to messages that have no
type; if it's not included, UNKNOWN is implied. Saves a few CPU cycles.
Change-Id: I9088b9fcee63bf001b43febbe1e3ac17eb1792b4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8635
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
"Move" now sounds like it has 'move' semantics (i.e. replaces this
structure's data with the other structure's data), while MoveFrom()
really had 'move+append' semantics (appends the other list's elements
to this list, and clears the other list.) To make this clearer, it's
here renamed to "TakeFrom".
This should reduce confusion with the other move-related APIs that
are starting to show up in the Haiku tree (e.g. "MoveFrom" in BRegion.)
Change-Id: Ib0a61a9c12fe8812020efd55a2a0818883883e2a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8634
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: X512 X512 <danger_mail@list.ru>
These were declared in this header on BeOS, so we need to keep
them around for ABI compatibility, but they are nonstandard
and no other C library besides glibc appears to provide them
at all (not even musl, and none of the BSDs.)
* Clarify the fResizeThreshold logic and remove the comment.
* Rename "count" constructor argument to "blockSize", as this is
what it actually does.
No functional change intended.
Change-Id: I993bf0e695f47da181e9fb50b9a964edfd4a0adc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8629
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This reverts commit 1db0961121.
It turns out the comment is not obsolete; what it refers to isn't
PAE systems but true 32-bit ones. I'm not sure we should use
64-bit cache offsets even there, but that's a decision for another
time.
The previous implementation allocated and freed event objects
on every insertion and removal using malloc()/free(). It was also
licensed under a "distributions in binary form must reproduce ...
in the binary" license, which is more restrictive than the MIT license
that we prefer.
So, this is a rewrite from scratch. It uses the standard
DoublyLinkedList<> rather than rolling its own, and manages
a free list of event queue objects rather than hitting malloc()
all the time. It only frees chunks on destruction, though,
but that hopefully won't be an issue anyway.
All tests from the TimedEventQueueTest still pass, and media playback
still works as before.
Change-Id: Ia940b6176f8051ae4823b75acd305ded8783d1e0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8594
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Previously, lower was better, and higher was worse. But really we want
the scores to be based primarily around the index sizes, which can
grow to be very large, so a maximum score is hard to determine.
Instead, start with the index size, and then divide to make it smaller
based on how "useful" the equation terms will be in searching it.
Improves the performance of queries like those in #19080; according
to humdinger's testing, the query with the most expensive term first
went from ~2.0s execution time down to ~0.7s, same as the query with
the least expensive term first.
Change-Id: Id71fa21c95cfe3d8d0019ff356bdf4935446411f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8593
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
