Notable changes:
* jpeg replaced with libjpeg_turbo across the board.
* man replaced with mandoc.
* ilmbase merged into openexr.
* gnutls no longer needed in this set.
A few other packages unused in the local scripts were
also removed. Build fixes are in following commits.
Previously, all packages on the image, both activated and unactivated,
were in $systemPackages, so if a package actually in /system/packages
had a dependency in the Installer optional package area, the dependency
checking would see no problem but the generated image would be broken.
Now, packages going into /system/packages are treated separately
from those going elsewhere, and error checks added so the above
condition will not occur.
(I ran into this while working on the build-package upgrade
in the following commits.)
No need to pull in e.g. "libpng16" explicitly when the appropriate
libpng version will automatically get selected by get_package_dependencies
at image build time.
I did however remove ctags altogether; nothing in the base install
uses it, so there's no reason to have it.
It seems clear that the architectural designs of rpmalloc are
just not suited for us in the "corner-cases", and probably never
will be.
After R1/beta2, I'll investigate switching us to musl's mallocng,
which is explicitly designed as a system allocator and has much
lower overall memory usage than even glibc's default allocator.
This received 84% on the forums, so it seems pretty uncontroversial
to enable it by default.
No other option received 70% or more, so I'll leave Humdinger to
decide what the other changes to the defaults should be based
on whatever threshold is decided upon...
Should constitute a minor performance gain, with no functional change
(the kernel ELF loader does not do any semantic interposition; or
any interposition for that matter.)
Somehow, I missed this when implementing MTX_SPIN in the first place,
and it went largely unnoticed because MTX_SPIN is rarely used and
apparently even more rarely destroyed.
Should fix#15749.
They were theoretically guarded by the controller lock, but it appears
nvme_ns bypassed that, meaning that if ns_read was executed at the
same time as qpair_poll, unpredictable races could occur. This solves
that by making the qpairs guarded by their own mutex, which also
has the advantage of poll() being executable on more than one qpair
at a time.
Seems to fix the KDLs in #15123 (and maybe other NVMe tickets),
though the I/O corruptions remain.
Since the entry_cache operations go through the mount lock,
this may considerably speed up parallel entry cache operations.
Change-Id: Ib2f841e288eb593ee3f795922103459c77764c22
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2362
Reviewed-by: waddlesplash <[email protected]>
This protects against malicious programs trying to steal/overwrite
kernel memory by overflowing user buffers.
Note that this constitutes a behavioral change to user_strlcpy:
previously, address overflows on the "source" side would either
copy less data, or copy some data and fail anyway. Now, address
overflows on either side will always fail before any data is
copied at all.
Change-Id: I01d8b22672ab3758a9dd87b521af6fedd0487417
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2361
Reviewed-by: Adrien Destugues <[email protected]>
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...
Requires the preceding commit due to how it uses ConditionVariables.
Massively decreases CPU usage under heavy disk load.
Change-Id: I967e5ed000751d9f3971dd811563e23bcb13dd50
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2302
Reviewed-by: waddlesplash <[email protected]>
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 <[email protected]>
This is inside a "endpointId > 0" block, and endpointNum=id+1,
so we will never call EvaluateContext here. (Endpoint "1" is
configured by AllocateDevice.)
Spotted by Coverity.
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 <[email protected]>
Reviewed-by: John Scipione <[email protected]>
BRegions with only 1 rectangle will use inline data and perform
no allocations, so when we create a BRegion and only add
one rect to it, we can just use one inline and avoid using
the pool entirely at no cost (and some savings.)
No functional change (intended).
Change-Id: I10ac6bc7b5cf6b681641e88558a3f1ba770b6f77
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2298
Reviewed-by: waddlesplash <[email protected]>
_ConvertToInternal does the same thing, and should get inlined
under normal circumstances, so just use it.
No functional change (intended).
Change-Id: Ic4fc9daeb33ab33967d795065a077f282e844f6d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2297
Reviewed-by: Adrien Destugues <[email protected]>
Reviewed-by: John Scipione <[email protected]>
The previous code was missing a "~" make it possible for someone to
press PrntScrn, and then later Alt+D to trigger KDL, which is obviously
not the desired behavior. SYS_REQ_KEY only triggers when Alt+SysReq
is pressed, so this was not as much of an issue without PrntScrn.
Usually these are the same physical key, but some keyboards
(like my laptop) do not have a SysReq key, only a PrntScrn key.
Fixes entering KDL via the shortcut on my laptop.
This way, it is now actually impossible to submit a request to a
pipe that is in the process of being destroyed, solving several
race conditions.
Should fix the remaining KDL in #15710.
In d49942867b (part of hrev52813),
I moved invocation of the TERM_BEFORE/TERM_AFTER functions to
runtime_loader. Unfortunately, I only updated one location where
they should be invoked, and runtime_loader had two.
After this commit, there is one function that they are called from,
which is itself invoked from the appropriate places.
Noted by ttcoder & mmlr in #14047.
* As we were clearing out the endpoint structures before detaching
the xhci_endpoint from the Pipe, it was possible for SubmitRequest
to be called while we were being destroyed and then use the half-
torn-down endpoint, leading to crashes. Instead, we now call
SetControllerCookie first, so that SubmitRequest will thus
fail.
* Lock the endpoint after calling StopEndpoint, for the same
reasons that this is now the order of operations in CancelQueuedTransfers.
Probably fixes#15710, and maybe other issues.
It was only actually used to determine if a device was disabled
or not, which can be determined by checking the "slot" field
is "0" instead, as 0 is an invalid slot number.
No functional change (intended.)
KPaths are most commonly used in the VFS syscall paths,
and so they are typically user_memcpy'd to/from userland.
In the "to" case this is not really necessary (but it should
be so small of a performance difference as to not matter),
but in the "from" case, we must always clear the buffer
we received from the allocator, so as not to leak information
to userland.
Part of #14961.
If a transfer completed before the StopEndpoint did,
HandleTransferComplete would try to lock the endpoint,
resulting in a deadlock, and so StopEndpoint would
always time out in this case.
May help with #15161, #15141, #15215, #15416, #15657.
It seems that many controllers do not report status changes following
the hand-off from the BIOS, so we were never probing those ports
and reporting the devices attached to them.
The BSDs do something similar (although it seems to only do this
on the first explore, not always.)
This fixes booting off of USB3 ports from most Intel controllers,
as well as a variety of others with similar behavior.
Fixes#15000.
Before the refactor to use Event Data TRBs, this was necessary
to detect short packet conditions. Now that we use Event Data
TRBs, the hardware will send us an Event Data event even on
Short Packet conditions, so this is redundant.
Fixes log spam of "TRB ... not found in the endpoint", as
this was causing duplicate event postings. Also potentially
fixes instability seen when those messages were present.
Only a few definitions (and some "hacks", to force glibc to
use __builtin_* where possible) that are not in our math.h
remain. This cuts out a lot more of the "bits" headers.
No "functional" change intended (but should help
fix the build on arches where we do not include
__fpclassify, etc. anymore.)
This was the last function remaining in the glibc "string" directory,
so now we can remove that directory and a bunch of related files
that are no longer needed.
The glibc libm code was showing its age, and has recently been
the subject of a number of tickets about its inaccuracy.
Additionally, some developers have complained about
how convoluted the headers are, and thus how hard it is
to add support for new architectures (and how flaky
the support for the existing architectures is.)
So, with this commit, nearly the entire glibc libm has been
gutted and replaced with the one from musl 1.1.24.
The complex functions from glibc are retained (as they
are more mature than musl's), as are some glibc-internal
libm functions.
This also has the advantage that these functions are
actually using our <math.h>, whereas GCC used its own,
which was rather dangerous for obvious reasons.
Additionally, the new math functions are always compiled
with GCC 8 (even on x86_gcc2), as it seems GCC 2 does
not quite understand some of the union-aliasing they
use (a lot of which was added in C99, I suppose.)
FFmpeg on x86_gcc2 is already compiled with GCC 8
and that has so far worked out well, so there should
not be any problems caused by this.
I did verify that ARM and PPC at least still compile,
though other architectures may require a bit more work
(they are not bootstrapped so I could not do much.)
Should fix#14933 among other issues.
Change-Id: Ifeea0ddab23a8d0480fc26dece1b0192afc263bd
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 <[email protected]>
There is a section of the spec that dictates how TRBs need to be
sized within a TD, and we were not following that. This should
bring us into compliance.
See inline comments for more details.
Even if we are still not so sure about the veracity of other
filesystem drivers, the BFS driver has had no reported corruption
bugs for quite some time (almost 2 years I think). In fact the
only real corruption issues heard of recently are from KDLs,
which are also a vanishing issue.
So, disabling the warning entirely for BFS partitions probably makes
sense at this point.
Change-Id: I5470c956d57b90ea00b647bf15299ba606ba01c4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1822
Reviewed-by: waddlesplash <[email protected]>
The PCI enumeration functions are not implemented in the compat layer,
so we need a glue function that performs the Haiku equivalent here.
This code existed in the old Haiku-native driver, so it's just
copied from there.
The within-an-attempt timeout did not successfully break up
deadlocks that occur on a system with a lot of USB transfers
going, as we may never hit 2 seconds in between wake-ups,
but the size requested may be un-fulfillable regardless.
So, now we have a 2-second overall timeout. This fixes
the system freeze in #15569, but now attached USB disk
drives enter a Stall state, making the system unusable
anyway.
In hrev53370, leavengood refactored this function out of
PackageVolumeInfo::SetTo(). Inside that function, there
is a "state" variable which is initialized to the first,
default state, which is always the head state.
Refactoring it out of there and changing this to NULL meant
that GetNext would always return a NULL state, so the
states would never be initialized, and booting from an
old state would thus not be possible.
Fixes#15380.
It seems some drivers do not create dmamaps for all their bustags,
so we can't allocate the segments there. And of course, some also
do not go through dmamem_alloc, so the only option then is to revert
to where FreeBSD allocates them, inside dmamap_load.
Augustin Cavalier