Most of the string.h and wchar.h functions are implemented quite naively
at the moment, and GCC's pattern recognition pass might realize what we
are trying to do, and transform them into libcalls. This is usually a
useful optimization, but not when we're implementing the functions
themselves :^)
Relevant discussion from the GCC Bugzilla:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102725
This prevents the infamous recursive `strlen`.
A more proper fix would be writing these functions in assembly. That
would likely give a small performance boost as well ;)
Instead of storing the current Processor into a core local register, we
currently just store it into a global, since we don't support SMP for
aarch64 anyway. This simplifies the initial implementation.
By putting the NOLOAD sections (.bss and .super_pages) at the end of the
ELF file, objcopy does not have to insert a lot of zeros to make sure
that the .ksyms section is at the right place in memory. Now the .ksyms
section comes before the two NOLOAD sections. This shrinks the
kernel8.img with 6MB, from 8.3M to 2.3M. :^)
The sections did end up in the ELF file, however they weren't
explicitely mentioned in the linker.ld script. In the future, we can add
the --orphan-handling=error flag to the linker options, which will
enforce that the sections used in the sources files also are mentioned
in the linker script.
This fixes a weird bug that when sometimes a user tried to switch to
console mode, the screen was frozen on graphics mode. After a hour of
debugging this, it became apparent that the problem was that we left the
y offset of the bochs graphics device in an invalid state, so it was not
zero because the WindowServer changed it, and the framebuffer console
code is not aware of horizontal and vertical offsets of the framebuffer
screen, leading to the problem that the framebuffer console updates the
first framebuffer (y offset = 0), but hardware was indicated to show the
second framebuffer (y offset = first framebuffer height).
Therefore, when doing a switch between these modes, always set the y
offset to be zero.
This exposes the child processes for a process as a directory
of symlinks to the respective /proc entries for each child.
This makes for an easier and possibly more efficient way
to find and count a process's children. Previously the only
method was to parse the entire /proc/all JSON file.
This in turn makes the built-in kernel console much more nicer to look
into, so let's remove the support for 8x8 bitmap and instead add 8x16
font bitmap.
The old methods are already can be considered deprecated, and now after
we removed framebuffer devices entirely, we can safely remove these
methods too, which simplfies the GenericGraphicsAdapter class a lot.
Instead of letting the user to determine whether framebuffer devices
will be created (which is useless because they are gone by now), let's
simplify the flow by allowing the user to choose between full, limited
or disabled functionality. The determination happens only once, so, if
the user decided to disable graphics support, the initialize method
exits immediately. If limited functionality is chosen, then a generic
DisplayConnector is initialized with the preset framebuffer resolution,
if present, and then the initialize method exits. As a default, the code
proceeds to initialize all drivers as usual.
This ioctl is more appropriate when the hardware supports flushing of
the entire framebuffer, so we use that instead of the previous default
FB_IOCTL_FLUSH_HEAD_BUFFERS ioctl.
We shouldn't expose the VirtIO GPU3DDevice constructor as public method,
so instead, let's use the usual pattern of a static construction method
that uses the constructor within the method.
Such mechanism will be used by the Intel Graphics driver, because we
lack support of changing the resolution on this driver currently, so,
when WindowServer will try to mode-set the display then it will fail,
and will use the safe mode-setting call instead to be able to show
something on screen.
The DisplayConnector class is meant to replace the FramebufferDevice
class. The advantage of this class over the FramebufferDevice class is:
1. It removes the mmap interface entirely. This interface is unsafe, as
multiple processes could try to use it, and when switching to and from
text console mode, there's no "good" way to revoke a memory mapping from
this interface, let alone when there are multiple processes that call
this interface. Therefore, in the DisplayConnector class there's no
implementation for this method at all.
2. The class uses a new real-world structure called ModeSetting, which
takes into account the fact that real hardware requires more than width,
height and pitch settings to mode-set the display resolution.
3. The class assumes all instances should supply some sort of EDID,
so it facilitates such mechanism to do so. Even if a given driver does
not know what is the actual EDID, it will ask to create default-generic
EDID blob.
3. This class shifts the responsibilies of switching between console
mode and graphical mode from a GraphicsAdapter to the DisplayConnector
class, so when doing the switch, the GraphicsManagement code actually
asks each DisplayConnector object to do the switch and doesn't rely on
the GraphicsAdapter objects at all.
Since kmalloc() now works, we can actually load the kernel symbol table!
This in turn allows us to call dump_backtrace(), and actually get a
useful backtrace in the aarch64 Kernel.
These functions are called by kmalloc, and since there is no support for
threading in the aarch64 build yet, we can simply remove the
VERIFY_NOT_REACHED().
The code in Spinlock.h has no architectural specific logic, thus can be
moved to the Arch directory. This contains no functional change.
Also add the Spinlock.cpp file for aarch64 which contains stubs for the
lock and unlock functions.
Previously the embedmap.sh script generated a warning, since there was
no section defined where the actual kernel.map could be stored. This is
necesarry for generating kernel backtraces.
This compiler builtin abstracts away the specifics of fetching the frame
pointer. This will allow the KSyms.cpp to be build for the aarch64
target. While we're here, lets also change the
PerformanceEventBuffer.cpp to not rely on x86_64 specifics.
Previously in the aarch64 Kernel, this would cause dbgln() to actually
print more characters of the next string in memory, because strings in
the Kernel are not zero terminated by default. Prevent this by using the
passed in length of the string.
When calling dbgln(), the formatting code in AK/Format.h calls
Processor::is_initialized() to determine whether to add some text about
the current processor to the debug output. Instead of crashing, we just
return false, such that we can use dbgln() etc in the aarch64 Kernel.
This allows us to use the AK formatting functions in the aarch64 Kernel.
Also add FIXME to make sure that this file will be removed when the
proper abstractions are in place in the normal Kernel/kprintf.cpp.
The compiler figured out that the MemoryManager is not initialised, and
thus MemoryManager::the() cannot return a valid reference. Once the
necesarry code is in place, this compiler flag can be removed.
Coverage tools like LLVM's source-based coverage or GNU's --coverage
need to be able to write out coverage files from any binary, regardless
of its security posture. Not ignoring these pledges and veils means we
can't get our coverage data out without playing some serious tricks.
However this is pretty terrible for normal exeuction, so only skip these
checks when we explicitly configured userspace for coverage.
It doesn't make sense after introduction of routing table which allows
having multiple gateways for every interface, and isn't used by any of
the userspace programs now.
This will allow using the console tty and WindowServer regardless of
your kernel command line. Also this fixes a bug where, when booting in
text mode, the console was in graphical mode, and would not accept
input.
That code used the old AK::Result container, which leads to overly
complicated initialization flow when trying to figure out the correct
partition table type. Instead, when using the ErrorOr container the code
is much simpler and more understandable.
Previously the system had no concept of assigning different routes for
different destination addresses as the default gateway IP address was
directly assigned to a network adapter. This default gateway was
statically assigned and any update would remove the previously existing
route.
This patch is a beginning step towards implementing #180. It implements
a simple global routing table that is referenced during the routing
process. With this implementation it is now possible for a user or
service (i.e. DHCP) to dynamically add routes to the table.
The routing table will select the most specific route when possible. It
will select any direct match between the destination and routing entry
addresses. If the destination address overlaps between multiple entries,
the Kernel will use the longest prefix match, or the longest number of
matching bits between the destination address and the routing address.
In the event that there is no entries found for a specific destination
address, this implementation supports entries for a default route to be
set for any specified interface.
This is a small first step towards enhancing the system's routing
capabilities. Future enhancements would include referencing a
configuration file at boot to load pre-defined static routes.
I've noticed that the KVM hypervisor vendor ID string contained null
terminators in the serialized JSON string in /proc/cpuinfo - let's avoid
that, and err on the side of caution and strip them from all strings
built from CPUID register values. They may not be fixed width after all.
This creates all interfaces when the device is enumerated, with a link
to the configuration that it is a part of. As such, a new class,
`USBInterface` has been introduced to express this state.
Some other parts of the USB stack may require us to perform a control
transfer. Instead of abusing `friend` to expose the default pipe, let's
just expose it via a function.
This also introduces a new class, `USBConfiguration` that stores a
configuration. The device, when instructed, sets this configuration and
holds a pointer to it so we have a record of what configuration is
currently active.
AnonymousFile always allocates in multiples of a page size when created
with anon_create. This is especially an issue if we use AnonymousFile
shared memory to store a shared data structure that isn't exactly a
multiple of a page in size. Therefore, we can just allow mmaps of
AnonymousFile to map only an initial part of the shared memory.
This makes SharedSingleProducerCircularQueue work when it's introduced
later.
In most cases it's safe to abort the requested operation and go forward,
however, in some places it's not clear yet how to handle these failures,
therefore, we use the MUST() wrapper to force a kernel panic for now.
On the QEMU microvm machine type, it became apparent that the BIOS was
not setting the i8042 controller to function as expected. To ensure that
the controller is always outputting correct scan codes, set it to scan
code 2 and enable first port translation to ensure all scan codes are
translated to scan code set 1. This is the expected behavior when using
SeaBIOS, but on qboot (the BIOS for the QEMU microvm machine type), the
firmware doesn't take care of this so we need to do this ourselves.
This keeps us from accidentally overwriting an already set region name,
for example when we are mapping a file (as, in this case, the file name
is already stored in the region).
