You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 9976346
Browse filesBrowse the repository at this point in the historyBrowse files
openkal-linux 0.5.0: implement on the kernel, so that a C library can sit above (#1)
* openkal-linux 0.5.0: implement on the kernel, so that a C library can sit above
Version 0.4 was written upon the C library of the host. That is a correct
implementation of openkal and it fails for the program openkal exists to
support. A C library ported onto openkal defines write, malloc and open; so
does the host's; one program cannot reach both definitions, so this
implementation's calls resolved to the ported library, which called openkal,
which called this implementation again. Neither side reads as though anything
is wrong.
Every interface is now implemented on the kernel's own system-call interface
for x86_64 and aarch64, and the objects reference no C library symbol - which
CI asserts against the objects rather than the source, and which a probe
confirms the check can detect the absence of.
The kernel's structure layouts are declared here rather than taken from a
header, because the same-named structure differs between C libraries and an
implementation compiled against one and linked with another would read the
wrong fields.
A "freestanding" feature supplies what a C library's first object ordinarily
supplies, for a program that is a C library: the program entry, a thread-local
storage block per execution context built from the program's own PT_TLS
segment, and execution contexts created with clone. Without it, contexts come
from the C library the program is linked against, which is the ordinary
configuration and remains the default.
kal_fs_preopen(0) now reports the working directory's absolute path rather than
".", because a C library above openkal must report a working directory and
could not have done so.
The four operations and one property openkal 0.5 adds are implemented, and a
sixth conformance suite observes each of them by its effect.
* openkal-linux: state the arrangement in openkal's terms
The feature is renamed from 'freestanding' to 'standalone' and restated: what
it selects is whether this implementation is the whole of the program's
environment, which is a property of the program. The finding that produced it
is unchanged and is now stated generally --- an implementation must not depend
upon a runtime the program may itself supply --- with a C library as the
instance rather than as the subject.
* ci: two compiler families, the shared suite, and the feature under its own name
The workflow named a feature this package renamed --- `freestanding' became
`standalone', because the arrangement is a statement about the program and not
about how much of a C library is present --- so the two steps that assert this
version's central property were building the default configuration and asserting
nothing about the one they name.
It also ran only this package's own tests. The specification now carries the
behavioural half of clause 9 as a suite every implementation runs, so that is
run first and this package's own tests, which examine the operations version 0.5
added, follow it.
Both are now run under two compiler families. An implementation is a contract's
evidence, and a contract that holds only under the compiler its author used is a
description of that compiler.
* openkal-linux: set a file's modification time, and name the fixed widths openkal names
* docs: the feature under its own name, and where the shared suite is
---------
Co-authored-by: mcpplibs <noreply@mcpplibs.org>
0 commit comments