- 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
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.
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.)
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.
Otherwise we load and unload the SCSI module thousands of times,
which is expensive. It was only added to this section for virtio
in d3b108c53d, 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>
Necessary to get the system profiler to work properly.
Change-Id: Id9c1a0bedaef18680361c5de449d293ff053940c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7964
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
And add the necessary logic in scheduling_recorder. This way we can
track scheduling profiling during the boot process.
Also remove B_SYSTEM_PROFILER_IO_SCHEDULING_EVENTS as it can't be
activated this early in the boot process.
Change-Id: If32f9b5d61c8cd2b3b36a4e6f8065301abd46149
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7963
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It helps to simplify to view difference and apply patches.
No functional changes.
Change-Id: Ia29368eceaeb3306990c09da77c4527eff87c72a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7932
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This reverts c5a499a74b
(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 81e50deece,
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.