- Remove backported function that was needed only for old OpenSSL versions
- Add compile time options to declare which version of OpenSSL API we
want to use
This should make it possible to build with OpenSSL 3 while keeping the
old APIs available. Once the migration to OpenSSL 3 is done, we can bump
the OPENSSL_API_COMPAT value to get compile time errors when using APIs
that are deprecated in OpenSSL3, and rewrite all the code that needs
changes.
Change-Id: I606633739ed12f9698a3013989025b68478352fc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6484
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
In the case of devices where the mass-storage interface is not the
first one, we will miss it unless we were to check all attributes
one at a time in order. Instead of doing that, just fetch the configuration
and enumerate it directly.
I saw in a KDL stack trace that this function was using over 4KB of stack.
As it is called as part of device_manager startup, where there can be
pretty deep recursion happening, that seems like a bad idea.
Additionally, it did not actually do bounds checking.
Now we dynamically allocate an array of sufficient length.
There is now an "io_lock" which must be held when performing any USB
operations. All ioctls that read basic status, size, icon, etc. information
do not need to acquire it, of course, which should improve userland
lockup occurrences on congested USB disks.
A "bypass" mechanism is left in for when DMAResource would just add
overhead for no reason. All other I/O goes through it and is submitted
to the USB stack as physical addresses.
Tested in QEMU, can still boot from USB on all busses.
Fixes#15569.
Change-Id: I26bfd2208de4ebe1a17170a7034316076927663f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6480
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Introduce a new utility method, "generic_memcpy", which takes
generic_addr_t plus indications of whether these specify virtual or
physical addresses (and potentially user addresess) and calls the
appropriate memcpy variant depending.
All bus drivers adjusted to support this at once. We don't actually
take advantage of the physical addresses in any way (yet), as USB
controllers have some pretty specific requirements that would have
to be carefully validated to use these directly.
All bus drivers tested and confirmed to still be working.
Change-Id: I66326667e148091147bb2b3d0843a26fb7e5bda6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6479
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Prepares the way for actual physical-address request support,
which is not yet wired up.
Change-Id: I1b2d04a31e334a79b8361280fa0f3a5fbdb43d2b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6478
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This way it is more easily accessed from drivers outside the kernel,
which it soon will be, without having to add an explicit UseHeaders.
(The drivers that use it already all use the IOScheduler.)
No functional change.
Change-Id: Ibc2d2678e37d9d7ab73391cb17b72cca86f92132
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6477
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Before the PCI refactor, PCI initialization/enumeration occurred
immediately after the PCI module was loaded, and so by the time
we got to IOAPIC initialization, it was already complete.
After the refactor, PCI enumeration is deferred until slightly later,
and so we would try to initialize IO-APICs without knowing PCI
information. This would fail, as read_irq_routing_table needs to
have that available.
Hopefully fixes#18425, #18393, #18398.
Change-Id: I1e4b06367da26eeb10085a1c6322ed39885b632b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6476
Reviewed-by: X512 <danger_mail@list.ru>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
registering new devices requires the device_manager lock. The explore thread would wait
that the initial device scan is over to register devices.
Change-Id: I46529ab0926f349023f06ada3411979c0950dfcf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6475
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 ASSERT causes a crash in the debug build of libtracker.so.
The crash occurs when two conditions are met:
1. There are files in the directory with icons specific to them. This
is the case with image files, whose icons preview what the contents
of the image are.
2. Tracker has not displayed those icons yet. This happens if the user
has not scrolled down far enough to see the icons.
One way to meet these conditions is to configure the build system to
compile a debug build of libtracker.so. Then compile icon-o-matic.
Then run icon-o-matic with the debug build of libtracker.so
LD_PRELOAD'ed.
With that, press File->Open and navigate to
/system/documentation/BeBook/images/admonitions. While in the images
folder, do not scroll up or down to view the icons of the images in the
folder. They should remain unrendered. It should crash as soon as
Tracker enters the admonitions folder.
The crash occurs because NodeIconCache::Deleting is called without a
corresponding call to NodeIconCache::AddItem. Tracker calls
NodeIconCache::AddItem whenever it renders an icon to cache the result.
Tracker, however, is lazy, and only renders the icon when it comes into
view. When navigating out of the directory, Tracker has to call
Deleting for every file in the directory since it doesn't keep track of
which icons it rendered and which icons it didn't. Thus, AddItem has
been called for some of the files, but Deleting has been called for all
of them, causing the assert to fail and the program to crash.
This commit fixes the problem by not requiring a call to AddItem for
each call to Deleting.
Change-Id: I1038ce70ca345c44812becee7f3752567e5b562a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6474
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
These are populated with the correct version automatically when building
the package, so there's no need for an explicit setting. This had
already been cleaned up for the other packages, but not yet for
haiku_secondary
Change-Id: I5bcc94fb80f639610899ec31fc77a6e678ca9e80
These are used only by ICU tests and should not be in the ICU package.
They will be removed in the next versions of the ICU package when we
update.
Change-Id: Ib8bb2dd24ce1671e8b369c775b89d49b9b6e84eb
This is mostly important for B_GET_MEDIA_STATUS, which actually will
retry actions if the err_act is set appropriately.
Following this change, stalls are now fully recoverable without causing
the file descriptors of the mounted partition to be cleared, and the
system can resume normal operation without a problem.
Fixes part of #15569.
May help with #16745, #18185, #17543, #18421.
XHCI, at least, has "sticky" HALT states which must be cleared at
the controller level. Invoking cancel_queued_transfers takes care
of this.
This fixes USB disks spontaneously unmounting whenever stalls occur.
However, trying to read anything from the mounted partition results
in "Bad file descriptor", probably due to media-status error propagation.
Set modifier keys as following:
- Right Cmd -> Right Alt
- Right Opt -> Right Win
Change-Id: I61a193a7690fca8486ecd2c17eb672d24d69e241
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6471
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
This allows us to drop the PCI-specific ACPI management entirely.
Confirmed working on x86, and the fallbacks when there is no ACPI
also still work.
Change-Id: I6dac9f5539f99b934b17b341634ce22628bc66fd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6470
Reviewed-by: X512 <danger_mail@list.ru>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
On my machine, the address_length somehow is 0, but can be computed from
the minimum and maximum values.
Change-Id: I2262263915319e0d97a2cd9b9fde3f6af1f79a84
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5759
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Allow to easily access the alert icons and anything that's added to app_server
resources.
Fixes#10887.
Convert BAlert, Debugger AlertWithCheckbox and Keymap ModifierKeysWindow
to make use of it, removing the duplicate code to locate app_server
resources.
The resources are initialized only once (per application), so there is no need
to reload them for every access to the icons.
In the ticket there is discussion about putting this in BControlLook,
but I think this should in fact be moved fully into app_server with
special drawing commands for well-known icons. That would avoid loading
and rendering the icon on the application side to then send it to
app_server (especially in remote_app_server case)?
In any case, this simple API can serve as a base for applications to
use, and we can change how it is implemented later on.
Change-Id: Id370526ae5cf165cfb8bc277bc8a7f46c26f542d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6463
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
I found leak_analyser.sh and gave it a try. Indeed, it did find many
leaks, including this one.
Change-Id: I7d36274f3f7772aa459c4bf1d30392e7b8cfa171
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6467
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
We did not ever implement these, it seems, and so they are just
cluttering up the global namespace.
Change-Id: Ib37c3a31663525a18268c9bfe326bfba9afbc794
`cut_area` now checks the protection of the target area for
the `B_OVERCOMMITTING_AREA` flag and sets it on any cache it
creates. This allows operations that split large overcommitting
areas to succeed.
Change-Id: I8dee27d22df29741cc61af2575c9e6626da25949
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6391
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
