This is by default left empty, so people won't run the kernel in a mode
which they didn't want to. The embedded string will override the
supplied commandline from the bootloader, which is good for debugging
sessions.
This change seemed important for me, because I debug the kernel on bare
metal with iPXE, and every change to the commandline meant that I needed
rewrite a new iPXE USB image with a modified iPXE script.
First scan PCI bus 0. Find any device on that bus, and if it's a
PCI-to-PCI bridge, recursively scan it too.
Then try to handle Multiple PCI host bridges on slot 0, device 0.
If we happen to miss some PCI buses because they are not reachable
through recursive PCI-to-PCI bridges scanning starting from bus 0, we
might find them in this scanning.
This reverts commit e95eb7a51d.
This is causing some sort of list corruption, as evident by #7313
I haven't been able to figure it out yet, so lets revert this change
until I can figure out what's going on.
When mmaping a Framebuffer from userspace, we need to check whether the
framebuffer device is actually enabled (e.g. graphical mode is being
used) or a textual VirtualConsole is active.
Considering the above state, we mmap the right VMObject to ensure we
don't have graphical artifacts if we change the resolution from
DisplaySettings, changed to textual mode and after the resolution change
was reverted, we will see the Desktop reappearing even though we are
still in textual mode.
If we tried to change the resolution before of this patch, we triggered
a kernel crash due to mmaping the framebuffer device again.
Therefore, on mmaping of the framebuffer device, we create an entire new
set of VMObjects and Regions for the new settings.
Then, when we change the resolution, the framebuffersconsole needs to be
updated with the new resolution and also to be refreshed with the new
settings. To ensure we handle both shrinking of the resolution and
growth of it, we only copy the right amount of available data from the
cells Region.
Instead of processing the input after receiving an IRQ, we shift the
responsibility to the io work queue to handle this for us, so if a page
fault occurs when trying to switch the VirtualConsole, the kernel can
handle that.
I introduced this bug in e95eb7a51, where it's possible that the
ProcessGroup is created, but we never add it to the list. Make sure we
check that we are in the list before removal. This only broke booting in
self-test mode oddly enough.
Reported-By: Andrew Kaster <andrewdkaster@gmail.com>
Avoid allocating while holding the g_process_groups_lock spinlock, it's
a pattern that has a negative effect on performance and scalability,
especially given that it is a global lock, reachable by all processes.
Currently in SMP mode we hard code support for up to only 8 processors.
There is no reason for this to be a dynamic allocation that needs to be
guarded by a spinlock. Instead use a Array<T* with inline storage of 8,
allowing each processor to initialize it self in place, avoiding all
the need for locks.
Spinlocks guard short regions, with hopefully no other locks being taken
in the process. Violating constraints usually had detrimental effects on
platform stability as well as performance and scalability. Allocating
memory takes it own locks, and can in some cases even allocate new
regions, and thus violates these tenants.
Move the AnonymousVMObject creation outside of the spinlock as
creation does not modify any shared state.
Hook the kernel page fault handler and capture page fault events when
the fault has a current thread attached in TLS. We capture the eip and
ebp so we can unwind the stack and locate which pieces of code are
generating the most page faults.
Co-authored-by: Gunnar Beutner <gbeutner@serenityos.org>
Problem:
- `static` variables consume memory and sometimes are less
optimizable.
- `static const` variables can be `constexpr`, usually.
- `static` function-local variables require an initialization check
every time the function is run.
Solution:
- If a global `static` variable is only used in a single function then
move it into the function and make it non-`static` and `constexpr`.
- Make all global `static` variables `constexpr` instead of `const`.
- Change function-local `static const[expr]` variables to be just
`constexpr`.
The WorkQueue class previously had its own inline storage functionality
for function pointers. With the recent changes to the Function class
this is no longer necessary.
This modifies the error checks in VFS::open after the call to
resolve_path to ignore a null parent custody if there is no error, as
this is expected when the path to resolve points to "/". Rather, a null
parent custody only constitutes an error if it is accompanied by ENOENT.
This behavior is documented in the VFS::resolve_path_without_veil
method.
To accompany this change, the order of the error checks have been
changed to more naturally fit the new logic.
Fixes a bug where TTY::write will attempt to write into the underlying
device but will not acknowledge the result of that write, instead
assuming that the write fully completed.
There is a slight race condition in our implementation of write().
We call File::can_write() before attempting to write to it (blocking if
it returns false). If it returns true, we assume that we can write to
the file, and our code assumes that File::write() cannot possibly fail
by being blocked. There is, however, the rare case where another process
writes to the file and prevents further writes in between the call to
Files::can_write() and File::write() in the first process. This would
result in the first process calling File::write() when it cannot be
written to.
We fix this by adding a mechanism for File::can_write() to signal that
it was blocked, making it the responsibilty of File::write() to check
whether it can write and then finally making sys$write() check if the
write failed due to it being blocked.
This commit adds support for initializing multiple serial ports per
PCI board, as well as initializing multiple different pci serial boards
Currently we just choose the first PCI serial port seen as the debug
port, but this should probably be made configurable some how in the
future.
This avoids two allocations when receiving network packets. One for
inserting a PacketWithTimestamp into m_packet_queue and another one
when inserting buffers into the list of unused packet buffers.
With this fixed the only allocations in NetworkTask happen when
initially allocating the PacketWithTimestamp structs and when switching
contexts.
Problem:
- `BitmapView` permits changing the underlying `Bitmap`. This violates
the idea of a "view" since views are simply overlays which can
themselves change but do not change the underlying data.
Solution:
- Migrate all non-`const` member functions to Bitmap.
When profiling a single process we didn't disable the profile timer.
enable_profile_timer()/disable_profiler_timer() support nested calls
so no special care has to be taken here to only disable the timer when
nobody else is using it.
These functions should return success when being called when profiling
has been requested from multiple callers because enabling/disabling the
timer is a no-op in that case and thus didn't fail.
This had very bad interactions with ccache, often leading to rebuilds
with 100% cache misses, etc. Ali says it wasn't that big of a speedup
in the end anyway, so let's not bother with it.
We can always bring it back in the future if it seems like a good idea.
This fixes non-periodic comparators not receiving interrupts, as we
were never setting the InterruptEnable bit in their capabilities
register (unlike periodic comparators's bit, which was set as a side
effect of calling set_periodic on them to set their periodic bit).
This should help getting profiling work on bare-metal SerenityOS
installations, which were not guaranteed to have 2 periodic
comparators available.
