This view is really nice to check flags, but when clearing them we must
make sure that we only ever try to set 1 bit at a time, which makes
setting bits through the structured view a footgun, as that fetches,
ors in and then sets, potentially resetting other flags.
According to multiboot spec if flag for framebuffer isn't
set then corresponding fields are invalid. In reality they're set
to 0 but let's be defensive.
Loaders try to put modules as low as reasonable but on
EFI often "reasonable" is much higher than on BIOS. As
a result target can be easily higher than source.
Then we have 2 problems:
* memmove compares virtual address and since target
is mapped higher it ends up going backwards which
is wrong if target is physically below source
* order of copying of sections must be inverted if
target is below source
Prekernel code currently assumes that mapping until MAX_KERNEL_SIZE
is enough to make the modules accessible. GRUB tries to load as low
as possible but higher than 1 MiB. Hence this is usually true.
However on EFI some ranges may already be used by boot services and
GRUB tries to avoid them if possible. This pushes modules higher.
The simplest solution is to map entire 4 GiB space.
As an additional benefit it makes the framebuffer accessible that
can be used for the debugging.
About half of the Processor code is common across architectures, so
let's share it with a templated base class. Also, other code that can be
shared in some ways, like FPUState and TrapFrame functions, is adjusted
here. Functions which cannot be shared trivially (without internal
refactoring) are left alone for now.
SipHash is highly HashDoS-resistent, initialized with a random seed at
startup (i.e. non-deterministic) and usable for security-critical use
cases with large enough parameters. We just use it because it's
reasonably secure with parameters 1-3 while having excellent properties
and not being significantly slower than before.
This subtraction is necessary to ensure that the section has the correct
address. Also, without this change, the Kernel ELF binary would explode
in size. This was forgotten in a0dd6ec6b1.
This field is in a packed struct, which makes it possibly misaligned.
This knowledge is lost when invoking `dbgln` triggering an unaligned
access to it, aka UB. By explicitely copying it we avoid this issue.
Simplify core methods in the VirtIO bus handling code by ensuring proper
error propagation. This makes initialization of queues, handling changes
in device configuration, and other core patterns more readable as well.
It also allows us to remove the obnoxious pattern of checking for
boolean "success" and if we get false answer then returning an actual
errno code.
When a device is plugged into the machine (and hence, when
`Device::try_create()` is called), then we attempt to load a driver by
calling that driver's probe function.
At any one given time, there can be an abitrary number of USB drivers in
the system. The way driver mapping works (i.e, a device is inserted, and
a potentially matching driver is probed) requires us to have
instantiated driver objects _before_ a device is inserted. This leaves
us with a slight "chicken and egg" problem. We cannot call the probe
function before the driver is initialised, but we need to know _what_
driver to initialise.
This section is designed to store pointers to functions that are called
during the last stage of the early `_init` sequence in the Kernel. The
accompanying macro in `USBDriver` emits a symbol, based on the driver
name, into this table that is then automatically called.
This way, we enforce a "common" driver model; driver developers are not
only required to write their driver and inherit from `USB::Driver`, but
are also required to have a free floating init function that registers
their driver with the USB Core.
The VirtIO specification defines many types of devices with different
purposes, and it also defines 3 possible transport mediums where devices
could be connected to the host machine.
We only care about the PCIe transport, but this commit puts the actual
foundations for supporting the lean MMIO transport too in the future.
To ensure things are kept abstracted but still functional, the VirtIO
transport code is responsible for what is deemed as related to an actual
transport type - allocation of interrupt handlers and tinkering with low
level transport-related registers, etc.
We should consider whether the selected Thread is within the same jail
or not.
Therefore let's make it clear to callers with jail semantics if a called
method checks if the desired Thread object is within the same jail.
As for Thread::for_each_* methods, currently nothing in the kernel
codebase needs iteration with consideration for jails, so the old
Thread::for_each* were simply renamed to include "ignoring_jails" suffix
in their names.
Some syscalls could be simplified by using the non-static method
Process::get_thread_from_thread_list which should ensure that the
specified tid is of a Thread in the same Process of the current Thread.
The Kernel/API directory in general shouldn't include userspace code,
but structure definitions that both are shared between the Kernel and
userspace.
All users of the ioctl API obviously use LibC so LibC is the most common
and shared library for the affected programs.
The Kernel/API directory in general shouldn't include userspace code,
but structure definitions that both are shared between the Kernel and
userspace.
LibC is the most appropriate place for these methods as they're already
included in the sys/sysmacros.h file to create a set of convenient
macros for these methods.
