Currently, the kernel can write to 0xb80000 because this is part of the
initial identify mapping set up by the rt0 code. When we establish new
mappings for the kernel using its real VMA address then writes to the
framebuffer will cause a page fault unless we explicitly map it.
This commit removes the HWProbes() function from the console and tty
packages and replaces it with a global ProbeFuncs slice which is fetched
by the hal package when the hardware autodetection code runs.
Each driver should provide an init() function that appends a probe function
to the global ProbeFuncs slice.
This approach allows us to support conditional compilation of drivers in
the future (e.g. using build tags)
The implementation of Printf has been moved from the early package to
the kfmt package. The dependency to ActiveTerminal has been removed and
the code now uses an io.Writer for its output. As Go interfaces cannot
be used before bootstrapping the Go runtime, the code uses a ring-buffer
fallback for storing any kernel output emitted before that point.
The ring-buffer implements both io.Reader and io.Writer and uses a fixed
size of 2048 bytes (set by the ringBufferSize constant). This provides
enough space to hold a standard 80x25 screen's output.
This commit refactors the old VT implementation to work with the revised
TTY interface and adds support for:
- scrollback
- terminal state handling
When a terminal becomes activated, it overwrites the attached console
contents with the contents of its viewport.
Things like error messages (e.g in the io pkg) are actually allocated
when init() is executed. Unless we trigger a call to init(), values like
this will be nil causing various problems when we try to use functions
from the stdlib.
According to the ELF runtime handling of TLS document, the x86-64 arch
uses the same TLS handling variant (GNU) as the IA-32 ABI with the
exception that pointers are 8-byte wide and that the gs register is
swapped with fs. fs:0x0 points to the TCB; TLS variables are located
before it and are accessed using negative offsets from the TCB pointer.
In the Go case the G struct is accessed at fs:-0x8.
For more detauls see: https://www.akkadia.org/drepper/tls.pdf
By setting up pwd as a Go workspace, we can trim import paths from
something like "github.com/achilleasa/gopher-os/kernel" to just
"kernel".
These changes make forking easier and also allows us to move the code to
a different git hosting provider without having to rewrite the imports.
The rt0 code implements a dedicated function for initializing the Go runtime
structures. Instead of reserving space for a dummy g struct, the rt0
code now uses the g0 and m0 symbols defined by the runtime package. In
addition to setting up g0, the rt0 also sets up the m0 struct and links
it to g0.
Setting up m0 is a requirement for properly bootstapping the
malloc-related code in the following commits
The Makefile contains rules for invoking the offsets tool to generate
the offset definitions for members of the g, m and stack structs. The
definitions are stored in BUILD_DIR and BUILD_DIR is passed as an
include target to nasm.
The offsets tool is essentially a wrapper around "go build -a -n". It
creates a temporary folder with a dummy go file and runs the above
command using the target OS/ARCH for the kernel and captures the output.
The use of the "-a" flag forces go build to generate a build script for
rebuilding all packages including the runtime ones. As a by-product of
building the runtime package, the compiler emits the "go_asm.h" file
that contains (among other things) the offsets for each element of the
g, m and stack structures (see src/runtime/runtime2.go).
These offsets are used in Go assembly files instead of hardcoded
offsets. For example the following snippet accesses the pointer to m in
the g struct address stored at register CX:
MOVQ TLS, CX
MOVQ g_m(CX), BX
The offsets tool modifies the captured output from the go build command
so it only includes the steps up to building the runtime package,
executes the build script and post-processes the generated go_asm.h file
to retain the entries relevant to g, m and stack and then formats them
so they are compatible with nasm definitions (name equ value).
Depending on the value of the "-out" option, the tool outputs the
generated definitions either to STDOUT (default value for -out) or to a
file.
The generated DWARF information contains absolute file paths for the
source files which causes issues when debugging on OSX as GDB cannot
lookup the source files.
