All other uses of this definition was removed many years ago...
In addition, I'm certain this aspect of POSIX support is complete now.
Change-Id: I309779d8e895efeb6b2b7c107bf2ef038d0a6612
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8458
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Another regression from hrev58236: the code assigned start then size
previously, but there was another temporary that made things work
properly that was removed in that commit.
Fixes #18140.
1. fOnline made sense when APM was the dominant power interface
("online" is "charging" in APM-speak) but it's confusing now that
ACPI is the primary system and specifies more granular status.
Eliminate fOnline and check specifically for charging or discharging as
needed instead.
2. In multi-battery setups batteries that were neither charging nor
discharging were shown with the lightning-bolt charging icon due to the
lack of granularity in fOnline, now shows a paused icon instead.
This solves the first point in #19167.
Change-Id: If723b6b9a4695427d09075680a8ef435b3c1ac54
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8456
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This reverts commit 8b813adf6df7c4ec2c988888a5b6ef2e398aa103.
This does not properly handle the case of 32-bit page tables that
the kernel will continue using (i.e. non-64-bit, non-PAE). So,
some other solution will need to be found to not leak these
and the bootloader heap.
* Minor tweaks to POSIX sys/param.h for style.
* Don't redefine alignment macros in BSD sys/param.h even conditionally.
And add a few more macros from the real BSD sys/param.h, for convenience.
(Most of these are also declared in musl and glibc's sys/param.h)
This reverts commit b6554e72fc67652007c4d06317144af6427f0681
which added the --with-python flag. Using environment variables
to specify host and cross tools is how the rest of this script
behaves, so let's be consistent.
Fix different order of arguments between definition and declaration
of TTracker::SelectChildInParentSoon() and
TTracker::SelectChildInParent().
Pointed out by cppcheck.
Change-Id: Ie78089c80d77f8f687fb9e63883f0ce7b2e2785c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8379
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Fix different order of arguments between definition and declaration
of BAlert::_Init().
Pointed out by cppcheck.
Change-Id: I59af49f8d8789bc96df8ad6da6bc499d322771d0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8378
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Some systems may be using wget2 symlinked to wget (Fedora,
currently), which doesn't support --retry-on-host-error.
Change-Id: I9fac080e7ac1cc4c39a03f6c27e9c42f8697ecff
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8336
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
on a fresh Haiku install, Printers window title is hidden
due to the window position. Also use a better filename
for the window position settings.
Change-Id: Iee6a8fd0d992c5265f07082e5df99c577433b21d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8420
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
In testing, the allocation sizes I was seeing were all multiples
of the page size anyway, but of course there's no requirement
that they are, so we need to round here.
Pointed out by mmlr.
Just start the kernel allocations after the end of the identity map
(i.e. the first 8 MB of RAM.) This way, we can avoid putting the
bootloader heap and page table memory into the kernel ranges
at all, which avoids leaking it.
Technically reverts 039f93ce5eeef9ff027f71ad6b69c9bc78c2b0fc,
but just moves the call elsewhere.
Should fix #19164.
Change-Id: I3f240d4a28a4ec522382440944a3c80a74bbaa0e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8445
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The most likely case is that the last range is the one we actually
want to try expanding, so this should be a slight efficiency gain.
But it also will help in avoiding allocating "low" memory when
it isn't necessary.
This way, the Pipe won't be seen as "idle" when there are still
transfers in flight with references to it.
May help with diagnosing or even outright fix #17549, #18768, #17799
and #17348.
This avoids leaking the bootloader heap memory into the kernel.
Ideally it'd be dropped automatically, but in seems in many cases
it isn't (even on EFI).
Adjust platform logic to always remove the physical allocated range,
and ignore the return code and reuse the memory anyway if we can.
Previously, there was only platform_init_heap/platform_release_heap,
which allocated a single static heap region for the heap to use,
and any subsequent heap allocations had to go through the standard
platform_allocate_region, which allocates regions visible both
to the bootloader and the kernel.
But as mentioned in previous changes, it isn't always easy to
release regions allocated that way. And besides, some bootloaders
(like EFI) use a completely separate mechanism to allocate
bootloader-local memory, which will never get "leaked" into
the kernel.
So instead, refactor all platforms to instead provide two
new methods: platform_{allocate,free}_heap_region. On EFI
this is easy to implement; on most other platforms we have
logic based more on the old platform_init_heap or allocate_region.
(On the BIOS loader in particular, we can only fully release
the memory if it's the last thing we allocated in the physical
addresses. If the "large allocation" threshhold is lowered
back to 16 KB, then we are unable to do this enough times
that we will run past the end of the 8 MB identity map and
thus fail to boot. But with the larger threshhold, we don't
leak nearly as much, and don't hit the threshhold.)
This should further reduce the amount of bootloader memory
permanently "leaked" into the kernel's used memory, though
on some platforms it may still be nonzero.
Change-Id: I5b2257fc5a425c024f298291f1401a26ea246383
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8440
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Remove unused SetTo; clear Address/Size to 0 on init.
* Free all LargeAllocations in heap_release. (This method isn't
actually called by default before kernel entry, though, so
it probably doesn't matter much.)
Change-Id: If038274adcd65adae527235d16860af659ef37b6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8439
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Will be used in following commits.
Change-Id: Ica89d28cbf6980aca8dc347dfdcb200a0e637e9a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8442
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It should be OK to call this during kernel startup without using
reservations, since it's mostly used for fixed memory ranges
specified by the bootloader.
Also turn a later dprintf into a panic.
page_num_t is typedef'd to phys_addr_t, so it's 64-bits on 32-bit
platforms with PAE. In fact it's been so since the introduction
of phys_addr_t, so this comment was obsolete from the start...
If the existing allocated ranges are from physical memory ranges that
are just too small, then we'll need to start a new "allocated" range
based on the next-available physical memory range.
Should fix the "PANIC: error allocating early page!" tickets
(i.e. #14659 and friends.)
Not all platforms can properly release memory allocated via
platform_allocate_region() at present; in particular the BIOS
loader seems to (at least partially) leak it. And due to how the
kernel args ranges are handed off to the kernel, it seems
allocated physical pages that aren't virtually mapped are
leaked at present as well.
That seems like a bug that we should likely fix, and moreover
the heap shouldn't use that facility at all (but instead
request bootloader-local memory if possible; on the BIOS
loader that will ultimately go through similar logic, but
on e.g. EFI it will be entirely separate.)
But in the meantime, we can just increase the size of the
"large allocation" threshhold so that packagefs temporary buffers
(of 64 and 93 KB) stay on the main heap, and don't hit that
facility at all. The "maximum boot loader heap usage" seems
to go up by about ~200 KB with this change (e.g. 588 KB -> 797 KB),
so increase the default heap size by 256 KB to compensate.
This fixes most of the rest of #14831: memory usage after the
boot has finished is down by over 100 MB (!). The remaining
problems and leaks can be dealt with in later changes.