httpserver: Fix /os/dmesg output format

Output should be json formatted, according to the schema.

Signed-off-by: Or Cohen <orc@fewbytes.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
x64: Document how boot16.S get loader size

Signed-off-by: Elazar Leibovich <elazarl@gmail.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
console: Fix bare linefeeds on early output on Xen

This patch fixes #371, which reported OSv's early output (first few lines
of verbose messages) is "scrambled" in the sense that each line starts
below the place where the previous line ended, instead of the beginning
of the line where it should.

Even modern terminals follow typewriters (does anyone even remember those?)
in that they have two separate concepts: A "line feed", which moves one line
down (in the same column), and a "carriage return", which returns to the
first column (on the same line). In ASCII, the line feed is '\n' (\012)
and the carriage return is '\r' (\015). You actually need to output *both*
of them to do what people normally expect from a "new line", i.e., go
to the first column of the next line.

Since UNIX adopted the convention that it only takes a "\n" to mark a new
line, the terminal driver needs to convert "\n" to a "\r\n" sequence.
This conversion can be turned on or off using the ONLCR flag in an ioctl
to the terminal driver (see termios(3)). Normally, in "cooked mode", this
conversion is enabled. In our implementation, this conversion is done
by LineDiscipline::write(), and is working fine, which is why we don't
see the linefeed problem after the early output.

But for the early console output, we had separate code for outputting it,
and in that case, forgot to do the \n->\r\n conversion. So this patch
adds it.

Why did this problem only effect Xen?

Xen doesn't use qemu. It turns out that qemu has a long-known bug which
hides this OSv bug :-) Qemu enables the ONLCR bit on the host's tty
(don't be confused - this is in the host and not the ONLCR code in OSv
described earlier). In other words, qemu translates every \n it gets over
the serial port to \r\n when printing it to the screen, so even if our
code just outputted \n, it would show it correctly. That may sound like
"not a bug, it's a feature", but it really *is* a bug in qemu - it also
means that the guest has no way to output a bare linefeed to go one
line down. This is why in apps/rogue I had to patch the terminal
definition to use the cursor-down escape sequence instead of the linefeed.

Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>