When you download a file, the Downloads window is opened to show
the progress etc. This is good, but once opened, it shouldn't
get activated (= pop to the front and getting focus) for each
new download. Often you've continued scrolling a webpage and when
the download finally starts, the DL window steals the focus...
Change-Id: Icdbd6bc5e2f0441eff650428834348f3fb508906
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8799
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
* There's no such thing as zstdSources anymore, put the real
file in here.
* Move the zlib Includes up, so they match.
* Slightly reorder the logic inside the "if" to better match
the Support Kit Jamfile.
Fixes a missing dependency on the Zstd headers.
* Prevents us breaking a potentially working serial uart.
Change-Id: I57bed42cfa571d3d961ee07f380c96b62c7f34d6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8798
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* If we don't find a clock frequency, it can be worked around later
in a critcal code path for uart. Flag a failure or unknown with -1
Change-Id: I34d078da7471f559aafcf8926dc646aa9a7d4867
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8797
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Alexander von Gluck <alex@terarocket.io>
In #19343 it appears that read_pos returned "No error" but 0 bytes read.
We need to return an error code in this case, lest whoever called us
think the block was read in correctly after all.
Nothing uses it at present. This saves 8 bytes per PackageNode on 32-bit
and 16 bytes on 64-bit (mostly just EFI). We allocate a PackageNode
for every file in haiku.hpkg, so this is a significant savings in
the small bootloader heap.
This is more efficient and works most of the time. Additionally,
we can potentially join with a previous free chunk in the allocator,
avoiding extra fragmentation on the heap.
app_server (on x86_64) only has 1 "rld heap" area after this change
with a size of 0x50000 (320KB), whereas previously it had around 7
with a total size of 0x80000 (512KB).
The old define was really "check heap integrity", so it's split off.
In the userland test harness, this takes the total time spent in
the allocator from around 1ms to 14ms for all the allocations used
during a boot with "nightly" profile, so it seems acceptable to
enable it under KDEBUG.
Tested with both BIOS and EFI bootloaders, still works.
This uses a recorded array of allocation operations and "replays" them.
The included .h with such an array is mostly for demonstration; the
real captures from bootloader logs are very large (half a MB or more)
and so not included here. A small node.js script that can generate these
from such logs is included.
They were mostly copies of one another, save for the glue code
and a few other things. Now they're mostly unified, and this allows
the test to be greatly simplified, too, since it can avoid including
any bootloader code at all.
The heap implementation itself should have no behavioral changes
from before. Those will come in future commits.
They were hand-rolled singly-linked lists before. This adds 24 bytes
of size to the Team structure, but turns all the removal operations
in parent and process group into O(1) operations instead of O(N) ones.
Realistically, the Thread linked-lists should be converted as well,
but this is trickier due to interdependence on the Team structure.
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>
