This was converted to an enumeration for Intl.NumberFormat V3 in commit
33698b9615, but the default value was not
updated (and it's a bit surprising it compiled at all, given that this
is an 'enum class').
Besides from a general check if a file's directory has write
permissions, this also checks if the directory has set a sticky bit,
meaning that only file owners and the directory owner can remove or move
files in such directory. It's being used in /tmp for example.
This is the same address that the x86_64 kernel runs at, and allows us
to run the kernel at a high virtual memory address. Since we now run
completely in high virtual memory, we can also unmap the identity
mapping. Additionally some changes in MMU.cpp are required to
successfully boot.
Since we link the kernel at a high virtual memory address, the addresses
of global variables are also at virtual addresses. To be able to access
them without the MMU enabled, we have to subtract the
KERNEL_MAPPING_BASE.
Compile source files that run early in the boot process without the MMU
enabled, without stack protector and sanitizers. Enabling them will
cause the compiler to insert accesses to global variables, such as
__stack_chk_guard, which cause the CPU to crash, because these variables
are linked at high virtual addresses, which the CPU cannot access
without the MMU enabled.
This is a separate file that behaves similar to the Prekernel for
x86_64, and makes sure the CPU is dropped to EL1, the MMU is enabled,
and makes sure the CPU is running in high virtual memory. This code then
jumps to the usual init function of the kernel.
This was previously hardcoded this to be the physical memory range,
since we identity mapped the memory, however we now run the kernel at
a high virtual memory address.
Also changes PageDirectory.h to store up-to 512 pages, as the code now
needs access to more than 4 pages.
As the kernel is now linked at high address in virtual memory, we cannot
use absolute addresses as they refer to high addresses in virtual
memory. At this point in the boot process we are still running with the
MMU off, so we have to make sure the accesses are using physical memory
addresses.
This function will be used once the kernel runs in high virtual memory
to unmap the identity mapping as userspace will later on use this memory
range instead.
And use it the code that will be part of the early boot process.
The PANIC macro and dbgln functions cannot be used as it accesses global
variables, which in the early boot process do not work, since the MMU is
not yet enabled.
In the upcoming commits, we'll change the kernel to run at a virtual
address in high memory. This commit prepares for that by making sure the
kernel and mmio are mapped into high virtual memory.
When several tags refer to the same TagData object, we now only print
it the first time, and print "(see 'foob' above)" the following times,
where `foob` is the tag identifier where we printed it the first time.
Several tags can refer to the same TagData. In particular, the
rTRC, gTRC, bTRC tags usually all three refer to the same curve.
Curve objects can be large, so allocate only a single TagData
object in that case and make all tags point to it.
(If we end up storing some cache in the curve object later on,
this will also increase the effectiveness of that cache.)
This reduces reliance on the peek operation, which the generic stream
implementation does not support.
This also corrects the naming, since "tag" wasn't entirely correct for
some of the operations, where the tag takes up only part of a byte, with
the rest being reserved for data.
This used to be optional and was disabled in two cases:
- On a mouse move event during dragging; because double clicks are
only possible on mouse up events, this had no effect.
- On a mouse event for automatic cursor tracking; this has now gained
support for double click events.
Since it's always enabled now, we can remove the `bool` argument.
At the moment, there is no immediate advantage compared to just calling
the underlying functions directly, but having a common interface feels
more ergonomic (users don't have to care about how a type serializes)
and maybe we'll find a way to hide the actual implementation from direct
access some time in the future.
As a nearby comment says, "This is a terrible approximation".
This doesn't make things less terrible, but it does make things
more correct in the given framework of terribleness.
Fixes#17156.
Per CSS-SIZING-3, the min-content block size should be equivalent to the
max-content block size for some boxes.
Honoring this gives more correct results, and avoids unnecessary work in
many cases since the cached max-content size can be reused.