Utilize user_memcpy and IS_USER_ADDRESS when necessary to prevent SMAP violations.
Also add a "wacom_device_header" struct to more easily share data between the wacom
kernel driver and input_server addon.
Should fix#14589
Change-Id: Ie2784020b21523f82fd450a2db2de60ccf9d6620
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2783
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* This allows file systems to retrieve the actual error code on a
failure, and report it to the user.
* All affected file systems have been adjusted to the API change.
This is a binary incompatible change.
Change-Id: Id73392aaf9c6cb7d643ff9adcb8bf80f3037874c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2913
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
xsave or xsavec are supported.
breaks vregs compatibility.
change the thread structure object cache alignment to 64
the xsave fpu_state size isn't defined, it is for instance 832 here, thus I picked 1024.
Change-Id: I4a0cab0bc42c1d37f24dcafb8259f8ff24a330d2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2849
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Otherwise it clashes with the implementation in OpenSSL which uses the
same names but now has a different ABI.
Change-Id: I5cb3ff97d7b28de978cdcbd8a06f25f65fb53784
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2854
Reviewed-by: Kyle Ambroff-Kao <kyle@ambroffkao.com>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
The code to parse the resource table reads one entry at a time because
the table size isn't known. This resulted in a lot of read syscalls,
each reading just 12 bytes. Use a BBufferIO to buffer these and reduce
the number of syscalls. This helps especially when there are lot of
resources, for example in libbe with all the country flags.
It also removes some spam from strace output for all these read calls.
Change-Id: Ib165a0eacc2bc5f3d319c22c2fac4f439efbdef2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2858
Reviewed-by: Rene Gollent <rene@gollent.com>
The goal here is to avoid potentially expensive fork()ing.
The time for a fork() is (for a process with no real heap usage
and thus few areas) 300-400us on my system. load_image() takes
3000us (3ms) or so, but this of course includes exec() time.
Overall, for compiling HaikuDepot (with a tweaked jam to use
posix_spawn on Haiku, not just on Linux) there is a slight
decrease in time:
before:
real 1m21.727s
user 1m2.131s
sys 0m43.029s
after:
real 1m19.472s
user 1m1.752s
sys 0m41.740s
Which is probably within the realm of "noise", so more benchmarks
are needed. Likely if we tweak our jam usage to not need as many
shells when running commands, this would be a much more noticeable
change.
Change-Id: I217f2476b1ed9aa18322b3c2bc8986571d89549a
It iterates over all areas intersecting a given address range and
removes the need for manually skipping uninteresting initial areas. It
uses VMAddressSpace::FindClosestArea() to efficiently find the starting
area.
This speeds up the two iterations in unmap_address_range and one in
wait_if_address_range_is_wired and resolves a TODO in the latter hinting
at such a solution.
Change-Id: Iba1d39942db4e4b27e17706be194496f9d4279ed
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2841
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This introduces VMAddressSpace::FindClosestArea() that can be used to
find the closest area to a given address in either direction. This is
now trivial and efficient since both kernel and user address spaces use
a binary search tree.
Using FindClosestArea() getting multiple area infos is sped up
dramatically as it removes the need for a linear search from the first
area to the one given in the cookie on each successive invocation.
Change-Id: I227da87d915f6f3d3ef88bfeb6be5d4c97c3baaa
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2840
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
They return the left and right most nodes of the entire tree, i.e.
starting from the root node.
Change-Id: I651a9db6d12308aef4c2ed71484958428e58c9bc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2838
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This reverts parts of hrev52546 that removed the B_KERNEL_AREA
protection flag and replaced it with an address space comparison.
Checking for areas in the kernel address space inside a user address
space does not work, as areas can only ever belong to one address space.
This rendered these checks ineffective and allowed to unmap, delete or
resize kernel managed areas from their respective userland teams.
That protection was meant to be applied to the team user data area which
was introduced to reduce the kernel to userland overhead by directly
sharing some data between the two. It was intended to be set up in such
a manner that this is safe on the kernel side and the B_KERNEL_AREA flag
was introduced specifically for this purpose.
Incidentally the actual application of the B_KERNEL_AREA flag on the
team user data area was apparently forgotten in the original commit.
The absence of that protection allowed applications to induce KDLs by
modifying the user area and generating a signal for example.
This change restores the B_KERNEL_AREA flag and also applies it to the
team user data area.
Change-Id: I993bb1cf7c6ae10085100db7df7cc23fe66f4edd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2836
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The code in the Resize and Rebase methods was identical except for the
iterator.
Change-Id: I9f6b3c2c09af0c26778215bd627fed030c4d46f1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2835
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This allows switching from another recursive_lock, mutex or read-locked
rw_lock analogous to the switching possibilities already in mutex.
With this, recursive_locks can be used in more complex situations where
previously only mutexes would work.
Also add debugger command to dump a recursive_lock.
Change-Id: Ibeeae1b42c543d925dec61a3b257e1f3df7f8934
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2834
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The memory map may be unordered and include overlapping ranges. To make
sure that nothing gets included as usable that should actually be
excluded, first scan for all usable ranges and add them, then remove
anything unusable from these ranges again.
To calculate the amount of unusable memory, count the total after the
first pass and then subtract the total after the second. This way, only
unusable ranges that actually overlap physical memory (and therefore
reduce the amount of usable memory) get excluded.
Note that the explicit ignore of the ACPI reclaim memory is subsumed by
the above. We still don't want to add this region to the usable memory
map, as that would allow the kernel to allocate pages into that region,
possibly corrupting ACPI tables before they were used. We also don't
want to add it as an allocated range, as it is not guaranteed that ACPI
is done with the tables before the unused bootloader ranges are freed in
the kernel.
Also add the missing unusable memory amount from ignoring the first MiB
of memory in the EFI loader.
May fix#16056 although it is not certain that graphics memory ranges
are actually included in the memory map.
Change-Id: Ie7991d2c4dcd988edac2995b3a7efc509fa0f4a3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2814
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
APE reader was using a GPL licensed version of MD5. A similar
implementation in the public domain was available in libnetapi, which I
moved to libshared so the APE reader can use it (and made some fixes,
missing const mainly). It only needs a small wrapper to use it easily
from C++ in a way compatible with the previous implementation.
Part of #13814.
I forgot to change MUTEX_INITIALIZER following removal of the
unused field.
Change-Id: I011c023ae00bb4576c8bcecf83546892fef3a77e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2719
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
As far as I can tell, there is no reason to ignore unlocks, ever;
if no threads are waiting, then mutex_unlock() will act appropriately.
So all we need to do is increment the lock's count here,
as we are relinquishing our request for locking.
On the other hand, if we did not find our structure in the lock,
that means we own the lock; so to return with an error from here
without changing the count would result in a deadlock, as the lock
would then be ours, despite our error code implying otherwise.
Additionally, take care of part of the case where we have woken up
by mutex_destroy(), by setting thread to NULL and checking for it
in that case. There is still a race here, however.
May fix#16044, as it appears there is a case where ACPICA
calls this with a timeout of 0 (we should make this be
a mutex_trylock, anyway.)
Change-Id: I98215df218514c70ac1922bc3a6f10e01087e44b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2716
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This is required for BMenuBar based toolbars.
Fixes#15785.
Change-Id: I8d108694b481e408e5c56e23a697c8e7829343dc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2316
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
It is used by several of the filesystems, so it seems a good idea to
move it to the shared/ directory.
UFS2, BFS, XFS, EXT2 and EXFAT are adjusted.
Change-Id: I493e37a1e7d3ae24251469f82befd985a3c1dbdd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2489
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
For historical reasons, the package kit has an "url" field that is not
actually meant to be used as an URL. Rename it in the API and user
facing output as "identifier" to make it clear what the file is used
for. This change preserves the "url" key in on-disk and online storage
(hpkr files, stored settings, etc) in an attempt to not break anything.
Fix one remaining misuse of the "url" field as an URL in
get_package_dependencies.
Add an unit test showing that BUrl does parse "tab" URIs properly (there
is just a protocol and a path segment).
Change-Id: I339ce526e5798d42d78ae650855d7e988dbb4a1a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2542
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
We attempted to make it a 32bit char type, but that is actually not allowed
unless we also make uint_least16_t a 32bit type. And even then, we
wouldn't be allowed to store or handle values wider than 16bit.
Comply more closely to the standard. As a result, mbtoc16r is not
implemented. c16rtomb is implemented by casting the char to 32bit, which
isn't really correct either (I think you're supposed to be able to feed
the two halves of a > 16bit codepoint in two separate calls and get a
meaningful result out?)
Related to #15990 but we may want an actual implementation?
Change-Id: If8198675c27dd2aa412bc44d12d3df4e31d3e8c7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2623
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This reverts hrev54120 and instead adds the commonly supported
MAP_NORESERVE flag to request overcommit.
Using PROT_NONE for overcommit is problematic as the protection of
individual pages can still be changed via mprotect to make them
accessible, but that won't change the commitment. An application
using such a pattern may then unexpectedly run into out of memory
conditions on random writes into the address space.
With MAP_NORESERVE the overcommit can explicitly be requested by
applications that want to reserve address space without producing
memory pressure.
Change-Id: Id213d2245c5e23103e8e0857f7902e0cd8a2c65d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2611
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Rename MovePageRange to Adopt and group it with Resize/Rebase as it
covers the third, middle cut case.
Implement VMAnonymousCache::Adopt() to actually adopt swap pages. This
has to recreate swap blocks instead of taking them over from the source
cache as the cut offset or base offset between the caches may not be
swap block aligned. This means that adoption may fail due to memory
shortage in allocating the swap blocks.
For the middle cut case it is therefore now possible to have the adopt
fail in which case the previous cache restore logic is applied. Since
the readoption of the pages from the second cache can fail for the same
reason, there is a slight chance that we can't restore and lose pages.
For now, just panic in such a case and add a TODO to free memory and
retry.
Change-Id: I9a661f00c8f03bbbea2fe6dee90371c68d7951e6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2588
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Adds VMCache::MovePageRange() and VMCache::Rebase() to facilitate
this.
Applied on top of hrev45098 and rebased with the hrev45564 page_num_t to
off_t change included.
Change-Id: Ie61bf43696783e3376fb4144ddced3781aa092ba
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2581
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
- Use gcc builtin
- Define as a static inline function in the .h so no function call overhead is needed
- Keep the function in libroot for backwards compatibility
- Remove a duplicate implementation in the freebsd compatibility layer
gcc2 does not document the builtin, but it is in fact already available
there as well.
Fixes#3281.
Change-Id: I94f8a2548637aa70e85febbfab06f07c1a427005
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2605
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This code comes from an old Be Newsletter and since then the API
received the addition of SetMouseEventMask. In several places the
MouseDownThread was misused: it would spawn a new thread on every mouse
click and not clear the previous one. This could for example lead to
BSpinner skipping values if you clicked it at the right speed.
There are functional changes in BSpinner, before it updated for the
first time 100ms after mouse down, and then as you moved the mouse
around the button, now it activates immediately on first click and then
every 200ms (which may be a bit short). In other places, no functional
changes intended.
Change-Id: Ie600dc68cbb87d1e237633953e5189918bf36575
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2599
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Also remove the MINGW support, as it was far too incomplete.
This *should* work under case-sensitive NTFS, but instead,
it seems #14963 occurs. So perhaps there is a GCC bug
related to case-sensitive vs. case-insensitivity after all.
It was not specified as such before C11, but that's only because there
was no C standard way to do it until then.
Fixes#15955.
Change-Id: Ied7b7fd94988ed7724460917aebc859b74eaa585
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2558
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
add a WMI Asus driver, to control keyboard backlight brightness.
Change-Id: Ib86f70b4a407178b0a1f532269387a55915cc460
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2485
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This allows to use FileDescriptorCloser as unique pointer for file descriptor.
Change-Id: I4c768fafba6ed35658b2fdb075b9b547f53bc8da
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2495
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
The code in input_server was pretty much all set for this, but there was
no way to configure the extra buttons. Add them to the mouse view in
Input preferences (up to 5 buttons are handled now)
Define a new B_MOUSE_BUTTON(n) macro to generate the bitmask for a given
button (numbered from 1).
Change-Id: I9091082277937d89b08464ff474e7bbb5db82401
Reviewed-on: https://review.haiku-os.org/c/haiku/+/180
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
BeOS didn't support transparent views. As documented in the Be Book,
SetViewColor(B_TRANSPARENT_COLOR) only effect is to not fill the
invalidated areas with the view color before calling Draw() (it avoids
flickering, especially when combined with B_FULL_UPDATE_ON_RESIZE).
A previous change made B_TRANSPARENT_COLOR actually make the view
transparent (that is, additionally to the above, the underlying view is
drawn before the transparent children), but it creates compatibility
issues.
In order to keep the API compatible with BeOS, the new behavior is now
enabled explicitly using the B_TRANSPARENT_VIEW flag. This also opens
for future developments like allowing a view color with an alpha
channel (not supported yet).
Adjust programs that require transparent views.
Fixes#15744, #15745.
Helps with #15645.
Change-Id: I529574ea23db0a23579521b263bc8d572775e35a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2275
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Scroll bars should look and work identically to before on
HaikuControlLook.
Add DrawScrollBarButton() and DrawScrollBarThumb() and
DrawScrollBarBorder() methods. These methods are used to draw scroll
bars in a generic way so that they can be drawn differently by alternative
control look's (e.g. BeControlLook). Also it gives us back drawing of
scroll bar knobs. However the knob setting is not exposed in the
interface in this commit.
These methods are in addition to the 2 existing DrawScrollBarBackground()
methods that draw the scroll bar background. One draws the area above and
below the thumb and the other is called by the first to actually draw the
area.
The rest of the drawing besides the backgrounds was being done in
BScrollBar before. To draw the scroll bar arrows and thumb we were recyling
other ControlLook methods, while this worked well enough on HaikuControlLook
it wasn't flexible enough for alternative control looks.
DrawScrollBarButton() is used to draw the four scroll buttons and is
typically (so far) used in combination with DrawArrowShape().
DrawScrollBarThumb() draws the scroll bar thumb.
DrawScrollBarBorder() draws a 1px border around the entire scroll bar,
potentially B_KEYBOARD_NAVIGATION_COLOR if focused (although this is
feature not currently used.)
Draw unscrollable scroll bars as if they were disabled including the
buttons with their arrow shapes, background, and thumb.
Add FBC backwords compatibility macros in ControlLook.cpp
Change-Id: I9237c5ce45d17d674785111d51de951e5686306b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/351
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
type is acpi_handle, to be used with the ACPI bus manager
Change-Id: Ibbdd81a21bdd57fc651f7a7238e3676033204857
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2456
Reviewed-by: Rene Gollent <rene@gollent.com>
ACPI_DEVICE_HID_ITEM is now optional, instead of an empty string.
Change-Id: I352ffaaad377659f650a0b8c0d56e40a68b739c3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2420
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
to find a node in the hierarchy.
Change-Id: Iee858f21ce134569bf25fccbef9fe18ea8787e9d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2419
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
That's a bad idea. The drag and drop tracking could get confused enough
to crash app_server (possibly because of calling InitiateDrag multiple
times?)
Fixes#14983.
Change-Id: Id43bfcbfc24b1adb8f6e9fff587c6df9b62910f2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2413
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Previous version of the patch was broken by the EFI refactoring.
Change-Id: I6dd125100b22b2461c531bfd8f81b3dd28e2b751
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2409
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
- Cleanup HEAD_MODE constants. These should be completely removed, now
that we have a proper notion of pipes and displays. But the DPMS code
still uses them, for now.
- Fix the ie_pipe command where width and height were swapped and
missing a +1 to show the actual videomode values
change int types to uint32, as it's more correct.
Change-Id: Iae7043abe4c8b8a121548fe6d6a809f1bd879c8a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2334
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
We need to assign PLLs to pipes and transcoders. The assignments on
previous generations were fixed, but now it's up to us to set it up.
Do the simplest thing for now: assign PLL1 to pipe A and PLL2 to pipe B.
Not used by anything at all, and not included in the build.
Even the BeOS engineer who created it wrote in a Be Newsletter
that he was uncertain how useful it was, which is why BeOS
did not ship it as a kernel add-on...
It is no longer an error to destroy a ConditionVariableEntry
that is still attached to a ConditionVariable; it will
now be implicitly detached in that case.
This makes ConditionVariableEntrys much eaiser to use
from an API standpoint.
Change-Id: I03c676d3a198aa885de733d3e1729b15f80de031
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2301
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
There is no good reason to put them in a private header.
No functional change (but drivers now have access
to these constants.)
Change-Id: I7ac00a120ab44fbc110bc858dfd87d69d0061135
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2294
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: John Scipione <jscipione@gmail.com>
Change-Id: I0d6d2f8db2bc86c08d5ba2648f1cf46d85b54a5e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2267
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* arm efi additions
* cleanup some cpu headers which were oddly
split between efi and bios_ia32
* Move calculate_cpu_conversion_factor over to
arch_timer since it is timerish, and x86 only
* Drop some duplicated code from efi start. Move
hpet init code into efi timer/hpet code
Change-Id: Ia4264a5690ba8c09417b06788febc4f572f111ce
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2259
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* This is the bulk of the work. Anything else should be
minor cleanups and tweaking.
* riscv64 isn't a viable EFI platform yet.. just acting
as a stand-in to test a non-x86 EFI haiku_loader
Change-Id: Ib03de81e2b562e693987b86d7b4318209fb1c792
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2256
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
On modern x86, one can use __rdtscp to get the current cpu in userland.
Change-Id: I1767e379606230a75e4622637c7a5aed9cdf9ab0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2248
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
hrev53379 clears the buffer cache for disconnected clients, and also delete buffers.
This is too early (see #15263, media_addon_server crash), and should only happen
after the buffer is recycled. This can be resolved by abusing the fFlags field of
BBuffer to mark the buffer for deletion, and mark the buffer to be reclaimed.
Some BBuffers don't reside in the SharedBufferList, so we have to mark them as to
be reclaimed. For those in the SharedBufferList, call a new RemoveBuffer(), which
can check whether the buffer is still to be reclaimed. For reclaimed BBuffers,
delete them right away, others can be marked for deletion.
fixes#15606#15263, possibly #15433
Change-Id: I66e94138e7e10a40d4c48e2ac042f816c79f5aab
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2245
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: X512 <danger_mail@list.ru>
Reviewed-by: Ryan Leavengood <leavengood@gmail.com>
- Fix USB_hid_page_consumer.h: some values are skipped in the spec so
our defines were off
- Handle the horizontal wheel on my mouse which is declared as a
CON_AC_PAN, but otherwise works just like the vertical wheel
- Input server and interface kit already handle the events properly
(they were available for serial mice already).
Change-Id: Ie0080ebb27e9478bcfe9f9dc5fd2a936ae05a848
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2201
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
In a menu, we use the right side both for submenu arrows and shortcuts.
As a result, when an entry has both a shortcut and a submenu, its
shortcut is not aligned with others, and this does not look so nice.
The spacing for the arrow appears only if there is a submenu in any of
the items in the parent menu.
Change-Id: If91fdcdad36abb0141fb05d1f59141f89540c1db
Reviewed-on: https://review.haiku-os.org/c/haiku/+/355
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Ryan Leavengood <leavengood@gmail.com>
This is required for building shared libraries with hidden by default symbol
visiblility such as mesa.
Change-Id: I7150629aaea61d7c9b6e641d32913c5cc7c96543
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2159
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* A few tips for future folks follows.
* fenv.h gets wrapped in our buildtools
* If anything in the arch fenv.h "doesn't work" buildtools
will silently fail early on (autotools HAVE_FENV_H)
Change-Id: Icae064fde42af3bbed5ea2eadfaa8c18c677e6a6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2164
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
- 7xx (1st gen) has no driver in Haiku or is handled by the intel_810 driver
- PowerVR has no driver in Haiku
So there is no point in having those in the intel_extreme driver.
While I'm at it, fix the video timing/resolution constraints for
sanitize_video_mode.
- Implement watch_input_devices in input_server, as it was TODO. For
now, only one watcher is allowed at a time.
- Use it in Input preferences to get notified about added and removed
devices and update the device list accordingly.
Change-Id: I52018af53738e68271d6d63b5bea31fd7cab1b3b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2041
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The hacks to still use actual system headers for zlib didn't quite work.
- Define Z_SOLO, which makes zlib build without any system include
- Remove use of std::max and #include <algorithm> from AVLTree
- Do not include DebugSupport.h because it uses system headers
- Do not include uuid.h and define just what we need
Now it's possible to compile the btrfs_shell on Linux.
Change-Id: I74a14b5f6804db45ab5a9f582ab493d696376fd3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2098
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This issue was initially detected by PVS Studio (issue number V547) and fixed
as part of Google Code-in 2019.
The initial problem was the calculate_cpu_conversion_factor function
which had been copied in the BIOS and EFI versions of the boot code.
Further investigation led to more duplicated or very similar functions
being identified.
Introduce an arch_cpu.h for the x86 boot platform to group these things
in a single place, and adjust the BIOS and EFI code to call into that.
Note that the BIOS and EFI code is still a little platform specific,
ideally there should be a boot_arch_cpu_init() function for each
architecture as already done for openfirmware and u-boot.
Also remove some irrelevant comments from copypasted files for other
architectures, as that was filling my git grep with useless noise.
Change-Id: I16d815f0bf015cec0b4e03cc14f3cc447c7164c5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1985
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Borrowed from FreeBSD with some changes to get it building.
Now we need to rebuild the gcc package...
Change-Id: I6b8dfd7fb6ca912c76e2ff10fbe01ad583a09aec
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2131
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Get enough of the mmu working to be able to allocate memory.
Unlike on PowerPC, we get both address and size as 64bit values. So
adjust of_region to allow this.
Also unlike the PPC port, we do not drive the hardware directly, instead we
rely on the openboot primitives to manage the translation table. This
allows staying independant of the hardware, which is a good idea at
least for the bootloader (we can do actual hardware things in the
kernel)
Change-Id: Ifa57619d3a09b8f707e1f8640d8b4f71bb717e2a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1482
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Gets call-method working for sparc, and fix more places where we
accidentally truncate 64bit values or sign-extend 32 bit ones.
Change-Id: Ic79c55ffa8d2b475858def1639004412f17dd0c1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1986
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
glibc does the same. Technically, some of these builtins did
not exist / did not work before GCC 4.4, but the source tree
cannot be compiled with a version that old anyway.
x86_64 and _x86 need to keep the old functions for now, of
course; but all other architectures can probably feel free
to drop the s_isnan, etc. functions from their glibc.
This will make upcoming patches easier...
Change-Id: Ifb76ea74076553228c9741a8ee3ecb0e1cf736a3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2076
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
- The name for the registers were swapped
- The width and height were also swapped in one of them
- Remove some old #if 0 code that touched these registers but has been
disabled for a while.
LVDS panels must really be driven at their native resolution, otherwise
they will simply not work. This means we should basically never touch
the video timings on that side. We need to only set the source size in
the pipe configuration, and let the panel fitter figure out the scaling.
On my G45 laptop, this allows me to use non-native resolutions on the
laptop display. This also means when booting with a VGA display
connected, I do get a valid display on the internal panel (using the VGA
resolution). VGA still gets "out of range", so we're still not setting
up something there.
If I switch to VGA display in the BIOS, I get a working picture there
and garbage on the internal display, which is progress (before I would
get a black screen on the internal display)
Fixes#12723.
For #15515
As mentionned in the ticket, we may also want to hide the symbols
altogether from libroot for newer API/ABI versions, unless we still want
to provide C89/C99/C++98/C++11 compatibility, in which case we still
need them around.
Change-Id: I0ee267fb6c4c2f4bae9b1ba6f68e2bcefc399a7f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2061
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Drop gnu-efi
Change-Id: Ib601fc8ced49b18281b6b98cf861a5aef1b9c065
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2026
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
enable to check whether a shutdown process is in progress.
Change-Id: I8efdddb3caa80e9fd188f202b6e92a888a7608e5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2042
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
There is no reason to not allow this, and it makes it possible to load
data from eg. a BResource instead of a file, which is very useful.
Remove some unused members in the class and dead code, and fix style
issues.
Change-Id: I94cbd0c13c469ea80f55028cf33dfde2de4365ef
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2001
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
- Remove duplicate and otherwise unused lendian_bitfield.h
- Adjust listusb jamfile to use lendian_bitfield.h
- Fix various typos in usb_video.h and restore some fields to make
listusb happy
- Factor in types changes (introduction of intptr_t)
- Align JamFiles syntax with in progress architectures (arm/sparc)
- Xorriso doesn't support much of the mkisofs options (anymore ?)
- (After a correct bootstrap) one should be able to build @minimum-raw and haiku-boot-cd again
Change-Id: I4f779ad8f2210389fa9b7f7c0a98c3652a64c257
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1983
Reviewed-by: François Revol <revol@free.fr>
Using the geonames.org API, so we will need an API key for it (similar
to the one used for MLS, deployed by the buildbot)
The unit tests uses the "demo" user, which is restricted to 20000 API
call credits and often expired. But we cannot use our secret key here as
it would need to be available to anyone running the test. If we ever get
to automate running the tests on a buildserver we could probably make it
use the secret username known by our buildbot instead.
Change-Id: Ia16880db82555ce85505ad28e1c623f692f46be0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1873
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* Move x86 hpet behind timer interface.
* Add a few if x86,x86_64 macros to start.cpp.
Change-Id: I583ec1b064785182e6d48dfbcd91b1bb2ead4b44
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1929
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
The tab frame is drawn behind the tabs.
Create a new DrawTabFrame method in BControlLook and HaikuControlLook
that draws the tab frame background.
Until now we've been reusing the DrawInactiveTab method to draw the tab frame
in BTabView. While this works on HaikuControlLook, it doesn't work on other
ControlLook's (such as BeControlLook) that draw their tab frame differently.
Add FBC method to preserve binary compatibility on gcc2 and gcc4.
Move DrawTabFrame method to where _ReservedControlLook1 was in header.
Set rect to area of tab frame in TabView instead of doing the
calculation in HaikuControlLook so that others may benefit.
Change-Id: I513e238914f6d680f495659b6ec902df15555015
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1936
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>
Change-Id: I88afad6d071e8b577c23da9c60392c60b3726514
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1895
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This class is not implemented in our code. It is not documented in the BeBook.
Change-Id: Id3a48dbd2039005f69998567dcc26548612f3e9f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1876
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Non-KDEBUG kernels and kernel add-ons use atomic operations to acquire
and release the locks inline, so non-KDEBUG kernels/addons are only
compatible with other non-KDEBUG kernels/addons.
Following this change, though, KDEBUG kernels/addons should be able
to run under non-KDEBUG kernels/addons, too, since they always call
into the actual kernel functions and do not inline anything of
consequence.
It previously returned the cookie directly, which made it impossible
to distinguish between a NULL cookie and the function not having
anything to dequeue. This lead to some code setting a cookie that was
not actually used.
Return the dequeue status as a boolean and provide the cookie with an
optionally handed in pointer instead and adjust all users.
Change-Id: Iaac1726ac4bc7ae42bb96b8f0915852b6def5822
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1814
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This makes ARM64 target compile more files. This patch is one of
series of patches to support new architecture, as fixes in many
places are required just to compile the code.
Signed-off-by: Jaroslaw Pelczar <jarek@jpelczar.com>
Change-Id: Ia060612733cd3a0fcb781fec449da164ed635b8e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1807
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This adds one (private) VFS function, and checks in all usages of
the vnode->cache as a VMVnodeCache that it really is one. (Generic
usages, for the moment just the ReleaseRef() calls in vnode
destruction, are intentionally not touched.)
This will be used by ramfs to set the cache from its own,
so that map_file() calls on a ramfs can work.
Refactored out of execvpe. Originally I did this for my attempted
change to posix_spawn, but that change turned out to be wrong and
actually not that beneficial. This bit seems potentially useful,
though, so here it is.
The patched errata are only the AMD ones FreeBSD patches
(it seems there are no Intel errata that can be patched
this way, they are all in microcode updates ... or can't
be patched in the CPU at all.)
This also seems to be roughly the point in the boot that
FreeBSD patches these, too, despite how "critical" some
of them seem.
Change-Id: I9065f8d025332418a21c2cdf39afd7d29405edcc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1740
Reviewed-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
Define a new message, B_KEY_MAP_LOADED, that is broadcast to applications by
the Input Server each time a key map is loaded. This allows apps that cache
key-map data to know when their copy has become stale.
Change InputServer::HandleGetSetKeyMap() so it returns an error in the event
loading even the system (fallback) key map fails.
Change-Id: Icc6c884f695ca59c687d83c680bb2fb467dd90cc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1741
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It now lives in OS.h. The idea is that this will now be
accessible to userland applications, so userland memory
is protected from access by other processes, just as
kernel memory is.
No functional change (the constants are still the same,
though I've changed some to use shifts to make clear
which bits are allocated are which are unused.)
Sparcv9 runs Openboot in 64 bit mode, which means the cell size is
64bit. Use intptr_t where appropriate to make the open firmware calls
work.
Beware, some values are still 32bit, this matters for example for
of_getprop, if you get 32bits into a 64bit variables it will be in the
MSB of it (big endian only weakness...) and confuse things. See for
example in console.cpp, where the input and output handles are retrieved
as 32bit values. It seems wise to check the expected size when using
of_getprop in these cases, instead of just checking for errors.
Change-Id: Ie72ebc4afe7c6d7602a47478f0bfb6b8247004b8
Reviewed-on: https://review.haiku-os.org/c/1369
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Without this, even installed packages still get an "Install" button.
Fixes#14821.
This was implemented by adding BPackageRoster::IsPackageActive. I decided to
have this take a location since GetActivePackages also did, but as noted in my
TODO comment, I think this is awkward.
It would also be nice to show the user they have a different version of a
particular package, but that would require some changes to IsPackageActive.
Change-Id: Iab0d35eb6b671a17711b0214b15164d296927e5a
Reviewed-on: https://review.haiku-os.org/c/1694
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
Consider this scenario:
* A userland thread puts its ID into some structure so that it
can be woken up later, sets its wait_status to initiate the
begin of the wait, and then calls _user_block_thread.
* A second thread finishes whatever task the first thread
intended to wait for, reads the ID almost immediately
after it was written, and calls _user_unblock_thread.
* _user_unblock_thread was called so soon that the first
thread is not yet blocked on the _user_block_thread block,
but is instead blocked on e.g. the thread's main mutex.
* The first thread's thread_block() call returns B_OK.
As in this example it was inside mutex_lock, it thinks
that it now owns the mutex.
* But it doesn't own the mutex, and so (until yesterday)
all sorts of mayhem and then a random crash occurs, or
(after yesterday) an assert-failure is tripped that
the thread does not own the mutex it expected to.
The above scenario is not a hypothetical, but is in fact the
exact scenario behind the strange panics in #15211.
The solution is to only have _user_unblock_thread actually
unblock threads that were blocked by _user_block_thread,
so I've introduced a new BLOCK_TYPE to differentiate these.
While I'm at it, remove the BLOCK_TYPE_USER_BASE, which was
never used (and now never will be.) If we want to differentiate
different consumers of _user_block_thread for debugging
purposes, we should use the currently-unused "object"
argument to thread_block, instead of cluttering the
relatively-clean block type debugging code with special
types.
One final note: The race condition which was the case of
this bug does not, in fact, imply a deadlock on the part
of the rw_lock here. The wait_status is protected by the
thread's mutex, which is acquired by both _user_block_thread
and _user_unblock_thread, and so if _user_unblock_thread
succeeds faster than _user_block_thread can initiate
the block, it will just see that wait_status is already
<= 0 and return immediately.
Fixes#15211.
* It's safe to assume that if the file is shorter than
the provided header, things will go poorly.
* Avoids a random vauge ReadBuffer error.
* This doesn't fix#15230, but makes the issue clearer.
Change-Id: I3471e6de384a0c9be94049ad891c01be980f7846
Reviewed-on: https://review.haiku-os.org/c/1679
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Before this commit, *all* ConditionVariable operations (yes, all;
even Wait, Notify, etc.) went through a single spinlock, that also
protected the sConditionVariableHash. This obviously does not scale
so well with core count, to say the least!
With this commit, we add spinlocks to each Variable and Entry.
This makes locking somewhat more complicated (and nuanced; see
inline comment), but the trade-off seems completely worth it:
(compile HaikuDepot in VMware, 2 cores)
before
real 1m20.219s
user 1m5.619s
sys 0m40.724s
after
real 1m12.667s
user 0m57.684s
sys 0m37.251s
The more cores there are, the more of an optimization this will
likely prove to be. But 10%-across-the-board is not bad to say
the least.
Change-Id: I1e40a997fff58a79e987d7cdcafa8f7358e1115a
Also do some cleanup in private headers, I can't imagine why the build
libraries would need this function.
Change-Id: Ib08810b6efe4738dad596a735d741582a3781b28
Reviewed-on: https://review.haiku-os.org/c/1670
Reviewed-by: Ryan Leavengood <leavengood@gmail.com>
In CodyCam, we attempt to cast the result of this macro to const char*.
However, the ternary operator has lower priority than the cast so it
doesn't work as expected.
Add some protective parentheses here.
Change-Id: I5e9875187cec67b9534b1bbe58d82217c6cd5524
Reviewed-on: https://review.haiku-os.org/c/1667
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Unless __STRICT_ANSI__ is defined (as it is when running the compiler in
--std=c89 or --std=c99, but not when running it without any specific
args), we can enable these by default and behave like most other
systems. I don't know why no one has done this yet despite suggesting it
multiple times and people prefer to #define _BSD_SOURCE manually
everywhere.
Remove all places in our Jamfiles and sources where it had been defined.
_DEFAULT_SOURCE is now enabled by default for all sources of Haiku, since we
let the compiler use GNU extensions (no strict C standard specified on
command line)
Use _DEFAULT_SOURCE as the define name to match current versions of
glibc. Enable it if _BSD_SOURCE is #defined in compiler flags, for
backward compatibility.
Change-Id: I6db04da5f6db437723cdfba3478f5094a69d7727
Reviewed-on: https://review.haiku-os.org/c/1633
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
I assume the intent was the same as in other similar functions above.
Change-Id: I887cd73d846680a5a5ec5c90f678ad4b12122eb3
Reviewed-on: https://review.haiku-os.org/c/1655
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
My upcoming changes to use our "futexes" instead of semaphores
will obviously not work on non-Haiku platforms, so we now
need a copy of this class in libbe_build.
This defines the number of bits in a byte and is used in tnftpd.
Once this is merged, some patches to tnftpd can be removed.
Change-Id: Ie2d0c61ce1371daeeb8549281f4210147fb77197
Reviewed-on: https://review.haiku-os.org/c/1642
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It's used by both Tracker and Codycam and others might find it useful.
Change-Id: I585d3a1bdc7f8fce7d36bedf6867464cd541ba2e
Reviewed-on: https://review.haiku-os.org/c/1637
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Previously, it identified all Zen CPUs as Ryzen 7. Since the model
and stepping information consist of microarchitecture information
and don't carry the model number, use the parse_amd based name,
which will remove any unnecessary details from the returned name.
Fixes#15153.
Change-Id: I1a20bf35a60b2fdd20d4cc90ec2dd95fd0e6439d
Reviewed-on: https://review.haiku-os.org/c/1634
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Discovered this while working on VLC, checked with other online sources too.
Change-Id: I114c20babda0ff0e90d0eeee299d8483700166bd
Reviewed-on: https://review.haiku-os.org/c/1628
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Even on 64bit CPUs it's a 32bit register.
Change-Id: I9a4de6eec225de19a90d70fae1382b662e530629
Reviewed-on: https://review.haiku-os.org/c/1625
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
B_OS_NAME_LENGTH is 32, char* is 8 (on x64), and this structure
has quite a lot of pointers in it so it is not like we really
needed to save those 24 bytes. Hitting malloc() in here is not
so great, especially because we usually have B_DONT_LOCK_KERNEL_SPACE
turned on, so just inline and avoid it.
Change-Id: I5c94955324cfda08972895826b61748c3b69096a
The idea was that the Media Extractor could wrap the original source
given by BMediaTrack, but all operations on the data go through
MediaExtractor anyway.
We could probably move ownership of the BDataIO completely into
MediaExtractor instead.
Change-Id: I846b34b543fb983e60f6adf86cb17e835303267b
Reviewed-on: https://review.haiku-os.org/c/1587
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
The sparc openboot implementation can run executables in the a.out
format. We used to generate these using objcopy, but this does not work
anymore as binutils is deprecating a.out format support.
- Import elf2aout from FreeBSD
- Add some missing bits to our elf.h and have a copy of it in the build
headers so it can be used to build elf2aout for the host platform
(tested for Linux)
- Use it to generate the sparc haiku_loader
- Adjust the bootloader linker script to have two "program headers": one
that is not loadable and contains the ELF headers, and the second one
that is loadable and contains the actual code and data. Unlike
objcopy, elf2aout relies only on the program headers to know what to
put in its output file (sections are ignored), so this is required
otherwise we end up with the ELF header nested inside the a.out file,
and everything offset from the expected load address as a result.
Confirmed that this allows to build the loader and run it as far as
before, so I'm back to needing to implement some MMU support now.
FreeBSD commit: 7551d83c353e040b32c6ac205e577dbc5f2c8955
Change-Id: I90b48e578fa7f148aeddd8c5998fdddc5cfa73fa
Reviewed-on: https://review.haiku-os.org/c/1557
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This was (following the packagefs changes) the number-one (by call
count) consumer of malloc() during the boot -- 52866 calls, and 100%
of them either 1024 or 1025 bytes!
Virtually all of these are ephemeral (indeed, the object_cache
stats after a boot with this patch shows there is only a single slab
of 64 buffers allocated, and most of them unused), so this is
probably a significant performance boost.
Change-Id: I659f5707510cbfeafa735d35eea7b92732ead666
If the buildbots were working, I would have been informed of this
about an hour after I committed it last night. But it seems they aren't.
Maybe kallisti5 will have some more incentive to work on that?
Cleans up some lock/get/unlock sequences, and makes it possible
for external consumers to get team structs (which will be necessary
for permissions checks.)
* Now matches the rest of the architectures.
Change-Id: I6699e0c8f729923770f136f2c9599185a685336a
Reviewed-on: https://review.haiku-os.org/c/1527
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
The previous hack, which as the comment (and __MWERKS__) implies
dates all the way back to the Be era, finally broke: int32 is "int"
on non-x86, not "long", and so this generated an undefined symbol
error on ARM.
The best solution seems to be to make StartMenuBar merely protected,
and then make a subclass where it is fully public to call it.
This is a lot less fragile (and much less ugly.)
Change-Id: I0519d0d9eeb1cc4523d0c6dd4fdfe8688ed1092c
Reviewed-on: https://review.haiku-os.org/c/1516
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Remove a currently unused copy of it from HaikuDepot.
Change-Id: Idb97fae8e7190da6bc1049b3c1f1df929ea91bab
Reviewed-on: https://review.haiku-os.org/c/1506
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Their copy constructors are exactly what GCC would generate,
but we can't remove them because doing so would make them
trivially copyable, and so they would be passed in registers
on x86_64, an ABI breakage.
So instead we have to add explicit casts to void* here.
A lot of these classes are not *technically* "trivially copyable"
for one reason or another, but in all of these cases it seems
OK to me to use memcpy/memset on them. Adding a cast to void*
tells GCC that "I know what I'm doing here" and shuts up the
warning.
These worked in identical fashion to what the default copy
constructors would be, but their mere presence marks the class
as being "non-trivially copyable," which means that memcpy'ing
it is now a -Werror on GCC 8.
We have to be careful when making this change, though: classes
which *are* trivially copyable can be passed inside registers
on x86_64, so changes like these break ABI in a dangerous way.
These classes is private, so it should not be a problem, but
for other classes (e.g. BRect, BPoint) we cannot fix them
properly right now.
should help for ports.
Change-Id: Id504bdb79cb68db4b615f58848e0e1a86ced8d2b
Reviewed-on: https://review.haiku-os.org/c/1467
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
add-ons" is set.
Confirmed to fix#14361. It is finally possible to un-brick an install
with a bad system library in non-packaged without having to use another
install to do so.
Change-Id: Iafea7821f02cb34e77c766b1f97d1c19206b1081
Reviewed-on: https://review.haiku-os.org/c/1452
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
All of Barrett's individual reverts have been squashed into this
one commit, save a few actual bugfixes.
Change-Id: Ib0a7d0a841d3ac40b1fca7372c58b7f9229bd1f0
This allows cpu_type.h to be used in C-based software,
with the get_cpu_*() functions all accessible via C as well
as C++ code.
Tested changes with sysinfo, AboutHaiku and Pulse.
Change-Id: Ide87d8e3f2ba5f0f1890f385b1ac90c677bcc274
Reviewed-on: https://review.haiku-os.org/c/1453
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
app_server just passes the add-on path around.
Maybe we should make sure the add-on can be loaded when setting it.
Change-Id: I3acd3299782a22c1666bd5435dbf3d8053e359fa
Reviewed-on: https://review.haiku-os.org/c/1430
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* mutex_destroy() only checked wether or not there were waiters,
not if the lock itself was presently held by another thread.
Now we do, which should make #15015 panic much earlier instead
of trying to use freed memory.
* mutex_transfer_lock() and recursive_lock_transfer_lock() did
not check that the calling thread actually owned the lock.
Now it does, which should trigger asserts if anyone tries
to do this.
