* Witnessed at linux drivers/usb/serial/ftdi_sio_ids.h
* I have a 0403:6010 in hand, validated functional
* Looking at the linux code, there aren't any special
cases for these alternate FTDI devices.
* There are a bunch of clones we could add per the above
reference, but lets just support the "official" ones for now.
Change-Id: I4c1aa162b94753431d7497a65f646faec5cccfad
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7902
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Reviewed-by: Alexander von Gluck <alex@terarocket.io>
* Fixes #18595
* Organizes templates to the menu in following order: sub-menus,
directories and files
* Sub-menus are directories with boolean attribute _trk/_template_submenu
set to true
* For now it doesn't change the behaviour of template folders to allow
folders to have content to be copied as I suggested in the ticket, I'll
add that as a separate submission. I also intend to change the behaviour
of copying the templates to happen asynchronously, as if one uses a large
template with current implementation it will cause tracker to be
unresponsive while copying.
Change-Id: I20ea5e3ede0c32df0eacb12df93ae6051654c050
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7832
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Convert users of those and other parameters to the new API.
Fix mouse preferences "Default" button not changing button map.
Change-Id: I9184011fd3067fd0b229e1db6376c1b41f06dab9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7878
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
When reading data, return it from one of the connected devices, or from
defaults if there's none. When changing data, do it for all connected
devices.
Fixes: #16617
Change-Id: I36e0f9929c833905d146d19b02be136a3588026a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7837
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Remove compatibility with legacy settings format.
The preferences app doesn't need to read and save the settings file:
devices are enumerated and their properties retrieved from the
input_server. When something changes, the input_server updates the data.
Change-Id: Id1ea6f2532a1c8a173e9ba9818dd911fd6f4aa10
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7877
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
As discussed in #18339, it seems to make sense to vendor libsolv,
given how closely tied it is to the package kit, the difficulties
of upgrading it without breaking anything (even when using SOVERSION
to avoid conflicts), and other concerns.
We already vendor libraries much larger than this (e.g. Zydis),
so vendoring libsolv seems fine.
At least to the architectures that have stack trace printing code
clearly based on the current x86 one.
Change-Id: I6f28a10234a80ecd464fc640ac1ac26199aa2912
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7906
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: X512 X512 <danger_mail@list.ru>
A stack frame consists of two addreses: a return address,
and a pointer to the preceding frame. The stack trace loop
keeps track of two frame pointers: one to the "current"
and one "next" (next to be printed, really the "preceding" frame.)
However, inside print_stack_frame, the frame we are printing
is not the "current" frame (as the stack_trace method terms it)
but rather the "next" frame: because we are printing the function
which is specified by the "current" frame's return address,
and its stack frame is the one "preceding" with respect to "current".
In other words, what the stack_trace method calls "next" is in fact
the stack frame that print_stack_frame is supposed to be printing.
This was apparent from the fact that print_demangled_call was passed
"nextBp + sizeof(stack_frame)", as otherwise we would fetch the
arguments for the wrong function.
Thus we rename "bp" to "calleeBp", as it's the frame pointer of
the function that was called by the function we are printing, and
"nextBp" just to "bp".
Additionally, while at it, fix the kernel/user space switch check.
As the stack grows downwards on x86, we can just check that the
"current" frame is at a lower address than the to-be-printed frame.
This fixes stack trace address printing on x86. Before this commit,
the addresses column in KDL stack traces was "off by one" (most
obvious in that the first userland stack frame address was still
a kernel stack frame address.)
Spotted by X512.
Change-Id: I111bec4b9dd7aa83fb3f5d528b6a53a48de7db72
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7905
Reviewed-by: X512 X512 <danger_mail@list.ru>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
There was a missing case in reschedule(). Also fix a copy/paste
error in the power_saving logic.
This also slightly optimizes things by having an unset CPU mask
turn into a boolean and be processed separately, avoiding
loops and masks entirely in that case.
Have CPU masks be unset by default for new threads, while at it.
Change-Id: Ic5d000a72839448a2d025cfc99de1ed49c841852
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7900
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
BView and BColumn are owned by its parent objects and deleted automatically.
Fix crash on exit.
Fixes #14535
Fixes #18331
Change-Id: If4bc4268542d4975b60f8f42c2868ec8a1a0a83f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7901
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alexander von Gluck <alex@terarocket.io>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
* Don't write-lock the node when opening or closing a file unless the
node is actually being modified.
* Incidentally, move code from dosfs_close to dosfs_free_cookie. This
is not necessary to avoid this deadlock, but it is more consistent
with the approach of the BFS driver.
* When dragging and dropping a large file (e.g. 100 MB) in Tracker, it
is possible for BPoseView::AttributeChanged() to open the file in the
middle of the operation, which will deadlock with MoveItem() if
opening involves a write lock.
Change-Id: Ifc430e1e583cacff2eeb7283100417e16e3f1f5b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7881
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This way we avoid lock contention if multiple threads are trying
to delete areas at once.
Same benchmark and "before" as previous commit:
real 0m14.522s
user 0m14.194s
sys 0m4.337s
after:
real 0m13.810s
user 0m14.145s
sys 0m4.155s
Every time a page is mapped into an area on fault, we have to
allocate a mapping object for it. While the object_cache
does have per-CPU depots, these depots only store a limited
number of items, and once they run out the object_cache's lock
must be acquired.
So, to reduce lock contention on SMP systems, create a number
of object caches corresponding to the nearest power of 2
that is equal or smaller than the count of CPUs. (We already
allocate dozens of object caches for the block allocator
no matter how many CPUs there are, so a few more depending
on CPU count shouldn't impact memory use too much. Besides,
the object_caches are wired into the low_resource system.)
This significantly reduces lock contention on SMP systems.
Same benchmark setup as yesterday (compile mime_db and relink
HaikuDepot, VMware, -j4), before:
real 0m16.981s
user 0m14.357s
sys 0m6.060s
after:
real 0m14.522s
user 0m14.194s
sys 0m4.337s
And the page_mappings object_cache locks went from having 200,000+ waits
and ~14 seconds waiting time (across all threads) down to ~900 (yes,
that's not a typo) and ~0.05s wait time (though these numbers were captured
in conjunction with the following commit.)
The same as we do for prefetch. Otherwise very large areas
will spend an inordinate amount of time in premapping,
rather than just letting the fault handler do its job.
usage_count is set by the page_daemon, and as such isn't often
updated. In order to check whether new or "hot" pages are in-use,
we need to check their "accessed" flag directly.
This is a significant speed improvement, especially in heavily-contended
mapped files (e.g. shared libraries in a compile job.)
Same benchmark (compile the mime_db and relink HaikuDepot):
before (same as previous commit's "after"):
real 0m18.789s
user 0m14.880s
sys 0m8.779s
after:
real 0m16.615s
user 0m13.919s
sys 0m5.972s
If there are already more pages in the cache then we would be
prefetching, don't even call cache_prefetch_vnode(). This
cuts down on lock contention and avoids having to look up
whether the pages already exist (an operation that can take
hundreds of microseconds if we have thousands of pages.)
Time to rebuild the mime_db and relink HaikuDepot, best of
multiple runs (on VMware with -j4):
before:
real 0m19.005s
user 0m14.820s
sys 0m9.118s
after:
real 0m18.789s
user 0m14.880s
sys 0m8.779s
It seems there is presently a race between debugger state teardown
and canceling the profiling timer, which can lead to timers being
double-added in some circumstances (which hangs the system.)
Obviously that should be fixed, but for now adjust things
so that we catch this in an ASSERT.
Taken from FreeBSD but musl has the same. Does improve loading time.
Change-Id: I41c1f37e8948169a50d8989cc465998282fadaf8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7898
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This is an alternative to DT_HASH (SystemV/SVR4 hash tables.) Notably,
it uses a Bloom filter to allow an entire image to be skipped
at once rather than searching the actual symbol hash.
We don't currently build anything with DT_GNU_HASH support.
You can test this by adding -Wl,--hash-style=both to HAIKU_LINKFLAGS.
(It seems to increase image sizes by not too much: libroot goes
from 1347139 to 1367691 bytes (20.55 KB) in my build.)
Change-Id: I4a91276490fcd136db175833ee48b36e06ceed47
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7855
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Move the symbol testing out into its own method.
* Check the symbol name after the type (as that's a cheaper check.)
* Move some functions around to closer to where they are actually used.
Change-Id: I99c25eac6b03b0cb7e5a3edee80b222bc0325d4d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7854
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Nothing uses it, and it just allowed for mistakes like the one
corrected in the last commit to go unnoticed.
Change-Id: I5a64b45eb6f1f9abc9f98be14c9ff6d04c2814fa
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7853
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This reverts commit 61987fe7a2.
The original commit had a typo in it preventing this logic from
working (the "true" should be after the first ")".) It ultimately
doesn't seem to be needed, and just complicates the ELF lookup logic.
Change-Id: I23df8c86ad61cac4db45af2ae4ab69635a9e4a33
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7852
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Put close/free at the beginning since all FDs must implement that.
(Most of the function declarations inline were already in this order.)
* Add readv/writev hooks. Not used yet, but this will allow for
more than just files to implement them. All declarations updated
to have NULL for the hooks for the moment.
It allows introducing new file descriptor types without editing enumeration every time. Anonymous FDs will be needed for Mesa
OpenGL/Vulkan drivers to reference GPU memory buffers and other driver objects that can be referenced as FDs from userland.
This change breaks private VFS API compatibility.
No behavior changes intended.
Change-Id: Iac109aad420b0b6aae704b38619436e01dcf4969
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7838
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This only happens on team exit and exec. In the exec case, we can
just document that this implies all images are removed from the team.
It appears all consumers of the debugger API handle this correctly as-is.
Let the loop handle the iframe instead of processing it up front,
so that it doesn't call get_next_frame_no_debugger the first time around.
Fixes the profiler skipping the first function when profiling user
space only.
