All filesystems have open_dir calls in their vnode hooks,
but there are some vnode hooks that do not, like FIFOs.
Thus we need to check the hook actually exists.
Fixes#17870.
Creates, opens, tries to open as directory, then unlinks.
The attempt to open as a directory triggers an assertion
in the kernel at present (this is #17870.) The next commit
will fix that.
* adjust format string for thread id
* fix variable name loop vs looper
Change-Id: I3d1924d6ab98981b4b2a3f56689872e35e5bea77
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5562
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Change-Id: Icc4ab0c3f7258914d798267e08c47977c0987c97
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5547
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: David Karoly <karolyd577@gmail.com>
These two recieve integer values from userland (termios).
Cast them accordingly.
Should fix#17861. Tested on 32 and 64 bits.
Change-Id: Ic5eb53d2732354f86a82f59aab4917ad1851cfc5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5545
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
It can be enabled by putting "bios_patching true" in the VESA settings
file.
This patching does not work yet on modern hardware, but the detection
code to decide if we should try patching still says it found the
modetables. In this situation we can crash the BIOS or other weird
things can happen.
To avoid these problems, and because VESA is supposed to be the failsafe
option, disable this code by default, and let people who want to
experiment with it first enable it in the settings file.
Should fix#17633.
Change-Id: I4d89ff6dfeb7d02e39cd3da7b22ddd5411b10822
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5499
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
compiler generates a warning regarding using offsetof() function on a non - POD type class
disabling Werror will not break build due to this warning
Change-Id: Ic72210f92a257e80ad8de9327892cfca7454076e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5538
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
sscanf() requires 1024 bytes for url[] at line 96 and 97,
but url[] size is 256 bytes.
Pointed out by LGTM.
Change-Id: Ia94661b8d7f08874395f8912b48774dba3b9ece2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5534
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
* conditional compile for dump_fdt() with #ifdef
* rename functions according to coding standard
* use dprintf() for printing
Change-Id: Ie486739d87f1cb9a005188a46a43f470b6000319
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5536
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
... and B_WORKSPACES_CHANGED too.
hrev50148 propagated B_SCREEN_CHANGED messages to
children allowing them to respond to screen changes
fixing #8035 back in 2016.
This does the same thing for workspace messages only
I spelled propagate correctly this time.
Add private _PropagateMessageToChildViews() convinience
method to BWindow to do this work.
Call PostMessage() instead of calling MessageReceived()
directly which can work better in certain circumstances.
Change-Id: I5978c3fe674bbe75d9eafb7afb654a49ee3e0c11
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5516
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
and dns_resolver_repair() succeeds.
reply allocated at line 178, not freed on continue.
Change-Id: I8fc9d02512ab741d34b0f6bd4710bb1bd29ddaae
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5532
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
as it extends the provided protection with the kernel protection.
fix hrev55016
Change-Id: I9fa9349c15b4ef896a9dadd1b1b7a4165cc03b39
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5531
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
'reply' is allocated in Serialize() at line 120, but is not freed.
Pointed out by Clang Static Analyzer.
Change-Id: I9f7e0c5c2dcb976f11230ad8a5ba38d653b23d6d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5530
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
should help with #17664
register change from Tahiti for #17377
Change-Id: I52b9691cd6a04b58b70e905bc29e803f06936789
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5526
Reviewed-by: John Scipione <jscipione@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Normally the heap's priority will suffice to check if we need to reschedule.
However, in cases where the CPU in question is currently in the middle of
rescheduling already, and it is about to change its priority to "idle",
we can race with it and not notice that we need to send it an ICI.
Previously this meant we would just lose some performance, but after
recent fixes to not reschedule only as necessary, this race led to hangs.
Now we report whether the runqueue we added the thread to was empty
in ThreadData::Enqueue(), and if it was, we then always trigger a
scheduler invocation on the target CPU.
In my testing, this fixes#17847; and at least in my unscientific
benchmarks, improves compile performance by as much as 10% (I saw
~55s -> ~50s in some tests.)
This will allow it to be invoked outside scheduler_cpu.cpp,
and GCC should automatically inline this function within that file
anyway.
No functional change intended.
No commits since 2016 or so. Are you guys still around?
Change-Id: I07ca59f537c7e47859c02128023eeebb4d452e33
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5525
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: John Scipione <jscipione@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Instead of 8096 maximum entries, now there will be about 130k.
As there are around ~32k files in the Haiku git tree, this has a
serious impact on "git status" performance: in my testing it sped up
from around 0.95s to 0.39s, or less than half with a "hot" cache
(in a VM backed by an NVMe SSD, may be more dramatic on spinning system.)
Compile performance does not seem very much improved, however.
We are trying to add the enty to the current generation, so we
need to use the current generation's next_index, not the previous.
This was apparently broken since this code was imported. The "miss"
here meant we always acquired the write-lock and then ran the more
expensive add operation, which performs this same check (correctly).
Slight performance improvement seen in basic testing, but nothing
too drastic.
Instead set them in the Init functions. For now, the same
hard-coded sizes are used, so aside from slightly increased storage
on two classes (or not even due to padding), this has no functional change.
uselocale now attempts to create a backend and a databrige.
If the attempt fails due to a missing libroot-addon-icu, uselocale
does nothing (to support applications calling uselocale during
startup to enforce the C locale).
Else, uselocale will fail with ENOMEM.
LocaleBackend::CreateBackend() has been modified to return a status_t
that indicates whether NULL is returned due to out of memory (B_NO_MEMORY)
or due to being unable to load the ICU addon (B_MISSING_LIBRARY).
Change-Id: I0f62ebde5890364c64e6694ec58d38de43ec6841
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5505
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
this is only useful when connecting an external screen, and the laptop actually uses it on boot.
should help with #17706
Change-Id: Ia3434f76cf6210b743f17d5559d031c089cbcd85
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5518
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
* If the target is a volume, include a line on the Information tab of
the Get Info window that lists the filesystem name, block size, and
whether the volume is indexed.
* Fixes#16945.
Change-Id: I888ae708a15a2f7729f50806fb59dbb4df506cfa
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5507
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
test_app_server: fix build for SVGViewView.cpp
src/tests/kits/interface/picture/SVGViewView.cpp:
In method `struct rgb_color Svg2PictureView::GetColorAttribute(const
XML_Char **, const char *, unsigned char)':
src/tests/kits/interface/picture/SVGViewView.cpp:258:
warning: unsigned int format, long unsigned int arg (arg 3)
src/tests/kits/interface/picture/SVGViewView.cpp:258:
warning: unsigned int format, long unsigned int arg (arg 4)
src/tests/kits/interface/picture/SVGViewView.cpp:258:
warning: unsigned int format, long unsigned int arg (arg 5)
src/tests/kits/interface/picture/SVGViewView.cpp:264:
warning: unsigned int format, long unsigned int arg (arg 3)
src/tests/kits/interface/picture/SVGViewView.cpp:264:
warning: unsigned int format, long unsigned int arg (arg 4)
src/tests/kits/interface/picture/SVGViewView.cpp:264:
warning: unsigned int format, long unsigned int arg (arg 5)
src/tests/kits/interface/picture/SVGViewView.cpp:276:
warning: int format, int32 arg (arg 3)
src/tests/kits/interface/picture/SVGViewView.cpp:276:
warning: int format, int32 arg (arg 4)
src/tests/kits/interface/picture/SVGViewView.cpp:276:
warning: int format, int32 arg (arg 5)
Change-Id: I886cef4df7f47425db8ee22ec1271d122cb454ea
test_app_server: fix build for ScreenManager.cpp
src/servers/app/ScreenManager.cpp:206: parse error before `('
Add expat build feature to picture Jamfile
src/tests/kits/interface/picture/SVGViewView.h:5: expat.h: No such file
or directory
Change-Id: I83edbc3059d6042482820a43eb41ef16928b8f6b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5504
Reviewed-by: John Scipione <jscipione@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
