Change-Id: Icc1673b331d9afb3a7b34c91e7b1f20c3dee964a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1871
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Note there are 32bytes on disk for the checksum, but only the first 4
are used. This is because btrfs can (or could, at some point?) use
sha256 instead of crc32 when higher reliability is needed (but high
performance isn't).
Change-Id: I8a2bcf8f462440568d9b3e2d9fbdb7208723bfb9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1596
Reviewed-by: Chế Vũ Gia Hy <ugen@cinnamon.is>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* Improved the "Oh no!" text of the button.
Change-Id: I9b15f3dccca24a5e394d42890985fd42c49f7587
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1925
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
Change-Id: I8a2bcf8f462440568d9b3e2d9fbdb7208723bfb9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1596
Reviewed-by: Chế Vũ Gia Hy <ugen@cinnamon.is>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Change-Id: Iffea088f7234ab7d458ed0cabc4ded0aa50009c2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1617
Reviewed-by: Chế Vũ Gia Hy <ugen@cinnamon.is>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Use the gcc builtin instead, which generates more efficient code (it
saves a function call) and means less platform specific code to write
for us.
Change-Id: I1d55b5703027b2ea4ecde2438ea306bd4850eb32
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1859
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It just deadlocks, so let's try to go without it and hope for the best?
Should fix#14301
Change-Id: I3cbd6e800a64da31f1fb1f1fb66b088e0298596e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1899
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
To help understand the problem in #14276
Change-Id: I334a5cdfa149d335068f2135d13ed729b53fe6ab
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1900
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
As for other devices, N=1 makes no sense because N-2 is eventually
written to the hardware register, so wherever these values come from,
they can't be correct. Replace with the values from the Intel manual.
Also fix confusion as to when the + 2 or - 2 is applied to M1 and M2
values. The documentation says M1+2 and M2+2 are used in frequency
computations, but we instead write M1-2 and M2-2 to the registers, so
the M1 and M2 in our limit structs has an offset of 2 from the docs.
Should fix#13694.
Change-Id: I87157154d22a5e6caf622d71a2f0e0b9ff21a2fa
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1902
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This reinstates commit 2b5ebfcfd5.
According to the POSIX specification, a NULL iov_base means
"do nothing." So we should treat that as such properly,
and not consider it an invalid address.
Fixes#15356.
Change-Id: Ia9438777f1da8ca32f93e0d85229230c809e6711
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1918
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The HAIKU_FIRMWARE_NAME_MAP macro takes a size parameter to define the
firmware map array type, and then a multi-dimensional array literal is
assigned to the array defined by that macro.
This is error-prone. The idualwifi7260 driver, before this patch, had
the size incorrectly set to 6 when the number of entries was 7, which
sliced the last entry off of the map, making it unavailable to the
driver. After fixing this size, the driver properly loads the
iwm-8265-22.ucode firmware on my computer.
This patch changes that macro to take a const char[][2] literal as its
only parameter, making it less likely for this sort of bug to be
re-introduced.
Fixes#15413.
Change-Id: I78a75e692a8637af0f13d1eb16180ce8d95d0852
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1917
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This allows ARM64 to bootstrap for building of GCC.
Signed-off-by: Jaroslaw Pelczar <jarek@jpelczar.com>
Change-Id: Ia2ea34d1fc1a8e4d3c77a7ef05a32a8603a4fb51
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1851
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Change-Id: I3ccb6be54ba3e42136fa7093f35e16aaecc5a540
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1589
Reviewed-by: Chế Vũ Gia Hy <cvghy116@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
We have quite a few GSoC projects around this, it would make sense to
have some documentation for people attempting them.
Add some generic overview of filesystems and how to test them.
Follow up to #15135, which created a regression, apps would crash if
using the port pool before creating a BMediaRoster instance. Now the
port pool is entirely managed by the MediaRosterUndertaker, which is
less confusing.
Fixes the media_addon_server crash on shutdown for me as well, but I
don't remember why (I had studied the code and came to the conclusion
that this should fix it, but I don't remember the reasoning).
Fixes#15263, and regressions for apps using the port pool before they
instanciate the BMediaRoster.
Change-Id: I887dbc590d8ee9de391b6eae0206944bfe99325f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1897
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
