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>
Define a new message, B_KEY_MAP_LOADED, that is broadcast to applications by
the Input Server each time a key map is loaded. This allows apps that cache
key-map data to know when their copy has become stale.
Change InputServer::HandleGetSetKeyMap() so it returns an error in the event
loading even the system (fallback) key map fails.
Change-Id: Icc6c884f695ca59c687d83c680bb2fb467dd90cc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1741
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
There seem to be some cases that severely fragment rpmalloc's heap,
wasting large amounts of memory (in #15264, some 750+MB it appears
are wasted this way.) This is a stop-gap measure to cut the wastage
in half (or more) until a proper solution is implemented.
Now there is no need to resort to listattr and catattr to see the
attributes of a file. You can get them easily, from the GUI.
Limitations:
- No editing support
- Only a few well-known types are handled
- No support for attributes with array of values or otherwise unexpected
size
- Special handling for B_TIME_FORMAT which is annoyingly of a different
size between 32 and 64bit systems, making the attribute format
slightly incompatible.
The window is a bit small to show all the information, so the "Type"
column is put off-view on the right, one can scroll to it if needed.
Vertically there is space for only 4 to 5 entries. It was suggested that
we could merge the permissions and information tabs, making the new
first tab higher, and thus adding more space to this one as well.
Change-Id: I75d192314bc60378c2f058547485cb9c30263485
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1748
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
- Misplaced popup window for showing truncated paths in full (#15301)
- Crash when using Alt + E to edit the filename (#15302)
- "Link To" information for symlinks does not fit in window (#15303)
Change-Id: I72416ab4473e0b01c33817b9364eb9e9e59172e1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1747
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
- Use layout kit to make a few things simpler
- Separate the view showing the header (icon/name) and the one showing
the extra details, making two simpler files instead of a complex one
- Fix some layouting issues
- The permissions are now in a second tab, allowing to add a third one
with other things (more on that later)
screenshot: http://pulkomandy.tk/drop/fileinfo.png
Change-Id: Ief80815eba749723664f40f1317f8aa4cf692162
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1745
Reviewed-by: Ryan Leavengood <leavengood@gmail.com>
I'm going to split it into even more files, and it's easier to track
what's part of it this way.
Change-Id: I09c302da38ce96f0077c5f53fd17c08cdd6c22c9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1743
Reviewed-by: Ryan Leavengood <leavengood@gmail.com>
* Some PVS-Studio warnings are removed.
* fixes hardlink count in source and destination folders on rename.
* tested with fstorture and fsx (one job).
* add new definitions.
* import crc32c code from BSD.
* add some consistency checks at mount.
* DirectoryIterator::_AllocateBestEntryInBlock(), the direntry is checked for
consistency before using it, which should avoid crashing on bad data.
* DirectoryIterator::_SplitIndexedBlock(): the dotdot entry length should
include the dot and dotdot entries length.
Change-Id: I0f80d73b65b1ae6ddb2e746a6f85ef806f23dbb0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1735
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Symlink name or attributes may be relevant to the launched app, so it's
important that we pass the unresolved symlink as argv[0] when running
it.
Change-Id: Ie1d73bc4e9d5c3d0476f205ce635aafd9203e553
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1739
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It has been multiple years since this comment was written; all relevant
apps have added their own hooks around this, so we should now be
"secure by default."
Also spotted by a random Hacker News commenter.
Now SSL certificates with the wrong hostname actually fail to validate.
While I'm at it, remove the usage of BString and just check [0] directly.
Spotted by a random commenter on Hacker News.
The port pool now being created in BMediaRoster init, we must make sure
the media roster is initialized before doing anything else.
Change-Id: I5a3cc61c993e9be4078772bbf341b637d951d239
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1734
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Change-Id: I8084e0fa2ffbaf04242fa14617807d83abbd5586
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1556
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
If a new pose is going to be placed below the current view bounds, we
definitely do not need to do any drawing. If it is above or inside the view
bounds we do this special drawing method.
Overall this method of doing updates is complicated and hard to adjust without
introducing drawing artifacts. As noted in the TODO, this should be rethought
from scratch.
But for now in one case of over 8000 files in a single directory this improved
the loading speed from about 8 or 9 seconds to 1. Queries results also load
much faster. I am testing in a VM with a single CPU on a host with an SSD, so
others may see better performance with more CPUs, or less with a spinning hard
drive.
But at least now the drawing won't be the bottleneck.
Should finally fully fix#3011, or at least good enough for close.
Change-Id: I3806ffa7674e404c9db24edb33d6ab4eb2d825f7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1726
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This is a very simple reader for the media kit, useful to make sure
ffmpeg isn't at fault when you get a crash. Also, unlike ffmpeg it
allows you to see the full backtrace.
-Resolve some issues.
-Added the connected devices code in the main window.
-Replace BUTTON_DEFAULTS and BUTTON_REVERT with kMsgDefaults and kMsgRevert.
Change-Id: I3b0c86fc581056859239df0fbf2c085b8d168136
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1619
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Change-Id: I9f1c47728297d7e29033beed7338bbd44d6d13cd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1492
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Chế Vũ Gia Hy <cvghy116@gmail.com>
Add a preliminary set of unit tests for BKeymap and fix these issues:
* BKeymap::operator=() caused a crash by allocating a zero-byte array to hold
the other object's character data.
* BKeymap::SetToCurrent() and SetToDefault() leaked memory by not freeing an
existing character array before allocating a new one.
* BKeymap::SetToCurrent() incorrectly determined the size of the current
keymap's character array, causing GetChars() to fail whenever the current
keymap was loaded. Now SetToCurrent() uses the _get_key_map() private
function, which accurately reports the size of the array.
This commit also updates a Jamfile by replacing a use of "UseHeaders" to
include private header files with the more concise and expressive
"UsePrivateHeaders".
Change-Id: If6f71b209f1bd395be57835c4dd89f0e3f845994
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1724
Reviewed-by: Ryan Leavengood <leavengood@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
Letting it get deleted statically can cause segfaults since it is needed for
some final quit messages.
This mimic changes Axel made for the DormantNodeManager and
TimeSourceObjectManager.
I also pulled PortPool into its own file and header.
Fixes#15135.
Change-Id: Ie64753e1876d58b52f7cb95536c6be3df2e6d40c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1721
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
I had app_server crash on me because of an uncaught allocation
exception. I don't know if this will fix it but it's better to try to
survive even if it may result in some UI glitches.
Change-Id: I09dd2a7e6ff63d52f51389d7418d1a1d1810af00
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1720
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Without this, the BufferCache keeps a reference to these buffers inside the
media_addon_server until the media_addon_server quits, which is pretty much
never.
Should fix#4954 and #14755, and possibly #13614 and #14047, though I think
they may be something else.
Switched from std::map to our HashMap to get something which works in gcc2 and
gcc8.
Change-Id: I26463899724b9d1520d97fec785e435f536eaf3d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1717
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Thinking over this carefully, I realized that adding checks to
every ioctl implementation in every driver would be very prohibitive,
because there, one has to check is_called_via_syscall() in addition
to IS_USER_ADDRESS(), and this would have to be done in every case.
So that would take a massive amount of work, and it would be
very easy to miss a case.
Instead, we can take advantage of the fact that all we really care
about is the buffer not existing within the kernel address space.
This should allow using constants in the umappable range between
0x0 and the beginning of the user address space, too.
Change-Id: I2eeb46e806a5aac32e152c72076a042aa847be0d
