Removing it outright would cause implicit conversions and then the other
variant being called, which would create invalid lists. So make it private
so that any attempts to use it will create errors at compile-time.
As far as I can tell, it has no consumers whatsoever outside the tree.
(wpa_supplicant did not even use it.) So, remove it altogether.
If that turns out to be mistaken, we can reinstate it temporarily
as a private class function or ABI-only symbol.
Since we used a hash table with a fixed size (1024), collisions were
obviously inevitable, meaning that while insertions would always be
fast, lookups and deletions would take linear time to search the
linked-list for the area in question. For recently-created areas,
this would be fast; for less-recently-created areas, it would get
slower and slower and slower.
A particularly pathological case was the "mmap/24-1" test from the
Open POSIX Testsuite, which creates millions of areas until it hits
ENOMEM; it then simply exits, at which point it would run for minutes
and minutes in the kernel team deletion routines; how long I don't know,
as I rebooted before it finished.
This change fixes that problem, among others, at the cost of increased
area creation time, by using an AVL tree instead of a hash. For comparison,
mmap'ing 2 million areas with the "24-1" test before this change took
around 0m2.706s of real time, while afterwards it takes about 0m3.118s,
or around a 15% increase (1.152x).
On the other hand, the total test runtime for 2 million areas went from
around 2m11.050s to 0m4.035s, or around a 97% decrease (0.031x); in other
words, with this new code, it is *32 times faster.*
Area insertion will no longer be O(1), however, so the time increase
may go up with the number of areas present on the system; but if it's
only around 3 seconds to create 2 million areas, or about 1.56 us per area,
vs. 1.35 us before, I don't think that's worth worrying about.
My nonscientific "compile HaikuDepot with 2 cores in VM" benchmark
seems to be within the realm of "noise", anyway, with most results
both before and after this change coming in around 47s real time.
Change-Id: I230e17de4f80304d082152af83db8bd5abe7b831
Change-Id: Ia16e66a7bdac37019e6256405b9f10024909c69a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6215
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
The kernel heap only uses object caches for objects up to size 8192.
Larger allocations have to go through the raw allocator. That can
get pretty expensive.
Adding instrumentation around the malloc/free calls in this function
showed that on my machine, some 596ms during boot were spent on
*malloc/free alone*, all else aside. After this change, we are at
around 110ms, or a >5x improvement. Running an fgrep -R on /system/
after boot increased the cumulative time in memory functions to over
5 seconds, while after this change it is "only" 1170ms.
Honestly, it seems like the object depots should be able to be faster
than that, even if this function is called thousands of times. But that
is a problem for a different investigation.
It would be even faster for every consumer of this data in
packagefs just allocated one set of buffers up front, or at least
for a single "read session", but plumbing that all the way
through the myriad abstractions of the Package Kit will
not be easy, and is left for another time, as well.
While the BSDs and glibc seem to have various _r functions,
they all return int for errors instead of a pointer, making ours
exactly backwards of theirs for error reporting and thus useless.
So, remove them from the header entirely. They are left in
for ABI backwards compatibility for the time being.
A few constants not used by anything in the tree (i.e. not actually
implemented by libnetwork/netresolv) were also dropped. Some deprecated
or non-standard functions were placed behind _DEFAULT_SOURCE or deleted
entirely.
The header itself is now organized approximately as the BSDs do,
although with various Haiku-isms instead of BSD-isms where appropriate.
In fixed size mode, the menu field always uses all the available width.
In non-fixed size mode, the menu field will resize itself to be as small
as possible.
With layout, usually the difference isn't noticeable, since the layout
will already try to resize the control to the smallest possible size.
But there are a few cases where it makes a difference, when the layout
is over-constrained and the menu field can't be made as small as
possible. In that case, the menu field would be forced to fill its
allocated space, where we can instead make it a little smaller.
Change-Id: I911d497218a09aab3824865968558df5d4b3cf98
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6076
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: John Scipione <jscipione@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
These were introduced by mistake during the addition of the layout
system. They have been private since 2011. It seems safe to assume that
nothing uses them anymore and they can now be removed safely.
Change-Id: I98d030096f9cb06fccc25233fe4da17d0213050e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6075
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
BSD extension to set both the input and output speed of a termios
structure.
Fixes#18220.
Change-Id: I8c4a06b4be4aa55b8ce35cb7f62552fc47a8e8d0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6049
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
..instead of readv_pos/writev_pos. This way, we can be sure that we
are remapping them properly even under Haiku, as well as remove some
potential confusions.
bfs_shell seems to still work fine on a regular build.
They are not about reading and writing pages, but just iovecs.
As the passed iovecs use void*s, it can't possibly be working with
physical pages on 32-bit systems with PAE.
It appears nothing uses or implements these functions anyway,
as there was nothing else in the tree I had to adjust after making
this change...
* changed explicit locking to use Autolocker for gFontManager/fAppFontManager
in ServerApp, per comments in https://review.haiku-os.org/c/haiku/+/4790
* changed BFont::LoadFont (memory version) to use size_t for size and offset
* no functional changes
Change-Id: I438a4975d5bb1b2fa17bc54e9e171c31dadfeec5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6003
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
"Newer" synaptics touchpad support a new mode where they can report more
information to the host. In this mode, there is a different packet
format for tracking extra data from the touchpad, including a wheel
encoder (mousewheel) if available, and multitouch finger tracking.
This mode is documented in the Synaptics touchpad interfacing guide
(Synaptics document 511-000275-01 Rev. B), but was not yet implemented
in our driver.
It should help with detecting multiple fingers, or finger position on
clickpads to determine right or left click.
This change implements the following items from the Synaptics
interfacing guide:
- Cleanup and clarify the code for features detection to properly report
clickpads
- Enable "extended W" mode if supported
- Process extended W values 0 (mouse wheels, reported in the
touchpad_event structure and could be used by input_server for
scrolling), 1 (secondary finger), and 2 (finger count)
- Fix handling of wValue, which is not always a finger width
- Add handling of vValuen which indicates the finger width when wValue
doesn't
Overall, this should provide the movement_maker with a better picture of
what's happening.
Also improve tracing to show received packets and the corresponding
WValue since that's an important value in identifying which type of
packet it is.
Unfortunately I currently don't have a laptop with synaptics touchpad to
test this with.
Change-Id: If334392f4eb2a146955f6c8c897f0ab64d79b8d9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4425
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Reviewed-by: nephele <nep@packageloss.eu>
This is duplicated across multiple filesystems, and could probably be
used in more still.
Adjusted only BFS, EXT2, and NTFS in this commit, as they are the ones
which make use of fs_ops_support.h already and thus need to be modified
to avoid duplicate-definition errors.
Also tweak next_dirent to support being built under fs_shell.
(Possibly we should define ASSERT there, though?)
Compute a font size that just fits the available space, instead of using
an arbitrary scaling. This makes the code adjust to any font and any UI
size.
Select the appropriate font using a binary search, which will need only
a few attempts (I think 6 font sizes will be tried at the default
config)
Change-Id: Ie3b8678678c0d940981f1785418aa8ab354d01c5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3893
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
This is needed to fix usage of POKE_GET_PHYSICAL_ADDRESS on
x86 32 bits (with PAE).
Change-Id: Ic00185ec7fcf9b6666ad6169a752d8b8edd2b61b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5975
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
This patch adds an API call to BFont, called LoadFont, that
takes a string path to a font file. The user fonts are managed
via a new class called AppFontManager that inherits from the base
class FontManagerBase but adds the methods to add and remove user
fonts from disk or memory. There is also a new method called UnloadFont
to remove a user font, but on exit of an app all user fonts should be
automatically cleaned up.
Global/system fonts are managed by the GlobalFontManager, which is
a new class that also inherits from the base class FontManagerBase,
replacing the old "FontManager" class.
A maximum of 128 user fonts may be loaded, and memory fonts
may not exceed 20MB.
There's also an overloaded version of LoadFont that accepts
an area_id and loads the font from memory. A size and offset may
optionally be provided to allow for an area that contains more
than just a font.
Change-Id: I6add42bdf0c0cefc0e2e2a4984fd848c3e7269e5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4790
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
* aborted transfers will release the notify semaphore when the cancel is notified.
* the allocated buffer would be freed on return, while the usb stack eventually copied
data in the buffer in our back, leading to KDL crashes, because the freed buffer would
be right reallocated for some kernel team structures.
* regression introduced by hrev55806, the transfers didn't need to be cancelled before.
Change-Id: Ifb6e941f71d05c37c36f878059c33883bb72a67c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5905
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* We needed this previously due to our gcc2 compiled kernel.
* Now that our kernel is always latest gcc, we can move to the
c++20 syntax for inline assignment.
* Improves compatibility with clang, less GNU-specific stuff
Change-Id: Ib7272a0a52554a31e9a0e788fd3f031db9049795
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5898
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
we detect basically the cpu info before loading the microcode,
to be able to detect the vendor, and avoid any update on hypervisor.
I couldn't test because my cpu doesn't have any update available.
Change-Id: I6aea830158423b3ee13b640be8a788fc9041e23c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5859
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
the entropy source is read every second and pushed to the PRNG.
the PCI device is tested, not the ACPI.
Change-Id: I9bb6b21c7189b28a1d8a624d83b33ff6682152dc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5825
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
tested on Zen2 (Ryzen 3 5300U)
This support was submitted in October for inclusion in Linux.
Haiku supports only two profiles. We could probably add some more, and let the driver says which it supports.
Change-Id: Id7754b445bc32a691d58a1e4af630351562abc22
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5826
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
remove the yarrow module. the hardware modules can push entropy with queue_randomness().
virtio_rng will now push entropy every 300 seconds.
helps with #14937
Change-Id: If76c5deabf61dc616a0e051332f44b89deb6b8a1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5824
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
There's currently no way for an application to convert between view and
drawing coordinates with a drawing states stack without keeping track of
all the transformations itself, which is not very convenient for helper
or library functions.
Handle other spaces too, for good measure.
Change-Id: Ic8404a1c111e273fff1eebf2f9f59f58246b796c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5775
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
C99 chapter 7.18.2, Limits of specified-width integer types:
"This expression shall have the same type as would an expression that is
an object of the corresponding type according to the integer promotions."
C99 chapter 6.3.1.1:
"If an int can represent all values of the original type, the value is
converted to an int; otherwise, it is converted to an unsigned int.
These are called the integer promotions."
Therefore, UINT8_MAX, UINT16_MAX, UINT8_C and UINT16_C should be signed.
This prevents building WebKit with -Werror.
Change-Id: Ib2a2c15acc2c761cccf8caa016c7ff163e3fdc0d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5806
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Fix regression that building Haiku on 32 bit Haiku become not possible.
Change-Id: I527a8c3bc3ad4744d5515a76888d5cac06293cbe
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5750
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
