At present there's only ever one global one, so we don't bother using
an array for multiple screens (and we don't support multiple screens
yet anyway.)
This fixes a very old TODO, and avoids sending a ~32 KB port message
on every application startup.
Note that this breaks the app_server protocol ABI.
* Sentence casing
* Sort "Delete" in context menu to the bottom.
* Added BSeparator before "Delete" item to have this destructive
action stand out.
* As bookmarks often have spaces, put their path/name in quotes.
* A bookmark path can be long, better start it in a new line.
* If the bookmark was successfully deleted, but removing it from
the bookmark bar failed, we don't need to add the full path to
the alert text, just use the name (= Leaf()).
* Fixed wording of error text when removing a bookmark from the bar.
Change-Id: Ie3cf32325bf77ca9fa5b60e3a49f02baae268090
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8771
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Adjust some nfs4 code depending on _KERNEL_MODE / USER.
* Add several functions needed by this driver to kernelland_emu.
* Fixes #15556.
Change-Id: I36c1727d9cff088aa93870806bfe69b46dbdd4e2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8712
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The size classes between 4096 and 8192 are very infrequently used
on both 32-bit and 64-bit; a total of 25 objects isn't uncommon
to see across all of them (while 4096 had 68 used objects and 8192
had 49.) We might as well consolidate these and add size classes up to
16384, to take some pressure off the raw allocator.
On x86_64, it seems that we wind up allocating a large number (> 1000) of DMABuffer objects that wind up in the class for 10240, so this
probably saves around 2 MB or so vs. using the raw allocator.
The other new classes have more minor usage (6, 5, and 14 respectively.)
During builds, there are a lot of process arguments (+ environs) that
add up to values between 8K and 16K, so this will benefit that too.
The block size classes seem to not have been changed since their
original introduction in hrev20896 (2007).
Change-Id: Ifff73ed97adf01739fad7f70a1129066925d4b4f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8763
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Every shell execution creates and destroys a FIFO, it seems,
so it's good to avoid the raw allocator (and thus the kernel
VM translation map) here.
After this change, the only remaining use of the raw allocator
during a rebuild of HaikuDepot + the mime_db is the flatArgs
malloc(), and the change to increase the block sizes to 16K
will reduce that to a small number of calls.
* Rename function pointers in struct device for consistency,
and adjust all consumers. Use a switch() in the loop over methods.
* De-indent some code where possible.
* Remove an obsolete comment.
This isn't the BSD behavior, but it saves a lot of time in allocating
large softcs (many larger than the block allocator can handle) as
well as method lookups.
Only one in-tree driver actually seems to try and use the softc
during probe: broadcom570x. We can just add a small patch for it
to skip that set when sc == NULL, as nothing in the method
dereferences it.
Tested with ipro1000, rtl81xx, realtekwifi (USB), all still work (and
of course all other drivers' probe() are called every boot, so
those at least don't have problems when the devices aren't present.)
The IDs were introduced for iflib support, but we can make use of them
in here as well.
Also expose the "resolve_method" function for internal use.
Shouldn't break anything; BSD drivers still seem to work.
This way, we significantly increase the FD table sizes that can
be allocated without needing a "raw" allocation: previously
an FD table size of 512 would've been too large (on x86_64),
while now, tables of up to size 1024 will fit (so long as the
largest block allocator size is 8192, anyway.)
Adjust vfs_resize_fd_table to support allocating tables when
none have been allocated before, and then just use it in
vfs_new_io_context rather than doing the same calculations
and allocations.
No behavioral change intended.
We already didn't inherit FDs, which meant that the only thing we
did meaningfully inherit was the table size. That meant that basically
no applications actually had a table size of the default 256, but all
were at the kernel's 4096 (except Tracker and anything started by it,
as Tracker resets it to 512), and also that basically all applications
had FD tables allocated with the raw allocator instead of the block
allocator, which isn't very efficient.
Since this reduces the default FD table size, some applications
might encounter problems. However, build systems and other such
tools should already increase this by default as needed, and it's
easy enough to patch in calls to setrlimit() if it turns out
some applications needed a higher default after all.
Also remove a redundant call to vfs_exec_io_context. Calling
vfs_new_io_context with the second argument set to "true"
already skips cloning CLOEXEC FDs.
In most cases, we just need a read spinlock and then atomics
when updating this value, significantly reducing lock contention.
But this also paves the way for the use of these methods in
page-related hot paths, e.g. for reserving memory as well as pages
when mapping page tables.
Now that we don't wait the full timeout in most cases, this "optimization"
isn't really necessary; and it was also preventing reserving amounts
of memory that would require both RAM and swap, which is suboptimal
but there's not really much reason to prevent it.
Previously, we would run the low resource manager continously in
a loop until reaching the timeout. This used up a lot of CPU
needlessly, because if the manager fails to release the memory
we need in the first few runs, it's unlikely to do so later.
We could add another waiting mechanism here, but ultimately
it seems to make more sense to just fail early before reaching the
timeout at all, in this case.
Improves system responsiveness under high memory pressure.
vnode_used also acquires it, and acquiring a read-lock recursively
is illegal and can lead to deadlocks. Holding it across a vnode
lock acquisition isn't a good idea either. We only need it to hold it
before acquiring the unused-vnodes lock, and we can actually skip
acquiring that a second time altogether.
Should fix a deadlock observed by PulkoMandy.
Having "Notification" at the beginning of the sound names makes
sure their entries in the Sounds preferences are always next to each
other.
Change-Id: Ia47431ecd4c5e8c346f1417a4d29a151c06217cf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8737
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
If we fail to look up the chain, we won't uninitialize the protocols,
causing a memory leak (or even dangling references.) Add an ASSERT
that would have caught this problem.
Fixes a memory leak when using raw sockets.
Zstd wants a ~90 KB scratch buffer to decompress our 64 KB chunks.
Rather than let it allocate that itself every time, pass in a 2*64KB
"scratch" buffer and statically allocate the working memory from it.
Pass it down using iovecs, and pass down the other buffers in the same
way, to reduce parameters.
Further, rework the object_cache used for heap decompression buffers
to contain objects sized as 4x64KB, so we only need to do one allocation
and deallocation for the compression/decompression and scratch buffers.
Set the minimum reserve to 1 so that the low-memory manager doesn't
reclaim this, as we'll need it when reading back data.
Improves packagefs I/O performance (and thus boot speeds at least a bit,
it appears.)
Change-Id: Id51f6f598b33b9d757a283184c533bb97049529f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8717
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
This adds some new parameters to UnmapPage and UnmapPages. The important
one is a "_flags" pointer to UnmapPage, which if specified will be
filled with the page flags instead of PageUnmapped() being called
(and Flush() won't be invoked, either.)
This removes the remaining PAGE_STATE_* changes from VM architecture code.
Change-Id: Iacbc424dd8a75a79986edcd7f04d15a10f773c87
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8728
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Using "SndFilePanel" from Be Sample Code by Todd Thomas with only
small changes.
* Removed check for audio file in B_REFS_RECEIVED, because the file
panel uses a BRefsFilter.
* Reset file panel location in case the panel was canceled.
* Use entry.IsDirectory() instead of entry.GetStat() for simplicity.
Change-Id: Ibb4a4cb8e3c4b60c85a9ba0b2e5287416bbc4b44
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8736
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* Prevent the userlandfs server from calling clone_area on an area
that might have already been deleted.
* _HandleRequest(FileCacheReadRequest*) waits for a reply from the
server when bytesRead > 0. This ensures that the server has time to
use the area holding the returned data, before that area is deleted
when the RequestAllocator goes out of scope in the kernel add-on.
However, if bytesRead is 0, the server will still call clone_area,
even though by that time the area has probably been deleted. This
leads to a B_BAD_VALUE error when the FS tries to use the emulated
file_cache_read at the end of a file, which differs from the
normal behavior of file_cache_read.
* _HandleRequest(ReadFromIORequestRequest*) has similar logic in that
it waits for a server reply, but not if size == 0. It's possible
that a similar problem could occur here. This test can be
dropped if no requests with size 0 are ever sent from the server to
begin with.
* For other _HandleRequest overrides, the kernel never waits for a
server reply, and this causes no problems. This could be because the
size of data returned fits in the port buffer, so no external area
needs to be created by RequestAllocator::AllocateAddress.
Change-Id: If070901c25d446e00e67a74a7883808d8a38dae2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8721
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
In a basic test, I only saw one page of memory unreserved this way,
though.
Change-Id: I153bea280e26bee0d5b3159b24719f549b7b5178
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8724
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
All consumers of this API should be adjusted here.
This partially paves the way for use of committed pages for page tables.
Change-Id: Id6fc2edc86fbd80e929c413e23cf8de1509a8215
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8723
Reviewed-by: X512 X512 <danger_mail@list.ru>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
An extra argument is added to allow the VMAreaMappings objects to
be added to a queue instead of freed directly (and the lock unlocked,
and so on.)
All architectures adjusted.
This means there is now only one place in each TranslationMap that
the page state and other data is directly adjusted (in UnmapArea).
Change-Id: I3ed2d6d969d1b1e235144a1035c90c750779af27
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8716
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: X512 X512 <danger_mail@list.ru>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Add some parentheses for clarity.
* Remove a comment about unreserving pages. In fact this method is
always called with pages already reserved, and in the path the comment
was in, we wouldn't want to unreserve anyway, because we've
successfully allocated.
* Use a boolean rather than an int for "useCached".
No functional change intended.
Besides the already set sound files, the Sounds popup menu shows
the files of all the B_*_SOUNDS_DIRECTORY.
As people/packages may sort sound themes in sub-folders there, only
add files from there to the menu, no folders.
Change-Id: I79cda5d547fc1a0ec0234384e3b76f2c455b2881
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8722
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Default to B_SYSTEM_SOUNDS_DIRECTORY (if it doen't exist, the
home folder gets set automatically).
* Save the last used path in the Sounds_Settings file.
* If the last used path isn't valid any more, default to
B_SYSTEM_SOUNDS_DIRECTORY.
Change-Id: I90bf7e640e648e6e7dfc2941440550cb074c18f0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8704
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
* HOST_CPU was getting set to "" on arm64 host builds of
Haiku which resulted in varying host tool directories
objects/linux/x86_64/release vs objects/linux/release
* This captures the changes in buildtools abcf50c2 which
adds proper arm 64, and riscv 32/64 OSPLAT definitions
Change-Id: Ife768fe3e4b1f90748b8f09afd632d4cd9c87d2d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8720
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
