Having valid superblocks from multiple filesystems on the same disk is
confusing, let's try to avoid that.
Change-Id: I1a58843d45ea52193a77faaf8dcc3ca6a049406e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1802
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
If multipole filesystems think they can handle a volume, it makes sense
to assume the native one is to be used.
Makes my partitions with a BFS superblock and a leftover ext2 superblock
on them mountable again without manually specifying the filesystem type.
Fixes#15045.
Change-Id: Icb694472aa3de0a79e5f7d3c54976038e1e2590a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1801
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
I have two partitions which used to be ext2, but have long since been
reinitialized as BFS. However, the ext2 superblock is still here, and
the ext2 filesystem will detect it. It crashes later on trying to access
an Inode at block -1, so just add a check for that to avoid the crash.
Change-Id: Ie2ed6a969ea3ffd343dedfe45a15dfc37af05804
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1800
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Use 2D icons for mount modes: encrypted, file, readonly, shared
('boot' already uses he 2D Overlay_leaf)
* Use more vibrant colors for used space indicators.
(red = readonly, green = BFS, blue = non-BFS, grey/orange = encrypted)
* Don't have boot/bfs partitions override readonly status (red) with
green. Keep it simple: if anything mounts read-only, show in red.
Change-Id: I4a7c53e1c1d3c6f4be35cbd680b2a7b5e1f9bea3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1755
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Fix hardcoded black color in SeparatorView that caused invisible or
hard to read labels if you had a dark panel color. E.g MediaPrefs
* DrawBorder in HaikuControl didn't care about dark mode. Added check
for light/dark and changed the Tinting accordingly. We should probably
do the same for FancyBorder style as well.
Change-Id: I065211e56b0db5acd05ea287d6cacf75786f306f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1751
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
src/add-ons/kernel/network/ppp/shared/libkernelppp/KPPPInterface.cpp: In
member function 'void KPPPInterface::CalculateBaudRate()':
src/add-ons/kernel/network/ppp/shared/libkernelppp/KPPPInterface.cpp:2018:4:
error: this 'if' clause does not guard...
[-Werror=misleading-indentation]
if (ChildAt(index)->Ifnet())
^~
src/add-ons/kernel/network/ppp/shared/libkernelppp/KPPPInterface.cpp:2020:5:
note: ...this statement, but the latter is misleadingly indented as if
it were guarded by the 'if'
return;
Signed-off-by: Jaroslaw Pelczar <jarek@jpelczar.com>
Change-Id: I8790a8ea3a961d73073b295ac438f3c60c16fcba
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1759
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
VAL=xxx... and VAL=$VAL:xxx... are supported; all other syntaxes
will fail with an error message.
When combined with a build/jam patch that will come in a later
commit, this makes it possible to build a large number of targets
using exec as JAMSHELL; including all of libroot. The performance
difference is extremely obvious:
jam -j2 libroot, JAMSHELL=/bin/sh (32-bit Haiku)
real 1m43.571s
user 1m10.961s
sys 1m7.965s
jam -j2 libroot, JAMSHELL=exec
real 1m28.364s
user 0m58.190s
sys 0m57.563s
So that is a savings of 15.21 seconds, or 15% of the build time.
Something that is less I/O bound and more fork-bound (e.g.
linking application catalogs) will almost certainly see
an even bigger performance difference.
Changes to add the necessary JAMSHELL overrides for those
targets which need it, in order to make it possible to
enable usage of "exec" by default, will be coming
over the next few days/weeks...
This utility takes command-strings, e.g. "gcc -c file.c -D...",
parses them into an argv, and then execvp()s that. The use-case
is Jam, which cannot do this itself, but instead simply calls
JAMSHELL (usually just "/bin/sh -c") to do that for it.
Shells in general have a large amount of overhead (and bash in
particular is especially bad here), so using a utility like this
as JAMSHELL in most cases can be a significant speed-up.
For example, on Haiku (32-bit):
$ time sh -c 'for i in {1..100}; do sh -c "./exec test"; done'
real 0m3.335s
user 0m1.603s
sys 0m1.612s
$ time sh -c 'for i in {1..100}; do ./exec test; done'
real 0m1.547s
user 0m0.597s
sys 0m0.867s
So this means for every 100 executions, using bash has about 3.3s of
overhead, and this tool cuts out over half of that. Probably for
longer command strings, the overhead is significantly greater.
But that should be clear soon enough...
This was using unsigned integer math and then trying to clamp to 0.
That won't work. Use off_t instead, which is an int64 and thus signed.
May fix behavior in some stranger error conditions.
While I'm at it, avoid reading in the beginning partial block
if we don't need to.
The patched errata are only the AMD ones FreeBSD patches
(it seems there are no Intel errata that can be patched
this way, they are all in microcode updates ... or can't
be patched in the CPU at all.)
This also seems to be roughly the point in the boot that
FreeBSD patches these, too, despite how "critical" some
of them seem.
Change-Id: I9065f8d025332418a21c2cdf39afd7d29405edcc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1740
Reviewed-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
The code does just fine both if entry is NULL and if it doesn't have an
icon. However, if entry is NULL, this assert calls a method on it, which
is a bad idea.
Change-Id: I80b314db373970d99eb008aeaec6254d14c39ca7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1749
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
