* Migrate some platform agnostic architecture code into
boot/arch from efi/arch. This helps to avoid conflicts
between kernel and boot sources as well.
* Conflicts between arch_cpu in efi and kernel code means
bootcode really should *never* directly use kernel arch
headers. (other platforms don't, which is why they don't
have this same issue)
* We carefully thread any needed kernel headers (namely
assembly helper macros) into the bootloader headers without
mixing in the whole conflicting kernel/arch headers.
* ARM now properly get its cpu init code called, and we
progress further into the EFI bootloader.
Change-Id: If67ec9758b5ce68563ebd9eb45d5196401911c67
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2975
Reviewed-by: waddlesplash <[email protected]>
None of these were used; they were all imported with the original
root Haiku commit, and they are totally unrelated to PulkoMandy's
new SPARC work. Plus, they were also under a BSD Advertising Clause
license.
The BSD implementation was under the Advertising Clause,
so we might as well take the opportunity to replace the
implementation entirely with musl's.
Header also rewritten to be a Haiku one; the constants
are left unchanged of course.
Taken from FreeBSD; some minor cleanup elsewhere.
udp.h rewritten entirely as it contained no copyrightable
material and bears little resemblance to BSD's.
* Remove functions not even FreeBSD defines.
* Remove dependency on unnecessary headers.
* Update copyright headers to match FreeBSD's; includes
removal of the advertising clause.
* Move some private structs to netresolv port_before.
Unfortunately, it seems musl implements very little of this file,
so we may wind up sticking with netresolv for its implementation.
* Remove all functions and a number of constants that neither
glibc nor musl define or support (and even FreeBSD does not
declare a good number of these anymore.)
* Redeclare the primary flags in terms of (1 << X) instead
of raw 0x... for readability (the constants at the end
do NOT match up to their definitions in glibc, musl, and BSDs!)
* Remove usage of unneeded headers, and __BEGIN/END_DECLS.
* Replace non-Haiku license headers with the ones from FreeBSD,
which notably contain a removal of the advertising clause.
ABIs remain unchanged, but a small set of applications that
use these esoteric APIs may not compile anymore (are there
any remaining?)
These are not in the standard and are not declared by glibc at all.
The symbols remain for any applications that are still using them,
for now.\
Change-Id: Ie6b4a6b5ec3231c304e05ce9cb38c67d9ee51ad7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2942
Reviewed-by: waddlesplash <[email protected]>
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 <[email protected]>
* 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 <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
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 <[email protected]>
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 <[email protected]>
Reviewed-by: Jérôme Duval <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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.
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
Reviewed-by: Jérôme Duval <[email protected]>
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 <[email protected]>
* 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 <[email protected]>
- 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 <[email protected]>
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 <[email protected]>
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.
Alexander von Gluck IV