It was removed in hrev55422 as we never had declared it in any headers.
But it seems some software came to depend on it anyway. Reinstate it,
and add a declaration for it, behind _GNU_SOURCE.
This is a source compatibility break from BeOS, but should not
be an ABI one (I checked, the symbols are identical.)
Also use "= {}" in the definitions of the fields. We use this
in plenty of places in the kernel, so it should be OK for GCC2.
Change-Id: Ibe05b2236d46024d7b4563ae16e1cc7140fed965
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4434
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This removes the use of the destructor in the move assignment operator, as it
may rely on undefined behaviour from the compiler. Additionally, some duplicate
logic to dereference and free a shared string has been unified under
_ReleasePrivateData().
Change-Id: Ie9f51d598c734f83cd0fba49b651315c6e9c8aac
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4440
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
This implements the "rule of 5" for this type. While the copy operation for
BString was already using shallow copies of the underlying data, this change
further optimizes moving the data from one object to another.
While it is not the intention to implement move semantics to all types in the
legacy Haiku/Be kits, data types like BString are good candidates, because move
operations are often useful when working with data within an application.
In this implementation, the internal data of the string object will be set to
NULL, thus leaving an empty string.
Change-Id: I16bf9424f9b17f622b0b57659b80628e18760288
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4428
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
* Drop ArchUART8260 layer to reduce complexity. It's whole
existance in life was to adjust the mmio alignment.
* Fold architecture mmio alignment into DebugUart
* We could potentially pass a Init(int mmioAlignment)
arg in the future if the macros get too messy.
* Move Barrier code back a layer into DebugUART
* Fixes the arm uart and EFI build
Change-Id: I0f127d902993e9f6e6a03cac8c7c37c0363134bf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4422
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
The USB Kit uses it, so this allows the USB Kit to stop including
USB3.h.
Change-Id: Ifde025ec41bef92013fda0440d60b7216cfdbe4a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4413
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* We really should get out of the habbit of making up
our own architecture defines.
* __riscv with an additional __riscv_xlen is the
standard that developed... let's just roll with it.
Change-Id: Ieb777d48340ae25a6d66f66133afa0ec5c6da9b6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4402
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Including thread.h brings a massive array of things with it from
the kernel thread arch headers, team and thread definitions,
hash tables, linked lists, Referenceable, etc. that the vast majority
of AutoLock.h consumers neither want nor need.
So, put these in a separate header, and adjust all consumers of these
lockers to include the new file.
This change exposes the fact that a lot of files were inadvertently
making use of headers included indirectly through thread.h. Those
will be fixed in the next commit.
Previously these were just using the raw function name, which led
to markers like "Slab_begin". Now we prefix RANGE_MARKER_ so there
is absolutely no chance of confusion, and the symbols are clearly
visible in dumps.
Also add a note that the kernel must be built with -fno-toplevel-reorder
for these to work. (It seems when this was implemented, GCC had not yet
implemented top-level reordering.)
They are only used for debugging with the tracing system in a handful
of places, and -ftoplevel-reorder is enabled with optimizations for
a reason, so it makes more sense just to note this and not to enable
that option by default (i.e. in the off chance someone will want to
use these in non-debug builds, like I did.)
If the timeout is already >= B_INFINITE_TIMEOUT, we do not need
to do any of the following math (which would usually overflow anyway)
and can leave the timeout alone.
Spotted by kernel undefined behavior sanitizer.
Define thumbnail attributes in Attributes.h:
Media:Thumbnail to store the thumbnail,
Media:Thumbnail:CreationTime to see if thumbs need to be regenerated.
Store 128x128 thumbnail in attribute, for icon sizes smaller than
128x128 down-scale the 128x128 thumbnail. Use B_FILTER_BITMAP_BILINEAR
to down-scale the image using the bilinear scaling algorithm which
creates nicer looking thumbnails than the default scaling algorithm.
Store thumbnails as WebP images which compress smaller than PNGs and
fit in the inode better at 128x128.
Check the file's modification time in GetFileIconFromAttr() and compare
it to the thumbnail creation time. If the file has not been modified
since the last time we generated thumbnails return the thumbnail from
the attribute, otherwise fetch a new thumbnail with GetThumbnailIcon().
Add "Generate image thumbnails" Tracker setting. Default is turned off
for now. To generate image thumbnails you must first turn this setting
on in Tracker Windows preferences.
Spawn a get_thumbnail() thread to generate thumbnails and retrieve them
later on from the window thread to fill out into the icon. This should
improve responsiveness of generating thumbnails from a folder with a
lot of images. The generator thread will write the thumbnail data to an
attribute if on writable BFS volume.
If not on writable BFS volume, the generator thread will send the data
back to the original thread through a port by calling write_port().
When the thread is finished creating the thumbnail it sends a message
back to the Tracker application thread to update the pose which
instructs the window thread to look for an thumbnail. It either finds a
thumbnail in an attribute, or picks up the thumbnail data that has been
sent through write_port() using read_port().
This works on both read-write and read-only BFS volumes but it still
depends on the presence of a BEOS:TYPE parameter to have been written
to the volume before it became read-only. Thumbnail generation does not
work on other read-only volumes for example an ISO-9660 CD, but it does
work on read-only BFS volumes for example the BeOS R5 CD.
Move BPrivate::CheckNodeIconHintPrivate() from BNodeInfo to Tracker
Model CheckNodeIconHint(). Create Model::CheckAppIconHint() and look
for a vector icon or mini and large icon in that method. Check that
the base type is directory, volume, trash, desktop, or if executable
call CheckAppIconHint().
Add 1 to temp_name to fix the following warning:
src/kits/tracker/FSUtils.cpp:2437:12: note: 'snprintf' output 3 or more
bytes (assuming 267) into a destination of size 266
Rename temp_name to tempName following our style guidelines. Use
strlcpy() and strlcat() instead of strcpy() to safely copy the string.
This fixes thumbnail generation on 64-bit Haiku.
Change-Id: I7f927a5a1f8cf65e4b1aa1e0eb55bbfae87fd969
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3163
Reviewed-by: John Scipione <jscipione@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* This models the CpuInfo into a cross-architecture
platform_cpu_info
* Originally I was looking at merging this with "arch_cpu_info"
however that is "overall cpu" while CpuInfo is "indivial core
information" packed into an array.
* Since every dtb platform will report individual cores in fdt,
having a common cpu core info struct with at minimum the core
id makes sense.
* This could likely be refined further to some kind of core info
packed inside of arch_cpu_info, but this will fix arm,arm64,etc
for now until someone wants to dive into that.
Change-Id: Ia18a352403cd0da7130c1e637fc205d4311478ef
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4363
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Change-Id: I6cb31760519c8ba4542d217d6e68439602eda558
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4356
Reviewed-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Change-Id: I4b8f69271ede117701725f9cce30de5bb8ba30bb
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4332
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
It allows to call destructor function stored in struct object such as
device_manager_info::put_node.
Change-Id: If9162f2f449d2b1c52c39509fa8732f21debf04a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3484
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
- Remove Pause/Resume functions. They are not possible to implement (the
server would time out)
- Fix SetContext(NULL) to do the right thing.
Change-Id: I25ba09bb01ea0fe8a85d774611b33be7dc192028
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4245
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Niels Sascha Reedijk <niels.reedijk@gmail.com>
The APIs for this were introduced in ICU 63, so we'll need an update.
ICU 63 does not build with gcc2, so this method is disabled there.
Change-Id: Iabe49509ed6d4e578560d497d3ca336a97db4625
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1874
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Fixes:
* scsi: Fix a bug that caused the device capacity to be set
to an undefined value for some large SCSI devices when
READ CAPACITY (16) was used
* ahci: Fix VPD page reporting so that it does not return
undefined values
* ahci: Set the write bit to true when sending a DATA SET
MANAGEMENT (trim) command to a device. The command would
otherwise fail and time out on some devices.
Improvements:
* scsi: Extend the READ CAPACITY (16) support to also
include logical block provisioning information
* scsi: Prefer READ CAPACITY (16) over READ CAPACITY (10)
on devices that are expected to support this command
* scsi, ahci: Enable trim on SCSI and SATA devices that
are expected to support trim and which correctly report
trim support
* ahci: Redo the implementation of the SCSI UNMAP command
* scsi: Redo UNMAP-related code
* scsi: Add support for UNMAP via WRITE SAME (10) and
WRITE SAME (16) commands
* When copying trim ranges between different data types,
make sure that the values don't change (detect overflows)
* Report the number of trimmed blocks even if the trim
operation fails
Change-Id: Ie5fc993bbbc19546b4308138ba10184bf7b9986a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4157
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Fixes:
* Use uint64 instead of off_t when handling offset and size
of the trimmed range in the fs_trim_data structure
* BlockAllocator::Trim: Correct the size of a buffer
* ram_disk, mmc: Do not trim past device capacity
Improvements:
* BlockAllocator::Trim: Because the received offset and size
are ignored by BFS (the functionality is not implemented yet),
return B_UNSUPPORTED if the range does not cover the whole
partition
* ram_disk, mmc: More accurate calculation of the number
of trimmed bytes
* devfs: Add a uint64 version of translate_partition_access()
Change-Id: I24f4c08674f123ad33a5fef6e28996a4ada6ff0d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4155
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* Makes the case where the loader and the install differ by
release type, so that the icons are rendered in the same
position
Change-Id: I01e48109ce127b202ce5e05544aa2d5a495ed53e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4162
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
