To ensure actual PS2 code is not tied to the i8042 code, we make them
separated in the following ways:
- PS2KeyboardDevice and PS2MouseDevice classes are no longer inheriting
from the IRQHandler class. Instead we have specific IRQHandler derived
class for the i8042 controller implementation, which is used to ensure
that we don't end up mixing PS2 code with low-level interrupt handling
functionality. In the future this means that we could add a driver for
other PS2 controllers that might have only one interrupt handler but
multiple PS2 devices are attached, therefore, making it easier to put
the right propagation flow from the controller driver all the way to
the HID core code.
- A simple abstraction layer is added between the PS2 command set which
devices could use and the actual implementation low-level commands.
This means that the code in PS2MouseDevice and PS2KeyboardDevice
classes is no longer tied to i8042 implementation-specific commands,
so now these objects could send PS2 commands to their PS2 controller
and get a PS2Response which abstracts the given response too.
The HIDController class is removed and instead adding SerialIOController
class. The HIDController class was a mistake - there's no such thing in
real hardware as host controller only for human interface devices
(VirtIO PCI input controller being the exception here, but it could be
technically treated as serial IO controller too).
Instead, we simply add a new abstraction layer - the SerialIO "bus",
which will hold all the code that is related to serial communications
with other devices. A PS2 controller is simply a serial IO controller,
and the Intel 8042 Controller is simply a specific implementation of a
PS2 controller.
Ideally, we would want the audio controller to run a channel at a
device's initial sample rate instead of hardcoding 44.1 KHz. However,
most audio is provided at 44.1 KHz and as long as `Audio::Resampler`
introduces significant audio artifacts, let's set a sensible sample
rate that offers a better experience for most users.
This can be removed after someone implements a higher quality
`Audio::Resampler`.
All code that is related to PC BIOS should not be in the Kernel/Firmware
directory as this directory is for abstracted and platform-agnostic code
like ACPI (and device tree parsing in the future).
This fixes a problem with the aarch64 architecure, as these machines
don't have any PC-BIOS in them so actually trying to access these memory
locations (EBDA, BIOS ROM) does not make any sense, as they're specific
to x86 machines only.
This code is very x86-specific, because Intel introduced the actual
MultiProcessor specification back in 1993, qouted here as a proof:
"The MP specification covers PC/AT-compatible MP platform designs based
on Intel processor architectures and Advanced Programmable Interrupt
Controller (APIC) architectures"
Most of the ACPI static parsing methods (methods that can be called
without initializing a full AML parser) are not tied to any specific
platform or CPU architecture.
The only method that is platform-specific is the one that finds the RSDP
structure. Thus, each CPU architecture/platform needs to implement it.
This means that now aarch64 can implement its own method to find the
ACPI RSDP structure, which would be hooked into the rest of the ACPI
code elegantly, but for now I just added a FIXME and that method returns
empty value of Optional<PhysicalAddress>.
Previously, reads would only be successful for offset 0. For this
reason, the maximum size that could be correctly read from the PCI
expansion ROM SysFS node was limited to the block size, and
subsequent blocks would fail. This commit fixes the computation of
the number of bytes to read.
During receive_tcp_packet(), we now set m_send_window_size for the
socket if it is different from the default.
This removes one FIXME from TCPSocket.h.
These 4 fields were made `Atomic` in
c3f668a758, at which time these were still
accessed unserialized and TOCTOU bugs could happen. Later, in
8ed06ad814, we serialized access to these
fields in a number of helper methods, removing the need for `Atomic`.
Instead of having a single available memory range that encompasses the
whole 0x00000000-0x3EFFFFFF range of physical memory, create a separate
reserved entry for the RAM range used by the VideoCore. This fixes a
crash that happens when we try to allocate physical pages in the GPU's
reserved range.
This will eventually be replaced with parsing the data from the device
tree, but for now, this should solve some of the recurring CI failures.
Like the HID, Audio and Storage subsystem, the Graphics subsystem (which
handles GPUs technically) exposes unix device files (typically in /dev).
To ensure consistency across the repository, move all related files to a
new directory under Kernel/Devices called "GPU".
Also remove the redundant "GPU" word from the VirtIO driver directory,
and the word "Graphics" from GraphicsManagement.{h,cpp} filenames.
The implemented cloning mechanism should be sound:
- If a PartitionTable is passed a File with
ShouldCloseFileDescriptor::Yes, then it will keep it alive until the
PartitionTable is destroyed.
- If a PartitionTable is passed a File with
ShouldCloseFileDescriptor::No, then the caller has to ensure that the
file descriptor remains alive.
If the caller is EBRPartitionTable, the same consideration holds.
If the caller is PartitionEditor::PartitionModel, this is satisfied by
keeping an OwnPtr<Core::File> around which is the originally opened
file.
Therefore, we never leak any fds, and never access a Core::File or fd
after destroying it.
This has KString, KBuffer, DoubleBuffer, KBufferBuilder, IOWindow,
UserOrKernelBuffer and ScopedCritical classes being moved to the
Kernel/Library subdirectory.
Also, move the panic and assertions handling code to that directory.
When deleting a directory, the rmdir syscall should fail if the path was
unveiled without the 'c' permission. This matches the same behavior that
OpenBSD enforces when doing this kind of operation.
When deleting a file, the unlink syscall should fail if the path was
unveiled without the 'w' permission, to ensure that userspace is aware
of the possibility of removing a file only when the path was unveiled as
writable.
When using the userdel utility, we now unveil that directory path with
the unveil 'c' permission so removal of an account home directory is
done properly.
The Storage subsystem, like the Audio and HID subsystems, exposes Unix
device files (for example, in the /dev directory). To ensure consistency
across the repository, we should make the Storage subsystem to reside in
the Kernel/Devices directory like the two other mentioned subsystems.
This is enforced by the hardware and an exception is generated when the
stack pointer is not properly aligned. This brings us closer to booting
the aarch64 Kernel on baremetal.
This is the only kernel issue blocking us from running the test suite.
Having userspace backtraces printed to the debug console during crashes
isn't vital to the system's function, so let's just return an empty
trace and print a FIXME instead of crashing.
After examination of all overriden Inode::traverse_as_directory methods
it seems like proper locking is already existing everywhere, so there's
no need to take the big process lock anymore, as there's no access to
shared process structures anyway.
The contents of the directory inode could change if we are not taking so
we must take the m_inode_lock to prevent corruption when reading the
directory contents.
