This way, we can avoid printing anything if the superblock magic
doesn't match (i.e. the partition doesn't look like it's of the
filesystem), but print an error if the magic values match but the
rest of the data doesn't.
Reduces syslog spam.
* Remove the "pause" indicator; it adds too much noise at small
sizes and seems confusing at large ones. Instead, draw the
battery in a blue color when it's not in use.
* Reverse the direction of the battery bar. It now has the capacity
on the right and the empty on the left, the opposite of the way
regular progress bars are, but more in line with how this is
displayed on other OSes (and smartphones.)
* Tweak ratios to make the icon display larger in the deskbar.
It now displays closer to the size that regular icon views do.
* Tweak the lightning indicator to be a little larger, also for
legibility at smaller sizes.
* Other misc. cleanups.
Change-Id: I229fe120e769e43e17eeb87638b832418f5e7aaf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8690
Reviewed-by: Sen Nordstrom <haiku@sen.cx>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
List only the packages that are not required by any other package.
Most useful then used as "pkgman search --installed-only --non-required",
but works for non-installed packages too.
Based on OscarL's initial version, rewritten by me to use the real
dependency resolution system instead. One tweak from madmax to get
it to actually work properly.
Co-authored-by: Oscar Lesta <oscar.lesta@gmail.com>
Otherwise esc closes the file panel.
Differentiate between type-ahead and ref filtering in pose view
which is why this was not working in e.g. Expander a ref filter
was set so filtering was also set. We only want to cancel
type-ahead filtering on esc, not ref filtering.
Refer to 'ref filtering' as simply filtering e.g. IsFiltering()
and refer to type-ahead filtering explicity when that is meant.
Rename methods and variables to make it clear whether we're
referring to ref filtering or type-ahead filtering.
If we are ref filtering fill out the filtered pose list again
after stopping type-ahead filtering so that we don't get an empty
file panel in e.g. Expander on esc.
Fixes #13151
Change-Id: I96faf98c3b68d3bcb3d3892c3511ae2449c2f8a4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8689
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
It is not used anymore and is very slow on real hardware because it read
GPU memory by CPU.
Change-Id: I06f7ca072220b758d849921e844bb2aa75342e2c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8680
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Some 100 char fixes
Put looper in a variable and use it a few times
Remove ASSERT statements, we B_DISPATCH_MESSAGE if NULL.
Refactor command modifier key code to use a nested switch
Explict comparisons to NULL
Change-Id: I068a0123461290731b4b5388b802bb4cc7bb2455
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8688
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This reverts a8877df135.
Previously, the "unmergeable" flag was necessary for the RAMFS,
because if the last vnode reference was released while there
was still a consumer (as the old ordering of _RemoveConsumer
had), then the release of the cache reference when the vnode
was removed would result in the cache trying to merge with
its now-only consumer and sole referrer.
Now, instead, we remove the consumer before releasing the store
reference, so that there's no chance the cache will be merged
inside this method.
mmap_cut_tests still pass, web browsers using ramfs shared_memory
still seem to work.
This way, if the Resize() is supposed to take care of the commitment,
it will (and will fail early if it can't), while if we are the ones
responsible for adjusting the commitment, map_backing_store won't
commit at all (avoiding committing far more than will be necessary),
and we can just steal the commitment from the first cache for the second.
This reverts 3a81e9446d (2022).
That commit fixed #17556 by just checking if the area had an
underlying cache that wasn't a RAM cache. But there are cases
where there will be RAM source caches that we have to take
into account, too, not just vnode caches or the like. The
most common example of that would be all areas of a team
after a fork(); the original pages will be in a read-only
source cache.
This commit fixes the real underlying problem: if the first area
has a source cache, then the new second cache needs to have that
as its source, too; and furthermore must have the correct offsets
in order to access its pages correctly.
The test for #17556 that was added in 9ed77019b6
still works as before, as do all the applications I tested that
use cut_area. Some assertion failures that the cut tests triggered
(related to commitment sizes) are fixed by this, as well.
This also seems to fix the remaining instability on fork() in the
boehm-gc's "gctest".
The page_protections aren't changed at all, so all pages that exist
should already have the same protections as are specified in the array.
The only thing different is what cache and area they now belong to, but
the VMTranslationMap does not care about that.
So we don't need to loop over the pages and re-protect them in this case.
We already didn't for all cases where no page_protections were involved.
(It seems this logic was introduced in bdcc293fa8
along with general page_protections support in cut_area.)
When the area has no page_protections but isn't writable,
we also want to use a smaller-than-default commitment.
So, adjust compute_area_page_commitment to handle that case,
and then use it in cut_area where appropriate.
cache->virtual_base is the cache's start address, which no pages will
be found before. area->cache_offset on the other hand is the area's
offset into the cache (i.e. offset 0 in the area will be offset
0 + area->cache_offset in the cache.) These addresses may well be
the same (even if they're not 0), and in many situations they are,
but in situations with shared or cut areas, they may not be.
The only thing that uses this method is madvise(MADV_FREE), which
probably not many things besides the guarded_heap use at present.
We shouldn't return B_OK here, because then the page writer will
assume it's acquired a store ref and can write pages from this
cache, when of course it's done nothing of the sort.
Previously, we'd wind up adding pages from the source to the consumer
that were potentially or actually outside the consumer's bounds.
Now we check the consumer's size and ignore any pages that we don't
want or need; they'll just be freed along with the source cache.
While at it, drop VMAnonymousCache::_MergePagesSmallerSource; it
was the same as the base class's implementation of Merge preceding
this commit; and add a comment to _MergePagesSmallerConsumer noting
that some of the pages may be busy (indeed, I manage to trigger an
assert related to copy-on-write in here at least once.)
I discovered this problem because the page commitment size ASSERT()s
triggered inside Resize() and Rebase(); but the out-of-range pages
already existed in the cache before those functions were called. So,
I've also added an ASSERT to MovePage() that would have caught this
problem more directly.
The original meaning of vfork is "fork, sharing virtual memory" (until
exec). We don't implement that, and may never do so. However, since
calling any functions besides exec() in a vfork'ed child is "undefined
behavior", we can take advantage of that fact at least by not calling
any of the pre- and post-fork hooks, saving a lot of page faults from
copy-on-write.
On one run of the "compile HaikuDepot and the mime_db" benchmark with -j4,
the total waits count on the top two VMCaches by contention dropped
from 62125 and 58927, to 52034 and 41225.
musl apparently does more or less this same thing (vfork() is fork()
but without calling any of the hooks.)
The first was added in 2004 when there wasn't even a branch for
initializing the child; I think this can be considered done now.
The second was added in 2010, but it seems in the meantime we've
decided that reinitializing locks is the best way to make them
consistent after calling fork(), so it's also obsolete.
Otherwise, platform loaders couldn't make heap allocations inside
platform_start_kernel(), which some loaders (e.g. EFI) do.
Implement calling heap_release() for the BIOS loaders at least.
This gets us back the ~1.5MB of bootloader heap memory there.
Only show ratings UI elements when
the package could be rated
Change-Id: I4f464e2cb21f927186c0ffdddbc5c11498ffed31
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8678
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Rather than setting it from the total count of pages, and then reducing
it by the size of the B_ALREADY_WIRED areas incrementally. This means
that other things allocated in the early boot period (like page tables)
will also be accounted for. The downside is that, if they don't have
a corresponding area, then any pages freed later on won't also unreserve
memory at present; but the early boot page tables likely won't be freed
at all (since they'll be in use; or should have already been freed in the
case of the 32-bit to PAE transition.)
(In the future, we should reserve memory as well as pages for the page
tables, and that will take care of that problem anyway.)
Booting x86_64 in QEMU with 1GB of RAM, the old accounting method produced
an initial (after ALREADY_WIRED accounting) sAvailableMemory of 251,368
total pages, while this new accounting method gives 250,812 instead,
a difference of 556 pages. (Some of that is probably the never-freed
bootloader memory, which I think is around ~360 pages.)
Overall this should reduce the amount of "theoretically available but
actually inaccessible" memory, which should hopefully help with the VM
getting itself into trouble thinking memory is available when it
really isn't.
Fixes the code I introduced in hrev50114 for custom serial port
baudrates. The idea there was based on FreeBSD implementation, but I
missed a key detail: speed_t in BeOS (and Haiku) is only an 8 bit value.
Note that BeOS does not have c_ispeed and c_ospeed fields, instead they
are named c_ixxxxx and c_oxxxxx with a comment in termios.h saying that
they are not used. So the renaming and moving of these fields isn't a problem.
This means the previous code worked only for speed between 20 and 255
baud, quite the opposite of what I wanted to do, which is to enable
access to fast baudrates.
This new implementation exploits the fact that tcflag_t is 32 bit, but
we never actually use more than 16 bits. Therefore, the high bits of
each value were unused, and can be reclaimed to store the speed,
by changing tcflag_t to 16 bits. The speed is then inserted as two 16
bit values that can be combined as a 32 bit one. The flag bits are not
moved (on little endian systems), and the extra values are guaranteed to
be set to 0 by any previous code that was compiled with 32 bit tcflag_t.
Support for different speeds for input and output is now also possible
(POSIX specifies separate functions for setting the input and output
speeds, which is useful for some old terminals and modems, where it was
useful to have a high baudrate for data to display on the screen, but
things typed on the keyboard aren't quite as fast). If desired, we could
now properly implement this in our serial drivers, but it isn't done
here yet.
Additional changes:
- speed_t is now a 32bit type, allowing to pass large values to
cfset(i,o)speed
- fix some places where a baudrate enum value was incorrectly put in the
c_ispeed and c_ospeed fields, this is not how they were meant to be
used (it meant the default was to use a speed of 0, that means "hangup"
the line, which I think no serial driver really implemented).
- do not put baudrate enumeration values in c_iflag and c_oflag, they
are meant to be used in c_cflag only, and conflict with other bits.
Separate speeds for input and output can be done by setting the
c_cflag value to CBAUD (indicating custom baudrates) and then setting
the values in c_ispeed and c_ospeed.
Fixes #18483
Change-Id: If63a24b5ced5edf6d051d921197db194def0c614
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7068
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
See inline comment: we can potentially wind up with conflicting mappings,
depending on what the system ACPI firmware tells ACPICA to do, so it's
best if we avoid using non-default types on architectures where they
aren't strictly necessary.
Fixes #19119 and related issues.
