These are architecture-specific routines, so they deserve proper
architecture-specific naming. The user memory access routines are
already under arch_cpu (arch_cpu_user_memcpy, etc.), and the methods
usually change a CPU flag, so it makes sense to put these there too.
RISC-V had get_ac but nothing else defined or used it, so it's removed.
No functional change intended.
Change-Id: Id4715214e32f73d4a93bc7ba8249411a0878d174
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8106
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: X512 X512 <danger_mail@list.ru>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
So we need to check that it didn't when creating areas.
Change-Id: I4342463113046b543722faa7a51ca269ed67e8bf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8137
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Enhance the warning message and return a more relevant error code.
Fixes #19017.
Change-Id: I13d01ce206a27e5c9a35debc8081219422bfb10a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8136
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
- This key code is inherited from BeOS, where it was used for the power
key on Apple ADB keyboards
- Since then, we have introduced a new system for "multimedia" keys,
that uses HID key codes directly instead of defining our own mappings
- The PS2 driver was using the HID keycode, but the USB driver was still
using the BeOS defined one
- Japanese keyboards, which have a few more keys than US and European
ones, reused the same keycode for something else
Since the power key does not need to be mapped by the keymap, move it
out of the way by using the HID keycode (key codes larger than 0x7f
cannot be mapped to UTF8 symbols). Remove all mentions of the use of
0x6b as a keycode for the power key, but add a note in the documentation
that BeOS did this.
To avoid further confusions, complete the documentation of extra
keycodes, and remove some definitions from keyboard_mouse_driver.h that
should have been in InterfaceDefs.h.
While researching this, I also found that some keys specific to Korean
keyboards were declared in the wrong place, as mapped codes instead of
unmapped ones (checked that by looking at the HID driver, which emits
these raw keycodes, and confirming that the mapped ones are not used in
any keymaps. Also added a note about the mapping of the extra modifier
keys in Japanese keyboards, which I think may be a problem since these
map to invalid UTF-8 byte sequences, but this is what the existing
keymap does, so leaving it as is for now until we can determine if this
can be changed or if we have to keep it that way.
Change-Id: I6a198a0840cba7739bdc78e0c65e5d8fd23956c9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8047
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
According to the ARMv7 Reference Manual, "Wait for Interrupt" is supported only through the WFI instruction on ARMv7.
The currently used ARMv6 equivalent may not work on ARMv7 and newer CPUs.
Fixes #18520
Change-Id: I69a136870654be33c0c789004e08bf610db3dd97
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8044
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
ramfs needs to create caches that are both temporary and unmergeable,
so add another flag to make this state possible.
Otherwise, mmap'ed files from ramfs might wind up in VMCache
trying to merge the caches when the last one is closed, which
we don't want.
The IORequest internally likes to deal with transferEndOffset
not transferredBytes because of sub-requests potentially being
prepared all at once (in some paths in the I/O scheduler),
thus fTransferSize can get incremented in Advance() before we have
actually executed that transfer.
But external consumers much prefer just knowing transferredBytes
not transferEndOffset. And many of them actually named their
variables that (or "bytesTransferred") and just passed the
transferEndOffset through to variables with that name! That's
obviously wrong, and it's surprising it wasn't discovered before now.
The problem was uncovered by repeated KDLs in PrecacheIO.
That method used the "bytesTransferred" value as a count of
pages transferred, which would then run past the end of the array
if the transfer start offset was not 0 (which the majority
of the time it would be, since this method gets called on
the first mmap() of a file, probably before any pages are read in.)
Most other consumers of this API did not check the value, it seems,
or otherwise had some mitigating factor that prevented it from
causing more problems. An exception is the page code, which
may have spuriously considered writes as successful when they
really weren't.
May fix some of the "invalid concurrent access to page" KDLs.
We can't allow applications to reference/unreference cursors,
this is a safety/security violation, and it being done improperly
lead to the reference counts becoming incorrect on the app_server
side.
Change AS_REFERENCE_CURSOR to AS_CLONE_CURSOR and adjust the Cursor
code appropriately. (In the future, copying BCursor without Clone'ing
the data in the case of custom cursors could be accomplished with
client-side reference counting.)
Then rework CursorManager to remove cursors at once on team deletion,
and otherwise clean up cursor reference management to let the
reference counting handle things.
This paves the way for a variety of more interesting interactions
between drivers and the stack which are currently not possible
(e.g. checksum offload, #18744). The main advantage for the moment
is that we will save a memcpy of the buffer on each send/receive.
Adapt the virtio_net driver so that at least one driver is using
the new interface. Network still seems to work OK with it.
Change-Id: Ic5832e4865e3e1bed7462583ca1ffd16418d7cab
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7912
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Does not actually break ABI since net_buffer had 3 bytes of padding
remaining unused.
Add the first two constants for this field: L3/L4_CHECKSUM_VALID.
These will indicate when the checksum of the packet is known to be
valid (good/correct).
Change-Id: I155b3ea51d1093e229677cb788a007560ddbd428
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7916
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It contains only the MSG_* flags, not any other kind of flags.
Change-Id: Ia4590d87a1638fcdb848ef2b816b047b72ca2836
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7915
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@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>
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.)
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>
* 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>
Instead of taking the sample inside the timer callback
or the flush callback depending, always take it in the timer
callback, for consistency's sake. This should always work
because we try to flush the buffer when it's only 70% full;
in testing I can't recall seeing any dropped ticks.
Also add a flush call in the post_syscall hook, in case
we hit the flush threshhold while profiling in the kernel
and couldn't trigger the flush then.
Seems to significantly reduce "missed" ticks overall,
but there are still wildly inconsistent results and
lots of missing time.
Change-Id: I43a5e9c050a50309329da39f8a2386c3e2b3c0dd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7851
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The "-k" argument (which never did anything before) is now inverted
compared to what it used to be, i.e. now specifying it will profile
kernel frames, too, whereas by default only user frames will be
sampled.
This shows that the profiler is still pretty broken, because we
are missing quite a lot of ticks on average. One run of
"profile pkgman search" here produced an output with 66 total ticks
and 423 (!) missed ticks. A brief run of WebPositive was not quite
as bad (main thread: 1078 total ticks, 157 missed ticks.)
Change-Id: Idfc34534e66eff0fe7e948fcc3576be09db879a3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7820
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Without this, a query term that does have an index but for which
the pattern starts with a wildcard (e.g. "*term*") is treated as having
a score of 0. That means that it is then dependent on the query order
as to whether or not the equation will run at all, since if all the terms
have a score of 0 but one has an index, placing that term first
will make the query run while any other would not.
Fixes #18672.
If we have a matching operator, we will replace the current item
with a new item, and we may need to process it again. For example,
in cases like "A||B||C", the first pass will turn this into "(A||B)||C",
and so we need to re-process the first item to get "((A||B)||C".
Fixes "Open with..." and some other things following the query parser
refactorings.
This way, we won't run into stack overflow issues due to recursion.
Who would really need a FS query with more than 32 equations, anyway?
Fixes #18692.
Change-Id: Ieda401446d9cae2e56100ddbab08bebcc724b484
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7789
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
This way, we can handle parse trees of arbitrary depth without
running into stack overflows. Of course, evaluation is still
a problem...
While at it, use "const char*" everywhere, and also put the
query parser into an Init() function so we can return
more statuses than just B_BAD_VALUE.
Part of #18692.
Change-Id: Ib81e6545935ce484df10dfe36ca4ffcf2b3cd607
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7710
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Should not result in functional changes to packagefs and ramfs
queries behavior.
Change-Id: If361ca65de99d255e67f929c3442e0c20e39cdf4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7703
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Adds a `signal` field to the `team_deleted` event. Since killing
signals like `SIGKILL` and `SIGKILLTHR` do not generate a
`signal_received` event, debuggers would only see a `team_deleted`
message with the `status` field set to 0. This makes debuggers like
GDB think that the debuggee has exited with a status code of 0.
To correctly report these signals, when a killing signal is sent
to a team, this signal is relayed to the main thread instead of
defaulting to just a `SIGKILLTHR` for both cases.
Change-Id: If69c9e2e4d87bfbd31f654f5cb6f696ac69ef777
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7756
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
scheduler modes adapted to take into account the thread affinity mask.
when no cpu in the affinity mask is enabled, the mask is ignored.
Change-Id: I577737441ab073941a4c5e06f94f7825cffdc2c4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7674
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Add a field to `debug_[team/thread]_deleted` to report the exit status
on the corresponding events.
This is useful for debuggers like GDB expecting a return value when one
of their inferiors quit.
Also add a `usage` field to `debug_team_deleted` since this is another
potentially useful piece of information exposed by the `waitpid` family
of syscalls.
Change-Id: Ieff7c31f56b1b9f8f709725d19050273b21f2504
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7736
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Fix fPosition and fTerm not being initialized when expr is NULL
at line 1162.
Pointed out by GCC14.
Change-Id: If883ac0cc32e3418d0e3b49b42012efd861d65f4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7641
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
(And surrounding portions of the "btCoreData" module.)
* Rewrote the main "l2cap.h" header representing protocol constants
and structures. Now conforms to general Haiku naming conventions
rather than BSD ones. Some more constants added/removed based
on the most recent Bluetooth specification.
* Rewrote all code derived from the BSDs to match Haiku conventions
and structures in the driver.
* Dropped the "channel" and "frame" structures from "btCoreData".
Channels are now managed by L2capEndpoints, and "frames" are
now just plain net_buffers without surrounding structures.
This also makes state management much simpler.
* Made it so that actual net_buffers are passed through to the
l2cap_receive function rather than another data structure.
A fake interface address is used to communicate connection
information. (This probably ought to be changed, though.)
* Get rid of l2cap_lower and l2cap_upper abstractions.
Everything related to channel/endpoint management is now
done in L2capEndpoint, while buffer reception is handled
directly in l2cap_receive and elsewhere, same as other drivers.
* Wire up more hooks and fix module flags (needed to be able to
get the module loaded and opening sockets at all.)
* Implement an actual locking strategy in L2capEndpoint
and HciConnection. There's still problems with lifetime
management, but at least thread-safety is mostly handled.
* Create an L2capEndpointManager and use it to manage
the endpoints, rather than having a single (unsafe)
linked-list.
And plenty of other refactorings and cleanups besides.
There's still more to be done for Bluetooth overall, though:
* The "btCoreData" and "hci" modules also badly need a major
overhaul, and should be merged into a single "bluetooth"
bus_manager. They also shouldn't be passing around pointers
to other modules like this.
* There's a number of TODOs/FIXMEs in the L2CAP module, most
notably around timeouts (especially command timeouts) and
parameter validation/specification.
Tested by myself with kallisti5's help. Incoming connections
(on the PSM for SDP) get all the way to the latter half
of the Configuration step before hanging.
