GCC complained of missing prototype for "uninit_hardware()" and,
as -Werror is enabled for these targets, build was broken for them.
While src/system/kernel/device_manager/legacy_drivers.cpp supports
that hook in legacy drivers binaries:
- no header mentions it.
- these two were the only places in-tree that implemented that hook.
- both were basically no-ops.
Change-Id: Ifb08846351b92a2d0fbbe95db2eee0e424ae5997
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6180
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Following some IRC discussions, it seems useful to have this written
down somewhere.
Change-Id: Ic02686948d989bff2fa671a3831ba5aed1515d25
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6085
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Separate the "interface specification" into multiple individual, shorter
pages. Also update some outdated parts and replace references to
OpenBeOS with Haiku.
Change-Id: I86baa9a78c5f7a8a3c4c7aa3ac2992714afecae6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6084
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Change-Id: Ic3e83dceb917c84db6baed1f1e4af4a27ece5372
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6177
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 FileTypes Tracker add-on allowed dragging-and-dropping an icon to
any open FileTypes information window, but directories were not
supported. Changing the icon for a directory (either directly, or via a
symlink) now works as expected.
Change-Id: I0c435ed789f79897972469f4e238f19789f8df1f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6116
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Even if it may seem obvious to experienced users that they have to
click on the 'Set up partitions...' button, this is unfortunately not
always the case. Despite the pop-up that appears if there are no
suitable partitions to install Haiku on, some contradicting
instructions remain on the screen after closing it.
The Installer should also provide some feedback to the user as to
whether they used DriveSetup correctly, instead of inferring it from
the fact that they cannot select any drives after having used
DriveSetup.
For this purpose, the Installer window was made a bit wider.
Change-Id: If561f628e2768a01d85176359f07a187e002f51b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6087
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: humdinger <humdingerb@gmail.com>
With B_MODAL_WINDOW, others can be brought in front. But with
B_MODAL_WINDOW_LOOK plus B_FLOATING_ALL_WINDOW_FEEL, it will
retain its current appearance, but always stay on top of all other
windows.
Since debug_server does not have a Deskbar entry, this will prevent
such windows from getting "lost" and then having to minimize all others
in order to find them (or forgetting about them altogether by accident.)
POSIX seems to be silent about whether this is permitted,
but at least FreeBSD explicitly does not allow it.
Fixes#16936.
Change-Id: If6b23410ae88245e706df77d276234f4775654f9
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.
This cuts out a lot of unnecessary protocol entires found in the
longer NetBSD (and originally from ISC) lists. This data is used
in the implementation of getservent(), etc.
We shouldn't be doing these crazy things.
The only usage of this is the NextID rule which computes an unique
number by incrementing a variable. This is used for example to generate
names for the extra files used in xattr emulation.
But we certainly don't need multiplication, division, etc. That's better
done in scripts (Python, for example) in rule actions. So keep just
enough of this for NextID to work, and we could probably make it even
simpler.
Change-Id: Id06d4f5e236205203fe8d604de440753b63801bc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6088
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Saves at least a thread and a few semaphores per app.
Change-Id: Ied43e5944471918b34b897722346a25d159090df
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6073
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Move common add/remove code to the base class and improve encapsulation.
Loading FreeType is the responsibility of the global font manager.
Rename FontManagerBase back to FontManager.
Change-Id: I9396112f01583e19d03011106fd1fa1e37958ee8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6072
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
App-loaded fonts get the same IDs for different apps, so the cache
entries can be easily overwritten or used for an unexpected font. The
FontManager adds a unique chunk to the string.
Change-Id: I67ea9971784f425370d1aad516af4dae8489c45b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6071
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Record the read-only status of a partition in settings/mount_server
so it will be applied if automatically mounting on next boot.
* Fixes#18081.
Change-Id: Idd7267fd356f35689bb6ad79de4a45bf071164f1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6080
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* We depend on FDT passed to the bootloader now
from EFI or u-boot via fdt_addr_r now
* We leave an fdt path within the boot partition
(for now) to allow / encourage users to optionally
plug in their own DTB's for troubleshooting. (only
on u-boot loader)
Change-Id: I3f2d81b60d46f388f333d5caa27aa77e6e36447d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6081
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: X512 <danger_mail@list.ru>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Tested-by: Automation <automation@haiku-os.org>
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>
The code is endian-dependant because the alpha channel is not at the
same place. This resulted in transparent white in icons being converted
to partially transparent yellow when attempting to darken the icons, for
example.
Change-Id: I57916139ba37b8d7ae0f9e9ba9e74c1d496d7b05
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6077
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The previous logic of _AddTrim plus _TrimNext meant that if a trim
range was specified in the final call to _TrimNext (i.e. with force=true),
but the trim buffer was already full at that point, that last range
would not actually be trimmed.
Now, _AddTrim returns true when the buffer is filled and trimming
should be done, rather than delaying it and requiring a second
add after trimming.
Change-Id: I4b782948e8dc9267c63e61bce0c078fd4e834177
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6070
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>
There's only one implementation of smix so we don't
need any selection logic.
Change-Id: Id43e4ed49ee5a96755c3c4ab975bd128024e57b0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6065
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
