LookupServer can now take two types of requests:
* L: Lookup
* R: Reverse lookup
The /bin/host program now does a reverse lookup if the input string is a
valid IPv4 address. :^)
If it returns 0 that just means we hit the timeout. I suppose we could skip
the timer checks if there are a non-zero number of fds marked as well, but
I'm not sure that's a great idea since it will add some latency.
This was unnecessarily confusing. When we build up a chain of commands
connected by pipes, we now store the file descriptors of each end of
these pipes as rewirings in a vector. The rewirings are then put into
effect by calls to dup2().
This removes grub and all the loopback device business from the default
build process. Running grub takes about a second, and it turns out it's
inconsistently packaged in different distributions, which has led to
at least one confusing issue so far (grub-install vs grub2-install).
Removing it from the basic path will make it easier for people to try
Serenity out.
There are now two scripts that can be used to build a disk image:
1. `build-image-grub.sh` - this will build an image suitable for writing
to the IDE hard drive of a physical machine, complete with a partition
table and bootloader. This can be run in qemu with the `qgrub` target
for the `run` script.
2. `build-image-qemu.sh` - this is a simpler script which creates a bare
filesystem image rather than a full MBR disk.
Both of these call out to `build-root-filesystem.sh` to do most of the
work setting up... the root filesystem.
For completeness' sake, I've retained the `sync.sh` script as a simple
forwarding to `build-image-qemu.sh`.
This relies on the functionality from #194 and #195. #195 allows us to
use `/dev/hda` as the root device when nothing else is specified, and #194
works around a strange feature of qemu that appends a space to the kernel
command line.
This introduces very basic handling of the kernel command line to choose
the root filesystem at startup. Given that we currently only support a
single IDE hard drive, it's hard-coded to look for `/dev/hda` at the start
of the argument.
If there is nothing following this, or if the parameter is empty,
init_stage2 will try to load the ext2 filesystem from the start of the
device. This is intended to be the default behaviour when running
development builds, as it is faster to set up and doesn't require a
working grub installation.
If `/dev/hda` is followed by a number, init_stage2 will try to read an MBR
partition header from the drive, then load the requested partition. It
will reject non-numeric trailing data, and anything outside of partitions
one through four.
When there's a trailing space in the cmdline from the boot loader, this
results in an empty string being emitted from `String::split` after
splitting apart the argument list. This empty string resulted in a
zero-length Vector from the subsequent call to split the key=value pairs,
which was unexpected. This ultimately caused a crash when we tried to
access `[0]` of that zero-length vector.
We now detect and handle an empty string coming from `String::split`
correctly.
This is a small change to the existing split() functionality to support
the case of splitting a string and stopping at a certain number of
tokens. This is useful for parsing e.g. key/value pairs, where the value
may contain the delimiter you're splitting on.
We should work towards a pattern where we take StringView as function
arguments, and store String as member, to push the String construction
to the last possible moment.
This implements a passthrough disk driver that translates the read/write
block addresses by a fixed offset. This could form the basis of MBR
partition support if we were to parse the MBR table at boot and create that
OffsetDiskDevice dynamically, rather than seeking to a fixed offset.
This also introduces a dependency in the form of grub. You'll need to have
32-bit grub binaries installed to build the project now.
As a bonus, divorcing Serenity from qemu's kernel loading means we can now
*technically* boot on real hardware. It just... doesn't get very far yet.
If you write the `_disk_image` file to an IDE hard drive and boot it in a
machine that supports all the basic PC hardware, it *will* start loading
the kernel.
