- Stored the additional start time of each team, expressed by
milliseconds since boot.
- Added more fields to the `team_info` structure. These field
include those provided by the `get_extended_team_info` syscall as
well as the newly introduced `start_time`.
- Extended the `_kern_get_team_info` system call to receive an
additional `size_t` argument. If this size is smaller than or
equal to the size of the old `team_info` structure, the newly
added attributes will not be retrieved.
Change-Id: I22ee6b91ad2ee3b66a7f770036c79a718c5f115c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6390
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
Implemented exclusive mode on Haiku and added the related `ioctl`
operations (`TIOCEXCL` and `TIOCNXCL`).
Change-Id: Iaa201ea20eec0e45d02dd5db9ba6aa35fd27dfb2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6387
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
This new driver uses the "generic" TTY layer, unlike the old driver
which had its own implementation (which the generic module was derived
from, originally.)
The remaining bits of support for controlling TTYs is added to the kernel &
generic layer at the same time, which should allow for serial interfaces
to be controlling terminals now, as well.
Tested with bash, nano, vim; all seems to still be working as expected.
Exported `pthread_attr_get_np` under `_DEFAULT_SOURCE`. Otherwise,
the presence of this function in `libroot.so` without a definition
would confuse some configuration scripts.
Change-Id: I623ebefc98800e9528dc48859c2aefc828821f27
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6383
Reviewed-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
I want to use this in at least 2 third-party applications. I think it's
time to make it shared?
Change-Id: I855a59aab4ad6d47d77cf2901cb3dfc34c108059
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6296
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
THREAD_BLOCK_TYPE_OTHER implies the "object" pointer in the
wait information is a string. But sometimes we want to pass
through objects which are not strings, for inspection in KDL.
Remove ConstrainClippingRegion calls as they do not take into
account view transformations.
Clip drawing to the drawing rect, not the updated area.
Fixes#12890
Change-Id: Ie76cb83e0af03213008da78407de25261daea5df
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4457
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
busses/pci/x86: add
Other add-ons are in following commits.
Change-Id: I7a77bfaef0e8995917b4b54c8369d7075533ec26
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6220
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
See #18351 for details on the specifications.
This is the same thing NetBSD does. BeOS R5 defined these values
differently than we did even before this commit, and it does not
seem to have caused problems then, so this should be fine.
While technically an ABI break, in practice these values are not
always differentiated on other platforms, and it appears musl's
code triggers divide-by-zero exceptions on purpose before it
returns this value, anyway.
Fixes#18351.
* Make some code common in Insert.
* Remove unneeded logic from InsertAfter and just call the base Insert.
InsertBefore does this, already.
* Synchronize Insert code and APIs in the fs_shell DoublyLinkedList.
Removing it outright would cause implicit conversions and then the other
variant being called, which would create invalid lists. So make it private
so that any attempts to use it will create errors at compile-time.
As far as I can tell, it has no consumers whatsoever outside the tree.
(wpa_supplicant did not even use it.) So, remove it altogether.
If that turns out to be mistaken, we can reinstate it temporarily
as a private class function or ABI-only symbol.
Since we used a hash table with a fixed size (1024), collisions were
obviously inevitable, meaning that while insertions would always be
fast, lookups and deletions would take linear time to search the
linked-list for the area in question. For recently-created areas,
this would be fast; for less-recently-created areas, it would get
slower and slower and slower.
A particularly pathological case was the "mmap/24-1" test from the
Open POSIX Testsuite, which creates millions of areas until it hits
ENOMEM; it then simply exits, at which point it would run for minutes
and minutes in the kernel team deletion routines; how long I don't know,
as I rebooted before it finished.
This change fixes that problem, among others, at the cost of increased
area creation time, by using an AVL tree instead of a hash. For comparison,
mmap'ing 2 million areas with the "24-1" test before this change took
around 0m2.706s of real time, while afterwards it takes about 0m3.118s,
or around a 15% increase (1.152x).
On the other hand, the total test runtime for 2 million areas went from
around 2m11.050s to 0m4.035s, or around a 97% decrease (0.031x); in other
words, with this new code, it is *32 times faster.*
Area insertion will no longer be O(1), however, so the time increase
may go up with the number of areas present on the system; but if it's
only around 3 seconds to create 2 million areas, or about 1.56 us per area,
vs. 1.35 us before, I don't think that's worth worrying about.
My nonscientific "compile HaikuDepot with 2 cores in VM" benchmark
seems to be within the realm of "noise", anyway, with most results
both before and after this change coming in around 47s real time.
Change-Id: I230e17de4f80304d082152af83db8bd5abe7b831
Change-Id: Ia16e66a7bdac37019e6256405b9f10024909c69a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6215
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
The kernel heap only uses object caches for objects up to size 8192.
Larger allocations have to go through the raw allocator. That can
get pretty expensive.
Adding instrumentation around the malloc/free calls in this function
showed that on my machine, some 596ms during boot were spent on
*malloc/free alone*, all else aside. After this change, we are at
around 110ms, or a >5x improvement. Running an fgrep -R on /system/
after boot increased the cumulative time in memory functions to over
5 seconds, while after this change it is "only" 1170ms.
Honestly, it seems like the object depots should be able to be faster
than that, even if this function is called thousands of times. But that
is a problem for a different investigation.
It would be even faster for every consumer of this data in
packagefs just allocated one set of buffers up front, or at least
for a single "read session", but plumbing that all the way
through the myriad abstractions of the Package Kit will
not be easy, and is left for another time, as well.
While the BSDs and glibc seem to have various _r functions,
they all return int for errors instead of a pointer, making ours
exactly backwards of theirs for error reporting and thus useless.
So, remove them from the header entirely. They are left in
for ABI backwards compatibility for the time being.
A few constants not used by anything in the tree (i.e. not actually
implemented by libnetwork/netresolv) were also dropped. Some deprecated
or non-standard functions were placed behind _DEFAULT_SOURCE or deleted
entirely.
The header itself is now organized approximately as the BSDs do,
although with various Haiku-isms instead of BSD-isms where appropriate.
In fixed size mode, the menu field always uses all the available width.
In non-fixed size mode, the menu field will resize itself to be as small
as possible.
With layout, usually the difference isn't noticeable, since the layout
will already try to resize the control to the smallest possible size.
But there are a few cases where it makes a difference, when the layout
is over-constrained and the menu field can't be made as small as
possible. In that case, the menu field would be forced to fill its
allocated space, where we can instead make it a little smaller.
Change-Id: I911d497218a09aab3824865968558df5d4b3cf98
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6076
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: John Scipione <jscipione@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
These were introduced by mistake during the addition of the layout
system. They have been private since 2011. It seems safe to assume that
nothing uses them anymore and they can now be removed safely.
Change-Id: I98d030096f9cb06fccc25233fe4da17d0213050e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6075
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
BSD extension to set both the input and output speed of a termios
structure.
Fixes#18220.
Change-Id: I8c4a06b4be4aa55b8ce35cb7f62552fc47a8e8d0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6049
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
..instead of readv_pos/writev_pos. This way, we can be sure that we
are remapping them properly even under Haiku, as well as remove some
potential confusions.
bfs_shell seems to still work fine on a regular build.
They are not about reading and writing pages, but just iovecs.
As the passed iovecs use void*s, it can't possibly be working with
physical pages on 32-bit systems with PAE.
It appears nothing uses or implements these functions anyway,
as there was nothing else in the tree I had to adjust after making
this change...
* changed explicit locking to use Autolocker for gFontManager/fAppFontManager
in ServerApp, per comments in https://review.haiku-os.org/c/haiku/+/4790
* changed BFont::LoadFont (memory version) to use size_t for size and offset
* no functional changes
Change-Id: I438a4975d5bb1b2fa17bc54e9e171c31dadfeec5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6003
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
