Here comes the foundation for a neat remote debugging tool.
Right now, it connects to a remote process's CEventLoop RPC socket and
retreives the remote object graph JSON dump. The remote object graph
is then reconstructed and exposed through a GModel subclass, which is
then displayed in a GTreeView.
It's pretty cool, I think. :^)
This implements a very basic VGA device using the information provided
to us by the bootloader in the multiboot header. This allows Serenity to
boot to the desktop on basically any halfway modern system.
The complication is around /proc/sys/ variables, which were attached
to inodes. Now they're their own thing, and the corresponding inodes
are lazily created (as all other ProcFS inodes are) and simply refer
to them by index.
This is kind of a mess, but because IPC client code depending on the
IPC protocol definition artifacts in the server code, we have to build
the IPC servers first. And their dependencies before that, etc.
One more drop in the "maybe we should switch to CMake" bucket..
makeall.sh used to build the AK tests and leave some binary objects laying
around that would get in the way of further incremental builds. There also
wasn't a lot of structure to the order things were built in. This patch
improves both of those things.
It is now possible to unmount file systems from the VFS via `umount`.
It works via looking up the `fsid` of the filesystem from the `Inode`'s
metatdata so I'm not sure how fragile it is. It seems to work for now
though as something to get us going.
We were forced to do this because the page fault code would fall apart
when trying to generate a backtrace for a non-current thread.
This issue has been fixed for a while now, so let's go back to lazily
loading executable pages which should make everything a little better.
This patch adds the mprotect() syscall to allow changing the protection
flags for memory regions. We don't do any region splitting/merging yet,
so this only works on whole mmap() regions.
Added a "crash -r" flag to verify that we crash when you attempt to
write to read-only memory. :^)
Now that we're bringing back the in-kernel virtual console, we should
move towards having a single implementation of terminal emulation.
This patch rips out the emulation code from the Terminal application
and turns it into the beginnings of LibVT.
The basic design idea is that users of VT::Terminal will implement and
provide a VT::TerminalClient subclass to handle presentation-specific
things. We'll need to iterate on this, but it's a start. :^)
TTY::emit is called from an IRQ handler, and is used to push input data
into a buffer for later retrieval. Previously this was using DoubleBuffer,
but that class wants to take a lock. Our lock code wants to make sure
interrupts are enabled, but they're disabled while an IRQ handler is
running. This made the kernel sad, but this CircularQueue cheers it up by
avoiding the lock requirement completely.
This should probably call out to a login program at some point. Right now
it just puts a root terminal on tty{1,2,3}.
Remember not to leave your Serenity workstation unattended!
Our logic for using the ATA_CMD_CACHE_FLUSH functionality was a bit wrong,
and now it's better.
The ATA spec says these two things:
> The device shall enter the interrupt pending state when:
> 1) any command except a PIO data-in command reaches command completion
> successfully;
> ...
> The device shall exit the interrupt pending state when:
> 1) the device is selected, BSY is cleared to zero, and the Status
> register is read;
This means that our sequence of actions was probably never going to work.
We were waiting in a loop checking the status register until it left the
busy state, _then_ waiting for an interrupt. Unfortunately by checking the
status register, we were _clearing_ the interrupt we were about to wait
for.
Now we just wait for the interrupt - we don't poll the status register at
all. This also means that once we get our `wait_for_irq` method sorted out
we'll spend a bunch less CPU time waiting for things to complete.
* The origin PID is the PID of the process that created this socket,
either explicitly by calling socket(), or implicitly by accepting
a TCP connection. Note that accepting a local socket connection
does not create a new socket, it reuses the one connect() was
called on, so for accepted local sockets the origin PID points
to the connecting process.
* The acceptor PID is the PID of the process that accept()ed this
socket. For accepted TCP sockets, this is the same as origin PID.
