For all intents and purposes, the cmd (super) key on macOS should be
treated as the ctrl key.
(cherry picked from commit 71b25e3e5a70937f1e2031b94541c04a68d28efa;
amended to fix minor conflict)
This rule hasn't actually generated a `Prekernel` file since d068af89,
so this wasn't doing anything other than causing this target to be
re-ran all the time.
This removes the need to have the install_libc_headers target, since
LibC's headers will now get installed before anything gets built. By
extension, this also prevents said target from re-running on every
build.
This replaces all usages of Cacheable::Yes with MemoryType::Normal and
Cacheable::No with either MemoryType::NonCacheable or MemoryType::IO,
depending on the context.
The Page{Directory,Table}::set_cache_disabled function therefore also
has been replaced with a more appropriate set_memory_type_function.
Adding a memory_type "getter" would not be as easy, as some
architectures may not support all memory types, so getting the memory
type again may be a lossy conversion. The is_cache_disabled function
was never used, so just simply remove it altogether.
There is no difference between MemoryType::NonCacheable and
MemoryType::IO on x86 for now.
Other architectures currently don't respect the MemoryType at all.
For some context, write_bytes_locked used to simply bail out before
writing any data if there weren't enough blocks to cover the entire size
of an inode before 1bf7f99a.
We're not actually restoring that behavior here, since computing the
amount of blocks to be allocated would get exceedingly complex,
considering that there could always be holes in between already
allocated blocks.
Instead, this simply makes allocate_blocks() bail out properly if there
aren't any free blocks left.
Fixes#24980
Devicetree drivers are created by using the `DEVICETREE_DRIVER` macro.
That macro creates a new class deriving from `DeviceTree::Driver` and
inserts it into the driver init section.
The driver code then has to implement the `probe` member function, which
will be called if `DeviceTree::Management` finds a node with a
compatible property entry that was in the array passed as the second
argument to the `DEVICETREE_DRIVER` macro.
The `probe` function then will check if it supports the given node and
if so, registers a `DeviceTree::DeviceRecipe` at the appropriate
subsystem, which will then create a device from that recipe once it is
initialized.
The driver can store the necessary info it got from the devicetree,
such as the physical address and interrupt numbers, in the capture
list of the callback lambda stored in `DeviceRecipe::create_device`.
The `DeviceTree::DeviceRecipe`s are necessary, as the `probe` functions
might not be able to create an instance of the actual device class,
since doing so can depend on some subsystems being initialized first.
