Includes OpenSSL 3.0, Python 3.10, and more.
(cherry picked from commit 7dea48f378ea64a3dfdeba5f2f2bc9c80d2e0254)
Change-Id: Id029ee3b91baad503ea5b5c7cd2b6a5cf2054a32
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7986
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
- Rename the package in Jamfiles as appropriate (but don't rename the
build feature)
- Remove libnetapi SSL class (not needed anymore, OpenSSL now knows how
to use pthread functions directly and seed its random generator)
- Rename or remove a few other deprecated functions
Change-Id: I624833923e113a8235932d7ce8020bf27c6e2ea6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7717
(cherry picked from commit 6c59ed739ba2adcde633b55a9f829c8b48e7e9af)
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7984
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The IORequest internally likes to deal with transferEndOffset
not transferredBytes because of sub-requests potentially being
prepared all at once (in some paths in the I/O scheduler),
thus fTransferSize can get incremented in Advance() before we have
actually executed that transfer.
But external consumers much prefer just knowing transferredBytes
not transferEndOffset. And many of them actually named their
variables that (or "bytesTransferred") and just passed the
transferEndOffset through to variables with that name! That's
obviously wrong, and it's surprising it wasn't discovered before now.
The problem was uncovered by repeated KDLs in PrecacheIO.
That method used the "bytesTransferred" value as a count of
pages transferred, which would then run past the end of the array
if the transfer start offset was not 0 (which the majority
of the time it would be, since this method gets called on
the first mmap() of a file, probably before any pages are read in.)
Most other consumers of this API did not check the value, it seems,
or otherwise had some mitigating factor that prevented it from
causing more problems. An exception is the page code, which
may have spuriously considered writes as successful when they
really weren't.
May fix some of the "invalid concurrent access to page" KDLs.
(cherry picked from commit 3ecbb34240d2f647222aa53ff0b5dca7f3873c33)
Change-Id: Id4f0e4cf96d44760691a533dbd82d95c8bc35e9f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7983
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The Desktop instance is currently a singleton, and by the time it starts
the GlobalFontManager's initial scan is already running, so if we
register the user paths then it will spend a long time waiting for
the lock. GlobalFontManager didn't even use the provided UID,
so just move the add-user-paths logic into the constructor.
This helps with #18669 on systems that have the default fonts set
and no font settings file. (On systems that do, the global font
manager lock will be acquired in desktop settings initialization.)
(cherry picked from commit 4909eb2091b751e2cee8eac11ecabf3315544a99)
Change-Id: I682b2c524996a9fbb2ddc0c4c661fd27c71fcec5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7982
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This wasn't noticed until now because the IPv4 module would just
truncate packets to their actual length, but the extra data would
appear in packet captures.
(cherry picked from commit 27462aa0c7cc684a0d3ed2ee7797f60b9410c44c)
Change-Id: Ied9e42dbd104e85962f280424a17bb9fe0e96c03
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7981
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Otherwise we load and unload the SCSI module thousands of times,
which is expensive. It was only added to this section for virtio
in d3b108c53d151d7c0aab32c1562bca355462868b, so avoid scanning
it here except in that case.
Confirmed that virtio_scsi still works as a boot device.
While at it, remove an unused get_attr.
Change-Id: I0882fcb3465809d6bcdd8ed45e66a4dbfe91f7ac
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7965
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
(cherry picked from commit 58c9714921c8fd4d82f2217693241fb71b29ec3a)
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7980
EFI doesn't have a boot keys mechanism so we just disable the
routine that enables it entirely. Also disable it in early kernel
output before the settings file has been read.
This reverts c5a499a74b7a3516451337373e455bb2aba00ace
(except for the style fixes in that commit.)
See inline comment. Even after the fix to realtime events,
it seems there are still some lingering bugs causing freezes
on some systems. For now, remove the check again.
_prepare_bounce_buffer also calls _allocate_dmamem and needs to have
the passed BUS_* flags handled properly, so just move the handling
to _allocate_dmamem directly.
The logic in the mixer will automatically stop the mix thread but
leave the "Started" flag set in this case.
While at it, clean up that logic.
This suffices to get the mixer to connect and disconnect from
the same output, at least, and have audio output still work.
See inline comment. As we initialize the TimeComputer with the current
system_time(), if the driver reports the played_real_time of its last
buffer exchange (which, if we're restarting media_server, could be
non-zero), we need to just ignore it.
Fixes assertion failures when using usb_audio. And now that we have
this check in here, we can remove the assert from TimeComputer.
Also add a cast in _GetControlName to appease GCC2 while at it.
Also refactor the logic to not need goto.
The previous design (from 2016) generated an event and wrote to the
control port to queue it, and then the control thread woke up our
semaphore at the appointed time. Rather than have this inefficency,
just use a timeout to the acquire_sem (which is more similar to the
pre-2016 design.)
This should not affect mixer behavior (as we wait for buffers
inside this logic already), it should only reduce the latency
of actual mixer runs.
Time out after waiting at most for 10 seconds. After 81e50deecea7,
this should only happen when the registrar succeeds in sending the
message but we fail in receiving it for whatever reason, so really
this is just a guard against infinite hangs.
Otherwise, if the filesystem doesn't set them, we will have garbage
values and act wrongly.
This fixes the second KDL and the underlying cause of #18838:
when the system gets into a low memory state, VFS purges unused vnodes.
But of course RAMFS keeps those nodes around. When the VFS went to
retrieve the nodes for reuse, the flags would sometimes randomly
have the "removed" flag set, and the VFS would then try to delete
the node. But of course it wasn't really removed, so we would hit
an assertion failure in RAMFS.
