Anyone I've moved, I didn't see any signs of code contributions
or reviews, tickets, or forum posts in the last year and a half
at least. They may still be around and reachable, but I don't think
that suffices to be a "Haiku maintainer".
I've also moved Alexander up in the list of maintainers; the "Past"
list doesn't seem to count "von" for the alphabetical sort.
There was also one mis-sort in the past list which I've fixed.
Change-Id: If6763372be6a23b24bc0f781243e198d1734a849
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8239
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
We unfortunately have to define its methods in the .cpp and not fully
inline them, because otherwise GCC chokes in some places thinking
that the class can be NULL (where it can't be) and thus generating
overrun -Werrors.
This reduces the size of Node and all subclasses (like UnpackingLeafNode)
by 8 bytes. (Not 16 as with PackageNode, as it doesn't eliminate a
virtual table pointer.)
BReferenceable has a vtable, so it's aligned on sizeof(void*) and thus
has 4 bytes of padding on 64-bit systems. We also had 4 bytes of padding,
and so if we just inline an int32 and add Acquire/Release methods,
then we save 16 bytes (again on 64-bit systems) of object size.
Since this isn't so obvious, add an inline comment explaining the
situation.
This makes sizeof(PackageFile) go from 112 to 96 bytes, and so on.
We don't really need nanosecond resolution here, microseconds will do.
We can thus fit the value into bigtime_t and use the standard converters.
Reduces the size of PackageNode by another 8 bytes on 64-bit,
saving another ~2.5 MB of memory (or so) on my test VM.
Change-Id: I1232aa8aa22fbf84a6a70af0129183f297961f03
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8237
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
BControl adopts parent colors on AttachedToWindow(). Use the
adopted view and high colors for BControl derivatives before
using B_CONTROL or B_PANEL colors.
Affects the following controls:
Spinners
Checkboxes
Radio buttons
Sliders
Text controls
Buttons (get control text color already, don't pass it in.)
Affects control colors in HaikuControlLook and BeControlLook,
FlatControlLook control colors derived from HaikuControlLook.
Do not remove control flag before drawing label, we get the
correct label color now. The fallback colors are only for if
you override AttachedToWindow() on your BControl subclass to
prevent adopting parent colors.
Change-Id: I9357c0287898bff48c695a7869f3b8be108c02ad
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8235
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
We do not always use radio buttons and check boxes on panel color,
use the parent colors instead if you have them. The label is left-
center aligned.
Change-Id: Id5cbd98e8ae88d3a65fb0735d45b2ad19c4afdf9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8233
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
... instead of list view background and panel text foreground.
Document color is appropriate here, this is not a list and we
don't want panel colors. Document color yields same result
as list color using default colors: black on white.
This changes the colors of the inside of the dialog that says:
"The following additional package changes have been made:" and
"The following problems have been encountered. Please select a
solution for each:"
fixes #19068
Change-Id: I5b721ad8703c73aa2da323eb189fa22033d44e5a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8232
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
* this avoid letting the linker defaults to take precedence.
* add common/debuginfo.ld taken from ppc/kernel.ld for debug sections,
extended by me for Dwarf 4/5.
* put the __bss_start symbol in the .bss section.
* add asserts for expected empty sections on x86 or x86_64.
Change-Id: If34433a8d7d82b3f115fe6dbf5881c1f9ea42442
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8229
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
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>
In case the queue operation failed, the entry would stay attached to the
ConditionVariable and eventually trigger an assert when re-added on the
next iteration.
Change-Id: I347b5b1c86a7cabc12a6052f85266ef1c584c415
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8187
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
This is similar to the change in virtio_block of the same name. Checking
the return value of queue_request_v and ensuring that the
ConditionVariableEntry is removed from the ConditionVariable by using a
local one.
Change-Id: I2e8e3304925cbec27a2004c8a26468946db3d46e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8182
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Queueing can fail in which case there is no point in waiting for the
transaction to complete as it will always time out. Instead check the
return value and skip waiting.
This requires the use of a local ConditionVariableEntry or an extra
ConditionVariable::NotifyAll as otherwise the entry is never removed
from the variable. As the creation of the entry is not expensive,
using a local variable seems simpler.
Change-Id: Ie697659a35442d965bc5cf2a636ca41841f9acff
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8181
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
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>
The maximum supported descriptor count is used at least in virtio_block
as the maximum vector count for IO operations. When the indirect entry
count is set lower than the supported one and indirect descriptors are
used, virtio_block can overrun that count as it was given a higher max.
Queuing would then fail and lead to transfers that never complete and
timeout after 10 seconds because the return value was not checked.
This was easily reproducible with lots of disk IO under QEMU where such
indirect descriptors are used with a maximum of 256 while the previous
hardcoded indirect count was just 128.
Change-Id: Id6f87b318e93506b04e65807d627a1cf2e8e39b5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8178
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
* Rename NumBlocks to NumBitmapBlocks, as this is the number
of blocks in the block bitmap, not on the filesystem.
* Rename AllocationGroup::Block(index) to Chunk(index), as it refers
to a "chunk" of 32 bits within the bitmap block. This gives us
one less usage of the term "block" in this file.
* Remove superfluous comment.
No functional change intended.
Change-Id: If736387fcd9963a4a74bb0dde12ede81da5502f3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8185
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The colors in the user usage conditions are
corrected.
Change-Id: I509441f5185ec521053045d2406d901a0644b0c7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8234
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
We never actually remove these (except on destruction) and only
iterate over them sequentially, so just use a singly linked list.
Combined with previous changes, this reduces the size of NodeAttributes
from 64 to 48 bytes (on x86_64).
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.
* PackageData::fVersion is (for now) static const, until such time
as there's a HPKGv3.
* Remove locking from DataAccessor as it was only needed for V1.
We want them for the heap buffers, but the rest will generally only
be used when other packagefs locks are acquired (during mounting
or unmounting of packages), so the depots are just a waste.
* 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>
* This fixes arm64 where disabling caching also disables
unaligned accesses.
* This matches how FreeBSD implements this callback.
Change-Id: Iee081d4ecff05b05c3758502d0cdacfbc56b11d8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8191
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
