vendor_id shall come after the bitfields
Move hpet_address to separate struct definition so we can apply
the correct packed flags.
see also: https://wiki.osdev.org/HPET
Change-Id: Iced005846fedd4b895910e9b61137d5349db5b41
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4859
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* The "size" parameter is the size of "out" not "in", and the
return size_t parameter is supposed to always have the total amount
of wchar_ts needed, not how many are actually used.
* In the case where "outSize == 0", we set "requiredSize" and then
return.
Fixes crashes seen in glib2 Unicode collation routines, which
are used in GTK file dialogs.
Thanks to PulkoMandy for glancing at this.
Change-Id: Iff9e4198aca706097889faf51e9559fe551126ad
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4782
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* We pack the first 8 bits into a union for the raw
edid since alignment matters.
* Handing the raw_edid is a bit ugly, so in the edid struct
we drop the input_type from the union since packing doesn't
matter as much.
Change-Id: I32dbfe9484f9eb83cf491a44d30a32ca36d65b7b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4775
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* Working under qemu smp 1,2+
* Working on SiFive Unmatched
* x86_64 efi not broken by smp_boot_other_cpus change
Change-Id: I32ebc17913e46ed082be9ade8f56448bbf12f16e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4705
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
For now this is used on RISCV64 to indicate that interrupts will always
be on CPU 0. However, in the future, some architectures may want
or require interrupts to be "steered" in various ways, and this
also paves the way for that.
Change-Id: Iec79870cf5c4898d102d0e624de19602271ae772
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4721
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Before 2019, the entire ConditionVariable system was "giant"-locked:
that is, there was a single global lock that all ConditionVariable
and ConditionVariableEntry operations had to pass through. This of
course was not very performant on multicore systems and when
ConditionVariables see significant use, so I reworked it then to have
more granular locking.
Those patches took a number of attempts to get right, as having two
objects in separate threads that can each access the other not turn
into a deadlock or use-after-free is not easy to say the least,
and the ultimate solution I came up with erased most of the performance
gains I initially saw on the first (partially broken) patchsets.
So I have wanted to revisit this and see if there was a better way
even since then. Recently there have been a few reports of
ConditionVariable-related panics (apparently double unlocks),
notably #16894, and so that was reason enough to actually revisit
this code and see if a better solution could be found.
Well, I think I have come up with one: after this commit, Entries
no longer have their own lock, and instead accesses to Entry members
are almost always atomic; and there is now a case where we spin inside
Variable::_NotifyLocked as well as one in Entry::_RemoveFromVariable.
This leads to somewhat simpler code (no more lock/unlock dance in Notify),
though it is significantly more difficult to understand the nuances of it,
so I have left a sizable number of comments explaining the intricacies
of the new logic.
Note: I initially tried 1000 for "tries", but on a few instances I did see
the panic hit, strangely. I don't think the code that is waited on can
be reasonably reduced any further, so I have just increased the limit to
10000 (which is still well below what spinlocks use.) Hopefully this suffices.
Quick benchmark, x86, compiling HaikuDepot and the mime_db in VMware, 2 cores:
before:
real 0m23.627s
user 0m25.152s
sys 0m7.319s
after:
real 0m23.962s
user 0m25.229s
sys 0m7.330s
Though I occasionally I saw sys times as low as 7.171s, so this seems
to be at least not a regression if not a definitive improvement.
Change-Id: Id042947976885cd5c1433cc4290bdf41b01ed10e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4727
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
GCC still assumes that the dirent has no data past the end for some
scenarios here and still mis-optimizes things. Therefore, drop the
usages of unions altogether, and instead use a casted character array.
Additionally, use B_FILE_NAME_LENGTH for the array, not B_PATH_NAME_LENGTH,
and make sure to add 1 for the NULL terminator.
The lock entry is the first thing in the struct, so this is a no-op
change, but it is safer to do in case of changes, of course.
Spinlocks have been structures for quite a long time, so this was
probably just missed in the conversion.
we don't sample if the last sample is too recent and use the cached result.
Change-Id: I17ed29bda7fe7276f1a4148b3e1985c9d32ae032
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4101
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This file should ideally contain only those things needed
across all system headers, even POSIX ones, and all other
declarations (B_* ones especially) should go in SupportDefs.h.
However, as nothing but riscv64 uses this right now, I've just
moved it to there.
GCC 11 treats [1] as a fixed-length array and not a flexible-length
array, and so some things that used direct strcmp("..", ent->d_name),
for instance, would be optimized out as being always unequal,
which was the cause of #17389. Using a real FLA informs GCC that
there is going to be more than one byte of data, and thus this
fixes that bug.
BeOS used [1] and not [0], possibly because it had to deal with
compilers (MetroWerks? Early GCC2?) that did not support FLAs.
GCC 2.95 does, using [0], and GCC 4 does, using [], so we can go
with that here.
(I did try using [0] for both, which seems to be OK with GCC 11,
but GCC 8 throws errors when d_name is dereferenced directly
as being-out-of-bounds. So, we have to use the #if here and give
newer GCC the [] syntax and not [0] to avoid that problem.)
The real question probably is whether or not we should backport
some variant of these changes to R1/beta3, as software at HaikuPorts
very well may run in to the same issue. (The alternative workaround
is to compile with -O1 and not -O2 for any affected software.) But
maybe this is an argument for keeping with the beta4 schedule of
this coming January...
At present, it does, but that is an oddity we have preserved from BeOS
that the next commit is going to remove. (This commit thus wastes 1 byte
without the following one.)
Most changes are pretty straightforward: only a +1 is needed,
and a few removed from sizing calculations. Some filesystems like UDF
originally passed back the length with the \0 included, so they have
been adjusted further. UFS2 had some other sizing problems which are also
corrected in this commit.
Our dirent structure is "slim": it has a flexible-length array at the
end which must be allocated to whatever size the consumer wants. However,
we use [1] there and not [0] or [], which meant GCC thought it was not
a flexible-length array, and so it optimized various string accesses
that it assumed must be always false. Among these was BDirectory's
check for "." and "..", and so that resulted in infinite loops.
When changing our dirent structure to a proper FLA instead of [1],
GCC then throws errors on LongDirEntry as it has data "after" the
FLA; which is what we want, but there is no way to tell GCC that.
So now we use a union instead, which is the proper way to statically
allocate a FLA.
This is part of #17389, but the real fix requires changing our dirent
structure, which is coming in a separate commit.
* A few things need alignment, instead of forcing them all
to align themselves, support alignment of the kernel_args
* Default of 1 is "no alignment"
Change-Id: Iff05dcec8adaa963c8444d701464ea11616062f6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4698
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
In most cases we don't need to use the complete display_mode struct and
we just need the timings. This will avoid future confusion between the
virtual width/height and the actual display timings, if we implement
scrolling someday.
Change-Id: I6c4430b84130b956a47ea0a01afb0843f5a34fd2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4665
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This way it becomes much easier to write multiple console implementations
in one bootloader.
Tested for bios_ia32 and efi.
Change-Id: I67134f5c3de109b15d46898864ba7f51c6592afc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4642
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This cuts out almost 40,000 lines of these headers. (I did something similar
in the atheroswifi AR93xx/94xx driver when importing it from FreeBSD,
which had a lot more than 40,000 lines.)
These will be needed to implement custom modes in the VESA driver.
Change-Id: I9b52de691baa14e1f1a3ccce500ced9bb040b113
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4622
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Now that it is not used anywhere in the source tree following
previous commits.
Change-Id: Id2fc417a0658d09148e99587c613a928f1fbe4c2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4611
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This reverts commit 3e8376c6dd.
Reason for revert: Bootloader currently fails to load kernel
It should be added back once the kernel can start.
Change-Id: Iebefbf8681aff4dff09cef7b7eb832b61f7789c7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4579
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Someone on the internet found out gcc only understand posix_memalign.
The alloc_align attribute may be applied to a function that returns
a pointer and takes at least one argument of an integer or enumerated
type. It indicates that the returned pointer is aligned on a boundary
given by the function argument at position.
Change-Id: I4b0af6ef3020da1fb460652117286193d5d72f1e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4514
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Change-Id: Ifadd47204be1ec688017a567d43dca38c80bd1df
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4431
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Set first stack frame return address to
<commpage>commpage_thread_exit, so it will be called
when thread entry point returns.
Change-Id: Ide5cde8d4501eb7241e03ff4052174e984e78870
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4493
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
These were used in function_remapper.cpp but can be used elsewhere too,
so move them to a private header. Also use them for the stack protector
hidden function definition (probably not so useful since gcc2 doesn't
support using the stack protector anyway?).
The gcc2 way to make a symbol hidden is to manually generate the .hidden
directive in the assembler output. This is not perfect: it is hard to
use for C++ functions and methods (manual mangling of the name is
needed), and inline assembler can only be inserted inside functions. But
the alternative is patching gcc2 to add support for the function
attribute, and I don't want to dig into that today.
* PCI ID's from Linux
* There are a bunch of NAVI quirks around 3d rendering pipelines
but not many around modesetting (which is the only thing we care
about)
Change-Id: If63e31fe1d37d9d95f2a71c222a4cda7a2914a5e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4467
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Only one code change: for some reason, GCC chokes on the cr3 functions
as macros (throwing errors about invalid registers.) The BSDs have them
as inline functions instead, so they are converted to that here.
Tested and working. There seems to be about a 10% decrease in CPU time
on some compilation benchmarks that I briefly tried.
Change-Id: I31666297394d7619f83fca6ff5f933ddd6f07420
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4515
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@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>
* 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.
* 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>
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>
This also keeps the functionality of hrev53848, which simplifies the
list of disks searched for bootable partitions; however, it maintains
the previous behaviour of platform_get_boot_partitions that continues
to iterate over a list of possible boot partitions, which should
allow finding a bootable BFS partition better in more circumstances.
Particularly, there are numerous reports of the UEFI loader entering
the boot menu despite it finding a bootable partition, which this
should address.
EFI's device_contains_partition is also structured such that it
compares the disk GPT table of the partition the loader is
querying of the EFI disk's GPT table, in the case that there are
multiple disks, as the most reliable method of comparison, with
a generic fallback for non-GPT disks, which will be less reliable.
This reverts commit 0d932a49ad.
Change-Id: I5fac8608035d56b8bb4dc6c3d495ec6db42fa9b7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4149
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* This will break previus ways to store settings (as it only stored a struct)
* Now we use BMessage to save data.
* Added some stuff to SettingsMessage.
* Fix a bug in BluetoothSettingsView::_GetClassForMenu() and SettingsMessage::SetValue
Change-Id: I6a0fa1564e78460258f480947592eb4007985007
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3887
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
the AC flag in eflags/rflags, pushed in the iframe by the CPU, is kept intact after handling the exception, since the fault handler is run with the faulted iframe and does a simple jump. The AC flag would otherwise be set until the syscall returns to userland.
Change-Id: I24f763032ab98029dd162fb411e1541586451606
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4040
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
It is not present in BeOS R5 and it just call unload_driver_settings.
Replace delete_driver_settings usages with unload_driver_settings.
Keep the symbol on x86 for binary compatibility.
Change-Id: I1382710e3a4cb5c65d1249ea0e5880891e6800e4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3485
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
It cause adding new entry to executable init array for each translation unit.
Change-Id: I1e2d7946da03c001de7721948bc9af8188e8b317
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3981
Reviewed-by: X512 <danger_mail@list.ru>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
this adds kernel & libroot stack protector hooks. it uses /dev/random in userspace.
A configure option --enable-stack-protector is added to activate -fstack-protector
on selected system components (ATM apps, kits, servers).
Change-Id: If3a2920ba9aa0a85eaff4ba6778947f8c76ade31
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3895
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* Thanks to kottan I notices something was of..
* Added uInt16 and uInt64, I was missing UInt16.
Change-Id: Id136dbb5a81392a7a694ac1fbbd9aefbd7f77af3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3888
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* Move SettingsMessage
* Remove SettingsMessage from MediaPlayer and WebPositive
* Use the central SettingsMessage in MediaPlayer and WebPositive (Later Bluetooth)
* Fix a Jam file.
Change-Id: I3bb82a40082c5ece5c2aea2468a77bcd9f15ce77
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3856
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* Inactiveate button and things that don't do anything.
* Those button and controlles that hade any actions in the Bluetooth Pref now saves in settings.
* Fix some windows/views.
* Fix Copyright in last Bluetooth commit.
* Last commit before we move saving settings with BMessage.
* Changed PoupMenu to BOptionPopUp
Change-Id: I32b85f1985b558d24b294a184665e08e6ce18a7d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3829
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This is not my code but from ticket #9265
* Made a picture of how it looks, old left andnew right. https://imagebin.ca/v/5wIe6TIMzw4C
* Think we have a bug somewhere and don't store the name of the Bluetooth device (shown i the image).
* I have made som small changes but other than that it's the same code as in the ticket
* Ran the src/tools/checkstyle/checkstyle.py to get som style stuff, probably missed some anyway.
Change-Id: Ifeb75c8ad890f541e100cdcf78b394675a48ada9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3825
Reviewed-by: Fredrik Modéen <fredrik@modeen.se>
Various projects, both commercial and OSS, began to use inclusive
terminology. There is no reason to not do it.
In Haiku, bootloader uses Blacklist, which is recommended to replace
with Denylist or Blocklist. I think Blocklist is appropriate here,
since it's a list used to block offending driver at boot.
Some strings remain unchanged for compatibility with previous naming,
but this change prepares for later removal of these (once everyone has
updated their kernel and bootloader).
Change-Id: Id9105ff5e9fcb866000355089b5ef97bf63ee854
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3145
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
a protection_max attribute is added in VMArea.
a read-only opened file already can't be mapped shared read-write at the moment,
but can later be changed to read-write with mprotect() or set_area_protection().
When creating the VMArea, the actual maximum protection is stored in the area,
so that it can be checked when needed.
this fixes a VM TODO.
Change-Id: I33b144c192034eeb059f1dede5dbef5af947280d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3804
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The standardized version of readv() and writev() take an int as the third
parameter. Arguably a size_t makes more sense, but the standardization bodies
decided otherwise.
The non-standard functions of readv_pos() and writev_pos() have been updated
for consistency. The corresponding _kern_readv() and _kern_writev() internal
functions continue to take the size_t parameter.
The ABI will not change, even though on 64 bit machines the size of the count
parameter will change from 8 to 4 bytes.
The actual use will be slightly different. Like with the size_t argument type,
it will not be possible to give a count lower than 0. If the value is less than
0, then the B_BAD_VALUE/EINVAL error will be set.
Change-Id: I949c8ed67dbc0b4e209768cbdee554c929fc242e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3770
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Do the final installation operations for all the packages in the
/system/packages directory when the OS is booted for the first time.
This will run their post-install scripts, create users, groups and generate
settings files (marked with a package version attribute). Previously we just
ran all the shell scripts found in the /system/boot/post-install directory
(don't do that as much now).
Fixes bug #14382
This patch has simpler code flow in CommitTransactionHandler::_ApplyChanges
Tested on 32 and 64 bit systems. Once it's official, need to remove the
open_ssh redundant post-install script that creates users etc. from HaikuPorts.
Now we can notice bugs like package version attributes on settings files aren't
fully working. :-)
Didn't remove special case for add_catalog_entry_attributes.sh since it
still does stuff that the build system doesn't do. Might be able to add
that script as part of the Haiku.hpkg. See change 3751 for removing it,
https://review.haiku-os.org/c/haiku/+/3751
Change-Id: I3807b78042fdb70e5a79eca2e2a45816ece0236f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2342
Reviewed-by: Alexander G. M. Smith <agmsmith@ncf.ca>
Reviewed-by: Niels Sascha Reedijk <niels.reedijk@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Previously, BUrlRequest returns data received via a callback that can't
return any value. This approach have several issues:
- It's not possible to signify failures to the request.
- Users have to implement custom listeners just to handle the common
case of outputting to a buffer/file/etc.
- The received data has to be serialized into BMessage when
BUrlProtocolDispatchingListener is employed. This can cause a
noticible slowdown in real-world scenarios as evident by #10748.
With this change, BUrlRequest will output directly into a BDataIO, which
exposes a richer API for request handlers to work with (for example a
BitTorrent client can request a BPositionIO for non-linear data
delivery), as well as simplifying common cases for users.
The adaptation only requires one additional API:
BHttpRequest::SetStopOnError(). This API simply instructs the HTTP
request handler to cancel the request if an HTTP error is occurred.
Change-Id: I4160884d77bff0e7678e0a623e2587987704443a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3084
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The switch to make BUrlResult serializable was debuted in
f9e1854f19 with the rationale is that
BHttpRequest auto-redirection might cause the headers to become
obsolete by the time a client process the BMessage received from
BUrlProtocolDispatchingListener.
With the change to BHttpRequest to not notify listeners when
auto-redirection is enabled, this is no longer the case and the
serialization code can go away now. This simplifies BUrlResult and its
subclasses, and gain us some performance for clients using
BUrlProtocolDispatchingListener as the result object no longer has to be
serialized.
This also change the ABI of BUrlProtocolListener::HeadersReceived to no
longer passing a BUrlResult.
Additionally, BUrlResult and BHttpResult now express the size of the content
as an off_t, thus allowing results larger than 4 GB.
Change-Id: I9dd29a8b26fdd9aa8e5bbad8d1728084f136312d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3082
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Further removal of the use of custom list class;
this time with the package lists.
Relates To #15534
Change-Id: I1f01ed9d5ddbd7754097ce0adbf505d6ba17fd2f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3732
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This change only applies in libnetservices.a. The implementation in
libbnetapi.so will use the original definitions.
Change-Id: I0aaa5a40af5fbcafaf233c32206cb4af862f8141
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2465
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The BGeolocation class uses the network interface in libnetservices.a, so it
is moved here for now.
This will break any out of tree projects that depend on it, but it is a source
incompatible change only.
Change-Id: I6f5b1332eb87ad37dd33fbe09fdb11b16f7f26e4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3670
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
In order to prevent classes between libnetapi.so with the legacy API and
applications using the libnetservices.a library, the latter will have the
classes in a distinct namespace.
In the implementation, both libbnetapi.so and libnetservices.a will use the
same header and source files. If LIBNETAPI_DEPRECATED is defined during build,
the headers and source will have binary compatible behavior. Otherwise, the
classes and other objects will be put in the HaikuExt namespace.
In order to build the libbnetapi.so and libnetservices.a with the proper
build configuration, there is a stub `src/kits/net/libnetapi_deprecated` folder
that applies the special configuration to the source files.
Currently HaikuDepot, Webpositive, libshared.a and the http_streamer add on
use the compatible API in libbnetapi.so.
Change-Id: Ic73e9f271ef75749adda46f6f72e9a0b2851b461
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3667
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
These classes have been moved to the public API too soon, and they need some
more time to mature before they can be declared stable.
Change-Id: I9c52a8e6cc103922abde7a6b911fe0c3e6bf5700
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3665
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Store the bus cookie in the mmc_disk driver and pass it to the bus
manager when executing commands. This avoids calling into the device
manager at each read and write operation. The code to get the cookie
from mmc_disk isn't so nice since it needs to access the grandparent
device (the mmc bus root), it would be simpler if this cookie would be
available directly from mmc bus devices.
We can get card removal and card insertion interrupt at the same time
due to insufficient hardware debouncing (the SDHCI spec says we
shouldn't, but it happens on Ricoh controllers. Can't blame them, they
don't advertise themselves as compliant with the spec). So, check the
card status from the interrupt handler and ignore the incorrect
interrupts.
Fix unreliable card initialization: power must be turned on before
starting up the SD clock. Remove a now unneeded delay that was added in
an attempt to avoid initial instability.
Change-Id: Ibd8d051da1a1d859f3924ee535f4a05d9b6398d4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3639
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
It works, but performance is still unexpectedly low (getting about
50kB/s write speed) with almost no CPU load.
Change-Id: I7da3ee70c8b379c4e6c2250d67f880c78635874f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3630
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
* otherwise the signal to be handled might be blocked. fixes#15193
* also remove automatic syscall restart on _kern_select, to match Linux and
BSDs behavior: this fixes parallel build with newer gnu make, which happens
to use pselect.
* also remove automatic syscall restart on _kern_poll.
from https://man7.org/linux/man-pages/man7/signal.7.html
"The following interfaces are never restarted after being
interrupted by a signal handler, regardless of the use of
SA_RESTART; they always fail with the error EINTR when
interrupted by a signal handler: ...
select(2), and pselect(2)."
from https://notes.shichao.io/unp/ch6/
"Berkeley-derived kernels never automatically restart select."
Change-Id: I3e9488f60c966b38d427f992f06e6e2217d4adc5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3636
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
* otherwise the signal to be handled might be blocked. fixes#15193
* also remove automatic syscall restart on _kern_select, to match Linux and
BSDs behavior: this fixes parallel build with newer gnu make, which happens
to use pselect.
* also remove automatic syscall restart on _kern_poll.
from https://man7.org/linux/man-pages/man7/signal.7.html
"The following interfaces are never restarted after being
interrupted by a signal handler, regardless of the use of
SA_RESTART; they always fail with the error EINTR when
interrupted by a signal handler: ...
select(2), and pselect(2)."
from https://notes.shichao.io/unp/ch6/
"Berkeley-derived kernels never automatically restart select."
Change-Id: I7f86d221eae1ad93d8a308a75581d2c30a369c9e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3627
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
- Switch to 25MHz clock
- Switch to 4bit transfers mode (the default is 1bit)
Reading and writing SD cards do not seem to work anymore with these
changes. I get invalid data on read, and on write, an interrupt is never
called in some cases.
On sparc, the minimal page size we can use is 8K. Since B_PAGE_SIZE and
PAGESIZE defines were hardcoded to 4K, this resulted in a lot of
confusion in all code trying to manipulate pages.
- Remove cpu.h from headers/private/kernel/arch/*. It dates back from
NewOS and was not used anymore since our kernel uses B_PAGE_SIZE
(PAGE_SIZE was the only thing defined in this header).
- Add posix/arch/*/limits.h with the arch specific page size and include
it from the main limits.h.
- Adjust bios_ia32/debug.cpp which was the only place using the
PAGE_SIZE constant from the deleted headers.
- Change OS.h to define B_PAGE_SIZE to be the same as POSIX PAGESIZE.
- Define PAGESIZE in the build header if the host OS doesn't.
Change-Id: I8c3732cf952ea3c2f088aa16d216678fbf198b96
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3558
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The main differences:
- The initialization sequence requires an additional command (this was
already done)
- The layout of the CSD register and the way to compute the device
geometry from it changes
- The read and write commands parameter is a sector number instead of a
byte position
Change-Id: Ie729e333c9748f36b37acd70c970adfd425cf0b6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3512
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
The SDHCI spec also offers an "advanced DMA" mode where we can use
scatter-gather lists. It would allow to remove several of the DMA
restrictions, but hardware support for it is optional, so we need this
version anyway.
The geometry is retrieved on demand in the first read or write or in a
call to the get geometry or get device size ioctl. It is not possible to
retrieve it from the device initialization because that is called as
part of the mmc_bus scanning, which needs a specific sequence of
commands and keeps the bus locked to prevent drivers to insert their own
commands in the middle of that sequence.
TODO:
- Move the DMA restrictions definition to sdhci_pci and forward it up to
mmc_disk (which is the one creating the IOScheduler)
- Decide if we want to keep non-DMA support (probably should, but it
makes things more complex, because it uses virtual addresses)
Change-Id: Ib1dd14eacf62052d747bfb3ef7820bc5a34d3030
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3471
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* The "default" of 3MiB wasn't enough for modern larger media
formats, resulting in inability to play 4k video no matter
how much horse power you threw at Haiku. (4k is ~8MiB)
* This dynamically calculates the ChunkCache based on the
video framesize * 2.
* 4k video now plays smoothly on my Ryzen 1800x.
Change-Id: I65bf6bd6fa60ac3196ea70eeeb5e655d43c10bcd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3598
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Mostly the same as PowerPC, using OpenFirmware.
Change-Id: I197cc181e92da92c272ee9cfa20c8ad2d2c63d41
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3579
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The manually written code was all wrong (missing branch delay slots,
wrong type of return instruction used, probably more bugs). Use the same
approach as x86 to have inline functions instead, which is much better
for performance and simpler to write.
Change-Id: Iac0fc814c15311658f983da58ac7f9d3edd75b81
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3595
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The definition in SupportDefs.h using gcc builtins is sufficient. No
need for a custom one. The same approach is used on x86 with gcc8
already, but other platforms had not been adjusted to use it.
Change-Id: I3973ff723a31f90cc8d19ac098eb1e85d471d610
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3594
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The sparc ABI reserves the g7 register for this.
Change-Id: I93b81ecef72cde859972ef7b7f6b9991d35f9f29
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3583
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It was bumped for bios and efi from previously very low values, but
other architectures did not follow.
Change-Id: I6ce92e2cdb0261d4d0637753e77d555d407073fc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3575
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Introduce fat_shell for build system fat manipulation
* Will theoretically let us do away with mtools when we
have another internal tool for partition manipulation
Change-Id: I661be556e79009842f157a9402c8f85da85d6336
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3556
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
la57 kernel support is required. we simply add a 5th level and enable the cr4
feature. the safemode option "256tb_memory_limit" is named after the 4gb one,
but the current support is limited to 512GB as before (this can be later extended).
Change-Id: I922774473c4a6112a0e4ff74162285ad58aa53af
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3552
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
* Makes our UEFI bootloader somewhat FDT/DTB aware on all
architectures.
* Will report when an FDT is found, and provide it to kernels
that want it.
Change-Id: I90324fc0579a9c835e60568fa9b654c2df0aba27
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3543
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
It allow to use arbitrary handle type, null value and destructor function.
Change-Id: I87c444cb7ef1b08d1dbed7fe4171700171d651d2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2977
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
First implementation of reading sectors from an SD card.
This is not the best performance for many reasons:
- No DMA
- Reads only one sector at a time
- Cannot read more than 512 bytes per syscall
Also there are major limitations:
- Cannot read less than 512 bytes. The hardware of course works in full
sectors. The mmc_disk driver should go through the io scheduler to
make sure requests have a reasonable size and offset, and nothing
tries to read just a few bytes in the middle of a sector.
- SD cards only (no SDHC, no MMC)
Architecture problems:
I think too much of the implementation is done in sdhci_pci and should
be moved to the upper layers. However it is difficult to say without
having implemented DMA (which indeed will be at the low level of the
sdhci controller). It doesn't help that the order of operations is a
bit different depending on wether there is DMA or not. In DMA mode you
first prepare the buffer, then run the command. In non-DMA mode you
first send the command, then read the data into the buffer. We need an
API at the mmc_bus level that doesn't care about that low-level detail.
There are other things that the MMC bus should be doing however, such
as switching to different clock speeds depending on which card is
activated and how fast it can go.
At least the following should be done:
- The read method for mmc_bus and sdhci_pci should use a scatter-gather
structure as a parameter instead of a single buffer
- See if can be integrated into ExecuteCommand at sdhci level (it's
essentially a command with an additional data phase)
Change-Id: I688b6c694561074535c9c0c2545f06dc04b06e7d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3466
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
No read and write support for now. But we implement getting SD card
capacity. SDHC is not supported yet (it uses a different layout for the
CSD register which will be rejected by this version of the code)
Change-Id: Ife844a62f3846c0a780259e9a3a08195e2fd965e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1068
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
C++ don't allow zero size class fields. If field with empty class field
is used, it's size will be 1 byte.
Create DeleteFunc instance as local variable at each use instead.
Fixes#16638.
Change-Id: Ifb76c45ea02e9fed014751542ee5f16f41e11d15
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3458
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The same as CObjectDeleter.
Change-Id: I85c4cb3635f01f13e529ca087324cc2fcb42cfc0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3456
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
It allows to make typedef of pointer types and declaring pointers in headers.
Store of destructor function pointer in CObjectDeleter is no longer needed.
Change-Id: Ic629fd10b28b09f4190edf8ba6b911ca3108ab0e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3455
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Only keep a fixed number of icons in memory at once.
Completes To #15370
Change-Id: I23e3a4fa7559894034f45afb3b536910ea037078
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3367
Reviewed-by: Rene Gollent <rene@gollent.com>
the preallocate syscall will call the preallocate filesystem hook, if available.
fix#6285
Change-Id: Ifff4595548610c8e009d4e5ffb64c37e0884e62d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3382
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Currently used by fixup_next_boot_floppy.
Change-Id: I47c10657b5280f00e470a3171ad11744859ce76c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3310
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
For now it just forwards the command to the SDHCI controller.
The bus will gain more features and functions as work advances (tracking
which card is active, arbitration of DMA transfers, etc).
Change-Id: I094eb84f27e7789387a3f8fb65fba1e5fcfa3e8a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3094
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Update BTab::DrawTab() to pass the current index, the index of the
selected tab, and the index of the first and last tabs into
BControlLook::DrawActiveTab() and BControlLook::DrawInactiveTab().
This allows you to draw tabs differently in your BTab or BControlLook
subclass in many different circumstances.
Modify BControlLook API to add indexes to DrawActiveTab() and
DrawInactiveTab() like so:
void DrawActiveTab(..., int32 index = 0, int32 selected = -1,
int32 first = 0, int32 last = 0);
void DrawInactiveTab(..., int32 index = 0, int32 selected = -1,
int32 first = 0, int32 last = 0);
These extra indexes are not used by HaikuControlLook which relies only
on if the tab is active or inactive to draw.
Add IndexOf(BTab* tab) method to BTabView and document it to get the
index of the current tab in BTab::DrawTab(). Also add a warning in the
BTabView::DrawTab() method not to use the position and full parameters
anymore, use BTabView::IndexOf(), BTabView::Selection(), and
BTabView::TabCount() to get the info you need.
Using a dynamic_cast to a BTabView in BeControlLook to determine if the
view is derived from a BTabView didn't work in the case of WebPositive.
Furthermore, WebPositive does custom tab drawing which needed to be
updated for alternative control look. These index parameters passed from
BTab to BeControlLook allow us to draw the tab like BeOS without relying
on a dynamic_cast to BTabView to get the info.
Reproduce the functionality described above for BTab in WebPositive's
custom tabs. Eliminate no longer needed code in favor of using indexes.
Update WebPositive custom tabs to use BControlLook::DrawTabFrame()
instead of BControlLook::DrawInactiveTab() matching the update made in
BTabView.
In BeControlLook::DrawTabFrame() fill rect with base color, WebPositive
doesn't draw any tab background, so it expects this work to be done for
it.
Eliminate hasFrames variable from WebPositive.
Rename TabSelected(index) to UpdateSelection(index) in WebPositive to
better reflect its purpose.
Adjusted HaikuControlLook::DrawInactiveTab() to draw the tab borders more
selectively. Only draw border if left border is set for top and bottom tabs
or top border is set for left and right tabs. Undo no longer needed frame
manipulation border drawing workaround in HaikuControlLook::DrawTabFrame().
Draw scroll bar triangle without using DrawArrowShape().
Unlike in HaikuControlLook, DrawArrowShape() is used to draw arrows in
BOutlineListView and menus distinctly from how it draws arrows in scroll
bars. Draw our distinct arrows in DrawSrollBarButtons() instead.
This fixes overflow of time edit up-down arrows in Clock prefs and the
collapse-expand arrow in Deskbar not being vertically centered.
In DrawBorders() only inset if we actually draw the border.
Fix alignment issues with DrawSliderThumb dots for example in
MediaPlayer volume knobs.
Draw using line arrays calling AddLine instead of StrokeLine in
several places.
DrawMenuBar() extends to draw final pixel which eliminates an extra
lines at the end of menu bars.
Truncate button labels better fixing a few issues for example keymap
keyboard layout button labels. Button insets has been updated a bit
to fix drawing issues with buttons missing a border.
Using a dynamic_cast to a BButton to determine if a view is a button
in BeControlLook didn't work in the case of the keymap label. Look for
B_FLAT, B_HOVER, or B_DEFAULT_BUTTON flag in BeControlLook::DrawLabel()
to draw the label inverted on click. Pass the B_FLAT flag from Keymap
keys when drawing using BControlLook so that the label is inverted.
Change-Id: I07631f4b006bdb9aeca2adc9cbdf2da54dae8e92
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2866
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
when the cpufreq module is loaded, we let the scheduler update its policy.
Improve assert report
CoreEntry::GetLoad() could return more than kMaxLoad.
Change-Id: I127f9b3e8062b5996872aae30b4021b9904fa179
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3216
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
implement on x86 with APERFMPERF.
Change-Id: Ia484854c76dee76c5447983de15800a25d791d39
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3213
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
to call a function on the target cpu. Early mechanism not available.
Change-Id: I9d049e618c319c59729d1ab53fb313b748f82315
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3212
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
This allows you to pass node_ref's around like you can entry_ref's.
Added node_ref_flatten(), node_ref_unflatten() and node_ref_swap() to
MessageUtils. These are close cousins to entry_ref_flatten(),
entry_ref_unflatten(), and entry_ref_swap() but for node_ref's.
Added B_NODE_REF_TYPE to TypeConstants.h in the Support Kit.
Added B_NODE_REF_TYPE to Debugger and ByteOrder in Support Kit,
B_NODE_REF_TYPE is treated the same as a B_REF_TYPE (entry_ref).
Add documentation for new NodeRef methods and B_NODE_REF_TYPE.
Change-Id: I32c6ed276bf1a7894a835b9fc9de5a882c35883c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3182
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
When a thread is created, it is expected that some other thread (usually the
creating thread) will want to make sure it completes. This is done using the
pthread_join() or wait_for_thread() calls.
It is possible that threads end before another thread waits for its completion.
That's why there is a dead thread list for each team, which holds thread ids
and their exit status so that a call to pthread_join() or wait_for_thread() in
the future can complete succesfully.
The dead thread list was limited to 32 threads per team. If there would be
more, the oldest thread would be kicked off. This could cause issues in
situations where a team would create more than 32 threads, and would start
waiting for their result after they have finished. Some of the calls would fail
because the threads would no longer be in the dead list.
This specifically caused problems for cargo (the Rust package manager), which
could depending on the number of dependencies, could create more than 32
threads. See: https://github.com/nielx/rust/issues/3
This change removes the limit of dead threads within a team. Note that there is
a risk that a badly written program that does not detach or joins its threads
can make this an endless list, but the impact is relatively small (dead threads
only occupy a bit of kernel memory).
Change-Id: I0135dd54e10ee48a529f23228d21237d4f1a74e2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3178
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The catalogs are loaded from separate files, so there is no need to have
an app entry_ref to load them, just a MIME type is enough.
The implementation is a bit simplified: only the default catalog format
is allowed (unlike when loading from entry_ref, where extra catalog
formats can be added in add-ons).
Unrelated cleanup: remove unused code to load catalogs from attributes
of an application. We considered this when designing the locale kit, but
using resources or separate files works better.
Use this in Cortex, where some strings are in a static library, so they
don't have an associated executable or library or add-on to identify
them. The code in Cortex is not complete localization, several parts
should use StringForRate, BStringFormat, etc.
Change-Id: I09be22b1f50891250c4497c51e1db8dcee279140
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3172
Reviewed-by: Kacper Kasper <kacperkasper@gmail.com>
When copying an area with vm_copy_area only the new protection would be
applied and any possibly existing page protections on the source area
were ignored.
For areas with stricter area protection than page protection, this lead
to faults when accessing the copy. In the opposite case it lead to too
relaxed protection. The currently only user of vm_copy_area is
fork_team which goes through all areas of the parent and copies them to
the new team. Hence page protections were ignored on all forked teams.
Remove the protection argument and instead always carry over the source
area protection and duplicate the page protections when present.
Also make sure to take the page protections into account for deciding
whether or not the copy is writable and therefore needs to have copy on
write semantics.
Change-Id: I52f295f2aaa66e31b4900b754343b3be9a19ba30
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3166
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Change-Id: Id050fad59ede444f2eab7eca681c6ec44612aaf9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3160
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: François Revol <revol@free.fr>
This enables generation of exceptions that are due to uncorrected
hardware errors. The exception handlers were already in place and will
now actually trigger kernel panics.
Note that this is the simplest form of MCE "handling" and does not add
anything of the broader machine check architecture (MCA) that also allow
reporting of corrected errors. As MCEs are generally hard to decode due
to their hardware specifity, this merely makes such problems more
obvious.
Might help to discern hardware issues in cases that would otherwise just
triple fault and cause a reboot.
Change-Id: I9e3a2640458f7c562066478d0ca90e3a46c3a325
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3155
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
- libicule and libiculx do not exist anymore in newer ICU versions
(harfbuzz replaces them), but we didn't actually use them, so remove
them from the build feature and from the package dependencies
- Add namespace usage marcos since the newer ICU packages put ICU things
in a namespace, making it easier to have multiple versions of ICU used
side by side.
No functional change intended, but this makes it possible to build the
code with either ICU 57 (for gcc2) or 66 (for other architectures).
Pages in the given range are unmapped and freed without getting written
back anywhere. It can be used whenever a caller does not care about the
data in the given range anymore and wants to reduce page pressure.
Change-Id: I8bcce68fab278efef710d3714677e1d463504a56
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2843
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Change-Id: Ifbd82ef7bfc2c39b2aeb5c25be177421cd22d246
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2920
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* Migrate some platform agnostic architecture code into
boot/arch from efi/arch. This helps to avoid conflicts
between kernel and boot sources as well.
* Conflicts between arch_cpu in efi and kernel code means
bootcode really should *never* directly use kernel arch
headers. (other platforms don't, which is why they don't
have this same issue)
* We carefully thread any needed kernel headers (namely
assembly helper macros) into the bootloader headers without
mixing in the whole conflicting kernel/arch headers.
* ARM now properly get its cpu init code called, and we
progress further into the EFI bootloader.
Change-Id: If67ec9758b5ce68563ebd9eb45d5196401911c67
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2975
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
None of these were used; they were all imported with the original
root Haiku commit, and they are totally unrelated to PulkoMandy's
new SPARC work. Plus, they were also under a BSD Advertising Clause
license.
Utilize user_memcpy and IS_USER_ADDRESS when necessary to prevent SMAP violations.
Also add a "wacom_device_header" struct to more easily share data between the wacom
kernel driver and input_server addon.
Should fix#14589
Change-Id: Ie2784020b21523f82fd450a2db2de60ccf9d6620
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2783
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* This allows file systems to retrieve the actual error code on a
failure, and report it to the user.
* All affected file systems have been adjusted to the API change.
This is a binary incompatible change.
Change-Id: Id73392aaf9c6cb7d643ff9adcb8bf80f3037874c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2913
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
xsave or xsavec are supported.
breaks vregs compatibility.
change the thread structure object cache alignment to 64
the xsave fpu_state size isn't defined, it is for instance 832 here, thus I picked 1024.
Change-Id: I4a0cab0bc42c1d37f24dcafb8259f8ff24a330d2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2849
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Otherwise it clashes with the implementation in OpenSSL which uses the
same names but now has a different ABI.
Change-Id: I5cb3ff97d7b28de978cdcbd8a06f25f65fb53784
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2854
Reviewed-by: Kyle Ambroff-Kao <kyle@ambroffkao.com>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
The code to parse the resource table reads one entry at a time because
the table size isn't known. This resulted in a lot of read syscalls,
each reading just 12 bytes. Use a BBufferIO to buffer these and reduce
the number of syscalls. This helps especially when there are lot of
resources, for example in libbe with all the country flags.
It also removes some spam from strace output for all these read calls.
Change-Id: Ib165a0eacc2bc5f3d319c22c2fac4f439efbdef2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2858
Reviewed-by: Rene Gollent <rene@gollent.com>
The goal here is to avoid potentially expensive fork()ing.
The time for a fork() is (for a process with no real heap usage
and thus few areas) 300-400us on my system. load_image() takes
3000us (3ms) or so, but this of course includes exec() time.
Overall, for compiling HaikuDepot (with a tweaked jam to use
posix_spawn on Haiku, not just on Linux) there is a slight
decrease in time:
before:
real 1m21.727s
user 1m2.131s
sys 0m43.029s
after:
real 1m19.472s
user 1m1.752s
sys 0m41.740s
Which is probably within the realm of "noise", so more benchmarks
are needed. Likely if we tweak our jam usage to not need as many
shells when running commands, this would be a much more noticeable
change.
Change-Id: I217f2476b1ed9aa18322b3c2bc8986571d89549a
It iterates over all areas intersecting a given address range and
removes the need for manually skipping uninteresting initial areas. It
uses VMAddressSpace::FindClosestArea() to efficiently find the starting
area.
This speeds up the two iterations in unmap_address_range and one in
wait_if_address_range_is_wired and resolves a TODO in the latter hinting
at such a solution.
Change-Id: Iba1d39942db4e4b27e17706be194496f9d4279ed
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2841
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This introduces VMAddressSpace::FindClosestArea() that can be used to
find the closest area to a given address in either direction. This is
now trivial and efficient since both kernel and user address spaces use
a binary search tree.
Using FindClosestArea() getting multiple area infos is sped up
dramatically as it removes the need for a linear search from the first
area to the one given in the cookie on each successive invocation.
Change-Id: I227da87d915f6f3d3ef88bfeb6be5d4c97c3baaa
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2840
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
They return the left and right most nodes of the entire tree, i.e.
starting from the root node.
Change-Id: I651a9db6d12308aef4c2ed71484958428e58c9bc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2838
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This reverts parts of hrev52546 that removed the B_KERNEL_AREA
protection flag and replaced it with an address space comparison.
Checking for areas in the kernel address space inside a user address
space does not work, as areas can only ever belong to one address space.
This rendered these checks ineffective and allowed to unmap, delete or
resize kernel managed areas from their respective userland teams.
That protection was meant to be applied to the team user data area which
was introduced to reduce the kernel to userland overhead by directly
sharing some data between the two. It was intended to be set up in such
a manner that this is safe on the kernel side and the B_KERNEL_AREA flag
was introduced specifically for this purpose.
Incidentally the actual application of the B_KERNEL_AREA flag on the
team user data area was apparently forgotten in the original commit.
The absence of that protection allowed applications to induce KDLs by
modifying the user area and generating a signal for example.
This change restores the B_KERNEL_AREA flag and also applies it to the
team user data area.
Change-Id: I993bb1cf7c6ae10085100db7df7cc23fe66f4edd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2836
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The code in the Resize and Rebase methods was identical except for the
iterator.
Change-Id: I9f6b3c2c09af0c26778215bd627fed030c4d46f1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2835
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This allows switching from another recursive_lock, mutex or read-locked
rw_lock analogous to the switching possibilities already in mutex.
With this, recursive_locks can be used in more complex situations where
previously only mutexes would work.
Also add debugger command to dump a recursive_lock.
Change-Id: Ibeeae1b42c543d925dec61a3b257e1f3df7f8934
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2834
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The memory map may be unordered and include overlapping ranges. To make
sure that nothing gets included as usable that should actually be
excluded, first scan for all usable ranges and add them, then remove
anything unusable from these ranges again.
To calculate the amount of unusable memory, count the total after the
first pass and then subtract the total after the second. This way, only
unusable ranges that actually overlap physical memory (and therefore
reduce the amount of usable memory) get excluded.
Note that the explicit ignore of the ACPI reclaim memory is subsumed by
the above. We still don't want to add this region to the usable memory
map, as that would allow the kernel to allocate pages into that region,
possibly corrupting ACPI tables before they were used. We also don't
want to add it as an allocated range, as it is not guaranteed that ACPI
is done with the tables before the unused bootloader ranges are freed in
the kernel.
Also add the missing unusable memory amount from ignoring the first MiB
of memory in the EFI loader.
May fix#16056 although it is not certain that graphics memory ranges
are actually included in the memory map.
Change-Id: Ie7991d2c4dcd988edac2995b3a7efc509fa0f4a3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2814
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
APE reader was using a GPL licensed version of MD5. A similar
implementation in the public domain was available in libnetapi, which I
moved to libshared so the APE reader can use it (and made some fixes,
missing const mainly). It only needs a small wrapper to use it easily
from C++ in a way compatible with the previous implementation.
Part of #13814.
I forgot to change MUTEX_INITIALIZER following removal of the
unused field.
Change-Id: I011c023ae00bb4576c8bcecf83546892fef3a77e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2719
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
As far as I can tell, there is no reason to ignore unlocks, ever;
if no threads are waiting, then mutex_unlock() will act appropriately.
So all we need to do is increment the lock's count here,
as we are relinquishing our request for locking.
On the other hand, if we did not find our structure in the lock,
that means we own the lock; so to return with an error from here
without changing the count would result in a deadlock, as the lock
would then be ours, despite our error code implying otherwise.
Additionally, take care of part of the case where we have woken up
by mutex_destroy(), by setting thread to NULL and checking for it
in that case. There is still a race here, however.
May fix#16044, as it appears there is a case where ACPICA
calls this with a timeout of 0 (we should make this be
a mutex_trylock, anyway.)
Change-Id: I98215df218514c70ac1922bc3a6f10e01087e44b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2716
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It is used by several of the filesystems, so it seems a good idea to
move it to the shared/ directory.
UFS2, BFS, XFS, EXT2 and EXFAT are adjusted.
Change-Id: I493e37a1e7d3ae24251469f82befd985a3c1dbdd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2489
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Rename MovePageRange to Adopt and group it with Resize/Rebase as it
covers the third, middle cut case.
Implement VMAnonymousCache::Adopt() to actually adopt swap pages. This
has to recreate swap blocks instead of taking them over from the source
cache as the cut offset or base offset between the caches may not be
swap block aligned. This means that adoption may fail due to memory
shortage in allocating the swap blocks.
For the middle cut case it is therefore now possible to have the adopt
fail in which case the previous cache restore logic is applied. Since
the readoption of the pages from the second cache can fail for the same
reason, there is a slight chance that we can't restore and lose pages.
For now, just panic in such a case and add a TODO to free memory and
retry.
Change-Id: I9a661f00c8f03bbbea2fe6dee90371c68d7951e6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2588
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Adds VMCache::MovePageRange() and VMCache::Rebase() to facilitate
this.
Applied on top of hrev45098 and rebased with the hrev45564 page_num_t to
off_t change included.
Change-Id: Ie61bf43696783e3376fb4144ddced3781aa092ba
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2581
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This code comes from an old Be Newsletter and since then the API
received the addition of SetMouseEventMask. In several places the
MouseDownThread was misused: it would spawn a new thread on every mouse
click and not clear the previous one. This could for example lead to
BSpinner skipping values if you clicked it at the right speed.
There are functional changes in BSpinner, before it updated for the
first time 100ms after mouse down, and then as you moved the mouse
around the button, now it activates immediately on first click and then
every 200ms (which may be a bit short). In other places, no functional
changes intended.
Change-Id: Ie600dc68cbb87d1e237633953e5189918bf36575
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2599
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
