On 32-bit at least, our ASLR is too aggressive and fragments
the address space very quickly to the point where at 500MB (1/4)
usage, area insertion begins to fail.
We want applications to be able to handle out-of-memory
conditions gracefully, not just trigger an assert every time.
I disabled this before, looks like I missed it in the final
patch.
The Device object gets an ID before it begins initializing, and
loses its ID after it fully finishes tearing down, so simply
verifying the Device object is non-NULL is not enough to verify
that we can use it. We need to call InitCheck() every time.
In Device itself, we should also unset fInitOK when beginning
teardown, so that anyone who still has a handle can no longer
use this Device object while teardown occurs (which, depending
on the number of pipes, pending transfers, etc. may take some
time.)
Fixes#14949 and almost certainly any other USB-related KDLs
in these codepaths.
All of Barrett's individual reverts have been squashed into this
one commit, save a few actual bugfixes.
Change-Id: Ib0a7d0a841d3ac40b1fca7372c58b7f9229bd1f0
SuperSpeed (USB3) devices have a "companion descriptor" along with the
endpoint descriptors that describes certain other attributes they have,
which are important for the controller to schedule transfers properly.
Previously we were just using USB2 values; now we are properly using USB3
ones.
Tested on an Intel Lynx Point controller. As far as I can tell, no
regressions, but #15000 is not fixed anyway.
It has lower overhead and allows to name the areas so that they are
labeled as heap areas.
Note that we can still use munmap for releasing. It has the nicer
interface of using the base address and length which we already know
instead of needing the area id that would have to be queried with an
additional syscall.
Change-Id: I338c4043ecc2947b82b8fe9fd69a99ce3fa23138
Hoard, the LGPL-licensed locking thread-caching allocator that we have
used by default since libroot's introduction, is showing its age.
It is a "pseudo-sbrk-based" allocator (it predates our actual sbrk,
so instead it uses a single Be area), which has serious limitations:
as we cannot ever move the area, we can only resize it "in place",
and so once we hit the end of the ~1.5GB reserved part of the address
space for the heap, we are usually out of luck if we need more memory.
On 32-bit userspace has only 2GB of address space anyway, but on
64-bit where address space is not a resource worth worrying about,
this can be a serious problem for applications that want to use a
lot of RAM. As more and more large applications get ported to Haiku,
the time for a mmap-based allocator has come.
For posterity's sake, here are all the possible options there were,
and why this one was selected rather than one of them, beginning
with the immediate rejects:
* nedmalloc. Unmaintained since 2014 and all benchmarks show it
underperforming vs. virtually all other allocators.
* bmalloc. Significantly worse-performing vs. other options on
this list with no apparent advantages.
* hoard3. Now GPL only, which is obviously not acceptable for
use as a system library.
* ptmalloc2. glibc's default allocator; underperforms vs.
even most of the above-listeds.
And now on to the honorable mentions:
* tcmalloc. This is Google's allocator; it's designed for server
and other high-performance workloads. As a result, it almost
never unmaps memory unless ordered to do so in a very explicit
way, which obviously is unacceptable behavior for a general-purpose
allocator.
* jemalloc. This is FreeBSD and NetBSD's default allocator as well
as finding use in Firefox and Rust. It is again designed for
performance, with significantly higher memory overhead than
other allocators, especially for small heaps; which is of course
a problem for us, as we want to retain our light footprint.
Finally this brings us to rpmalloc. It's not as well-travelled as
tcmalloc or jemalloc, but by benchmarks done by itself [0] and
by developers of other allocators [1], it seems to typically hit
the "sweet spot" of very good performance with lower (if not the lowest)
memory use out of all the other allocators it's tested against;
even beating jemalloc in certain benchmarks for speed, too.
You can see a description of the allocator's design in its README [2].
[0]: https://github.com/rampantpixels/rpmalloc/blob/master/BENCHMARKS.md
[1]: https://github.com/ezrosent/allocators-rs/blob/master/info/elfmalloc-performance.md
[2]: https://github.com/rampantpixels/rpmalloc#rpmalloc---rampant-pixels-memory-allocator
In general testing thus far on Haiku, it appears to be a consistent
5-10% performance boost (1m28s real -> 1m23s real) when doing
the "HaikuDepot compile" benchmark. Memory usage by most apps
after a cold boot changed negligibly (launch_daemon: 444K -> 476K,
app_server: 15.86MB -> 15.49MB, Tracker: 6.19MB -> 4.49MB.)
The only adverse affect I have observed so far is that a certain few
WebKit double-frees cause crashes/asserts faster than they did before
(e.g. Google Maps crashes after less than a minute instead of a few
minutes.)
That being said, any new or strange behaviors, please report
immediately. Backing out this change should be as easy as
reverting the changes to the libroot/posix Jamfile. If nothing
else comes up in a few weeks, then I'll remove Hoard from
the repository.
Fixes#13554.
Change-Id: Id2871601b1e99dcf022fbef2c53008ee6c3f233b
This allows cpu_type.h to be used in C-based software,
with the get_cpu_*() functions all accessible via C as well
as C++ code.
Tested changes with sysinfo, AboutHaiku and Pulse.
Change-Id: Ide87d8e3f2ba5f0f1890f385b1ac90c677bcc274
Reviewed-on: https://review.haiku-os.org/c/1453
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The HaikuDepot application has, thus far had its
own hard-coded list of languages that the user is
able to choose when (a) creating a new account or
(b) creating a user-rating. This change will mean
that those languages are loaded from the HDS
server dynamically and in this way the user can
choose from the full list. There have also been
improvements to the way in which the languages are
displayed in the menu as well.
Change-Id: If7cb7b87f348ca59d503d276a22444e72d0e6168
Reviewed-on: https://review.haiku-os.org/c/1425
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
some ops want an integer value instead of a pointer as arg parameter ( #15058 ).
http://pubs.opengroup.org/onlinepubs/9699919799/functions/ioctl.html clearly specifies that:
"The type of arg depends upon the particular control request, but it shall be either an
integer or a pointer to a device-specific data structure."
add a test for functions which should return ENOTTY as errno.
Change-Id: I4a98af73b17c79c3460123d3794ee866f8719898
Reviewed-on: https://review.haiku-os.org/c/1447
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
According to the HID Usage Tables document (Hut1_12.pdf), the In Range
usage is a Momentary Control (MC) (par. 16.3.1). A MC has a Logical
Minimum of 0 and a Logical Maximum of 1 (par. 3.4.1.3).
As the In Range usage is a bit quantity, the value can't be outside
the Logical Minimum and Maximum and therefore can't be in an invalid
state.
Now the inRange boolean value properly changes.
The pointer still moves to the upper left corner when the pen is out
of range, though. Maybe the input_server add-on doesn't use this value?
Change-Id: Idf511ac237158e90eb2e8f01422757655a7eea3a
Reviewed-on: https://review.haiku-os.org/c/1449
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
When the pen is moved out of range, the Wacom tablet sends one last
message with all values set to 0 and the In Range value set to false.
Don't send mouse event messages in this case.
Change-Id: I419d57cede47a6ef40a160322f3025ef372ecaa3
Reviewed-on: https://review.haiku-os.org/c/1448
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
Repository processing triggers HAIKU_REVISION computation, and it
is intended that the UserBuildConfig can override or set HAIKU_REVISION.
Fixes#14834.
Just does what the name says
Change-Id: I6cf23f997ce544df83d4ef2f73a3b130dea8825c
Reviewed-on: https://review.haiku-os.org/c/1432
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
Very simple for now, just reuses the Haiku one with some gradients
removed.
Add it to the haiku_extras package.
Change-Id: I41729ed65b147fed72bf56e7c5c89367b75563bb
Reviewed-on: https://review.haiku-os.org/c/1431
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
app_server just passes the add-on path around.
Maybe we should make sure the add-on can be loaded when setting it.
Change-Id: I3acd3299782a22c1666bd5435dbf3d8053e359fa
Reviewed-on: https://review.haiku-os.org/c/1430
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This makes the output much easier to read (e.g. "write(...)" vs.
"_kern_write(...)") and similar to strace/dtrace/etc. output
on other platforms.
Change-Id: Iac8e32aae0dcf3731a348c6192203f8d5b54da7a
Reviewed-on: https://review.haiku-os.org/c/1451
Reviewed-by: Bruno Albuquerque <bga@bug-br.org.br>
- Did not see his comments before pushing my previous change.
- clear owning flag when passed value is NULL.
Change-Id: I493973aff2b107785c3734847c85a52f0f9da360
Reviewed-on: https://review.haiku-os.org/c/1443
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Fixes#15056.
Change-Id: I48c00b955346971aa88b731ccad1953a4044983d
Reviewed-on: https://review.haiku-os.org/c/1442
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
- Keep track if the softc was allocated externally or not.
- Only try to deallocate it if it was allocated internally.
Do not try to free the softc if we were not the ones allocating it.
- Avoid a double free on consecutive calls to device_set_softc.
Change-Id: Ibb38e54e9dfd2a80dbb53920970bead626da8ba1
Reviewed-on: https://review.haiku-os.org/c/1441
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Since not everyone likes the default, make it an option in the vesa
settings file. Note setting a mode with the Screen prefs overwrites
the file so it will discard the option.
Also move the code to get_mode_from_settings() since we can't load driver
settings as early as vesa_init().
Change-Id: I93080bd1fbc064dab053624ad37935268b1ed17d
