This allows us to remove the PCI::get_interrupt_line API function. As a
result, this removes a bunch of not so great patterns that we used to
cache PCI interrupt line in many IRQHandler derived classes instead of
just using interrupt_number method of IRQHandler class.
Instead of blindly forcing BGR format on the bochs-display device, let's
ensure we do that only on QEMU bochs-display and not on VirtualBox
graphics adapter too.
- .text now starts at 0x80000, where an actual (non-qemu) RPi expects
- use magic section name ".text.first" to make sure the linker script
puts the kernel entry point at the start of the .text section
- remove a few things from the x86 linker script that aren't needed
for aarch64 (yet?)
This moves Kernel/Prekernel/linker.ld unchanged to
Kernel/Prekernel/Arch/aarch64 and Kernel/Prekernel/Arch/x86.
The aarch64 will change in a future commit.
No behavior change.
Looking at how these two constants are commonly used in other systems,
we should be able to mimic their behavior using our PT_PEEK constant.
For example, see:
https://man.netbsd.org/NetBSD-6.0.1/i386/ptrace.2
This ensures we dont try to hold the PCI Access mutex under IRQ when
printing VirtIO debug logs (which is not allowed and results in an
assertion). This is also relatively free, as it requires no allocations
(we're just storing a pointer to the rodata section).
As a demo, query the firmware version. `Meta/serenity.sh gdb aarch64`
can be used to observe that qemu puts 0x548E1 in x0 in response
to this mailbox message.
This fixes a Kernel Panic where the lazy allocation triggers inside an
ISR and grabs a mutex, which isn't allowed when interrupts are
disabled. This also fixes a bug where the mapping for VirtIO device
BARs is never allocated. #9876
Currently, writing anything to `/dev/mouse0` or `/dev/keyboard0` causes
the Kernel to panic. The reason for this is that
`[Mouse,Keyboard]Device::write` always returns 0, which is explicitly
prohibited by `VERIFY` macro in `Process::sys$write`. The fix seems
trivial; `write` should return EINVAL instead (as is the case with, for
example, `KCOVDevice`).
When testing the RTL8168 driver, it seems we can't allocate super pages
anymore. Either we expand the super pages range, or find a solution to
dynamically expand the range (or let drivers utilize other ranges).
This singleton simplifies many aspects that we struggled with before:
1. There's no need to make derived classes of Device expose the
constructor as public anymore. The singleton is a friend of them, so he
can call the constructor. This solves the issue with try_create_device
helper neatly, hopefully for good.
2. Getting a reference of the NullDevice is now being done from this
singleton, which means that NullDevice no longer needs to use its own
singleton, and we can apply the try_create_device helper on it too :)
3. We can now defer registration completely after the Device constructor
which means the Device constructor is merely assigning the major and
minor numbers of the Device, and the try_create_device helper ensures it
calls the after_inserting method immediately after construction. This
creates a great opportunity to make registration more OOM-safe.
Previously, attempting to call sys$waitid on non-child processes
returned ECHILD.
That prevented debugging non-child processes by attaching to them during
runtime (as opposed to forking and debugging the child, which is what
was previously supported).
We now allow calling sys$waitid on a any process that is being traced
by us, even if it's not our child.
Because we were holding a strong ref to the OpenFileDescription in
LocalSocket and a strong ref to the LocalSocket in Inode, we were
creating a reference cycle in the event of the socket being cleaned up
after the file description did (i.e. unlinking the file before closing
the socket), because the file description never got destructed.
