In GCC 8 builds it is by default, in GCC 11 builds it is weakly
defined, which runtime_loader does not yet support properly,
so we force it to be included.
Unblocking after unsetting fVariable just causes too many headaches
and corner cases to deal with; the code as-is did not actually handle
all of them, as it missed the case where the entry thread had called
thread_prepare_to_block but had not yet actually blocked.
Hopefully the last fix for #17444.
* Removed i2c keyboard handler, as it was just a hid shared handler duplicate with kdl stuff removed
* I've created a new macro def for the kdl code, splitting generic kdl code from specific usb one
* I2C custom KDL code can be added in the future (I don't know if it is already possible)
I am not very happy with this solution, but imho it is better than having two keyboard handlers. In fact, they were already out of sync from last patch series
Change-Id: I36513e57a2ce4f004fc7e05ccff5a6b2517fc139
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4758
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
If a thread executes a system call and meanwhile a different thread calls another one, then
the ongoing call is marked as unfinished. When the call returns it will be marked as resumed.
* remove PreSyscall, now unused.
Change-Id: Iea45b866be2c40568d766c2ed3cc73e34b9d1293
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4765
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
in the case of poll(), the events should be printed before the actual syscall,
and the revents after, while taking in account the return value.
thus B_DEBUGGER_MESSAGE_PRE_SYSCALL needs to be enabled and handled.
the attribute "preSyscall" is added to identify such syscalls, and the parameters
are identified with the attribute "inOut".
Change-Id: I390643ea176c720738c5ec4fc75a3a4c7125a3cd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4763
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
For now this is used on RISCV64 to indicate that interrupts will always
be on CPU 0. However, in the future, some architectures may want
or require interrupts to be "steered" in various ways, and this
also paves the way for that.
Change-Id: Iec79870cf5c4898d102d0e624de19602271ae772
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4721
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Factor out the code for clock frequency lookup to a separate function.
PL011 does not have clock-frequency property, it has a clocks property
instead, containing a phandle of the apb clock.
Change-Id: I5cbe2b4b2421afe1924c2804002ceef83ce37ef9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4734
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Don't match PL011 for arm,primecell compatibility string
as it can indicate other peripherals.
Primecell peripherals have the generic "arm,primcecell"
name as well as a specific name in the format of "arm,pl???"
see:
https://www.kernel.org/doc/Documentation/devicetree/bindings/arm/primecell.txt
Change-Id: Ida6450e9e71dac834770d558e4ab95c5574970cb
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4733
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The dirent struct is not packed, so offsetof(dirent, d_name) != sizeof(dirent).
Thus in order not to waste the alignment bytes (which are significant,
on x86_64 at least, sizeof(dirent)==32, but offsetof(...)=26.)
This is also the most portable way to handle things, and should
work just fine in cross-platform code that has a non-zero-sized d_name.
Otherwise if the file cache calls us again from a different thread,
as it sometimes does when doing concurrent I/O to multiple files,
we will deadlock.
Fixes#14104.
This driver was fully C until relatively recently, when it was
switched to C++ so that it could be used with fs_shell. However,
it still is mostly using C paradigms; so this commit begins the
refactor away from that.
If I did this correctly, there should not be any functional change.
Change-Id: Id87d17b2e019ccdd1c7f07156cfe2a2124496675
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4725
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
this avoids searching in edid information in this case.
Change-Id: I330341f089f71cd5de657a6630b5414d02db771f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4749
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Before 2019, the entire ConditionVariable system was "giant"-locked:
that is, there was a single global lock that all ConditionVariable
and ConditionVariableEntry operations had to pass through. This of
course was not very performant on multicore systems and when
ConditionVariables see significant use, so I reworked it then to have
more granular locking.
Those patches took a number of attempts to get right, as having two
objects in separate threads that can each access the other not turn
into a deadlock or use-after-free is not easy to say the least,
and the ultimate solution I came up with erased most of the performance
gains I initially saw on the first (partially broken) patchsets.
So I have wanted to revisit this and see if there was a better way
even since then. Recently there have been a few reports of
ConditionVariable-related panics (apparently double unlocks),
notably #16894, and so that was reason enough to actually revisit
this code and see if a better solution could be found.
Well, I think I have come up with one: after this commit, Entries
no longer have their own lock, and instead accesses to Entry members
are almost always atomic; and there is now a case where we spin inside
Variable::_NotifyLocked as well as one in Entry::_RemoveFromVariable.
This leads to somewhat simpler code (no more lock/unlock dance in Notify),
though it is significantly more difficult to understand the nuances of it,
so I have left a sizable number of comments explaining the intricacies
of the new logic.
Note: I initially tried 1000 for "tries", but on a few instances I did see
the panic hit, strangely. I don't think the code that is waited on can
be reasonably reduced any further, so I have just increased the limit to
10000 (which is still well below what spinlocks use.) Hopefully this suffices.
Quick benchmark, x86, compiling HaikuDepot and the mime_db in VMware, 2 cores:
before:
real 0m23.627s
user 0m25.152s
sys 0m7.319s
after:
real 0m23.962s
user 0m25.229s
sys 0m7.330s
Though I occasionally I saw sys times as low as 7.171s, so this seems
to be at least not a regression if not a definitive improvement.
Change-Id: Id042947976885cd5c1433cc4290bdf41b01ed10e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4727
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
