0.9.0 --- the five operations openkal 0.10 adds, and why each was missing - #22
Merged
Conversation
…sing Implements `kal_fs_lock', `kal_fs_unlock', `kal_fs_capacity', `kal_fs_set_modified_at', `kal_process_spawn_bound' and `kal_task_parallelism', and claims `KAL_FS_PROP_LOCKS', `KAL_FS_PROP_CAPACITY' and `KAL_PROCESS_PROP_BOUND_LIFETIME'. ⭐⭐ THE LOCK IS THE OPEN-FILE FORM AND NOT THE PROCESS FORM, WHICH IS THE WHOLE DIFFERENCE. This kernel's oldest record lock is held by the PROCESS and is released as soon as that process closes ANY descriptor for the node --- so a library that opened one file twice destroyed its own lock, and two parts of one program could not exclude each other at all. openkal states the holder as the `kal_file', which is exactly what `F_OFD_*' describes. Measured, and it is the observation that tells the two forms apart: with one file locked, a SECOND open file of the same name IN THE SAME PROGRAM is refused with `kal_err_again'. The process-held form would have granted it.⚠️ Release upon death is the half a caller cannot build for itself. Exclusion it can --- `KAL_OPEN_EXCLUSIVE' and a name --- but nothing above this line releases that name when its holder dies, so a program that ended abnormally while holding one would be locked out of its own file for ever. --- the other four ---------------------------------------------------------- `kal_fs_capacity' reports BYTES, from `f_bavail' and not `f_bfree': the second counts blocks only a privileged writer may reach, and the question is what THIS program could use. Measured: 1500829MB. `kal_fs_set_modified_at' is the stated route to a directory's time. There was none --- the file-taking form takes a `kal_file' and a directory is a `kal_dir' --- so openkal-musl reached one by opening the directory for READING and setting the time on that, outside anything the interface said. Measured: a directory stamped and read back at 1700000000. `kal_task_parallelism' asks for the set THIS context may run on rather than the set the machine has: a program confined to two processors should size itself against two. Zero is "cannot say" and is not one. Measured: 32. `kal_process_spawn_bound' arms `PR_SET_PDEATHSIG' with SIGKILL --- not a signal the started program may decline, because the caller asked for a program that does not outlive it and not for one that is invited not to.⚠️ AND IT IS ARMED BEFORE THE REPLACEMENT AND CHECKED AFTER. The setting survives the replacement, but the caller could have ended in between, in which case the signal is already spent and this image would survive it. Reading the parent's identity after arming closes that window.⚠️ THE PROPERTY WORD WAS THE ONE THING THE PROBE CAUGHT. `kal_process_spawn_bound' was implemented and `KAL_PROCESS_PROP_BOUND_LIFETIME' was not claimed, so a caller asking first would have been told the operation was unavailable while it worked. Nine observations green and that one red, which is what the property word is for.
⚠️ ⚠️ THE STANDARD THIS CALL COMES FROM NAMES TWO VALUES FOR ONE CONDITION AND LEAVES THE CHOICE TO THE SYSTEM. openkal names one. For a lock attempt that does not wait, a range another holder has is reported as EITHER of two errors --- the system decides. So a program written against the standard accepts both, and an implementation of openkal must NOT pass that choice on: `kal_err_again' is the answer a caller polls upon, and the other value translates to `kal_err_permission', which a caller reads as "asking again will not help" and acts upon by stopping. ⭐ NARROWED TO THE ATTEMPT THAT DOES NOT WAIT, because that is the only path for which the two values carry this meaning. A permission failure anywhere else keeps its own answer.⚠️ Found by looking rather than by failing: this kernel answers the first value in practice, so the observation passes here either way. The sibling implementation is on a system whose lineage answers the other one, and the two implementations must not disagree about what a caller sees.
…acks The comment above `execveat' said the started program's working directory is the directory supplied here. It is not: `b' resolves the program's NAME, and resolving a name is not entering a directory. The started program inherits this implementation's working directory, whatever it happens to be. Found by a consumer's own test, not by reading: chdir, start a program, ask it for its working directory, and it answers the directory the caller left --- with a host as control answering the one the caller entered. Not fixable here, and the comment now says why: an `fchdir(b)' would make the sentence true and the behaviour no better, since `b' is whichever preopen the name resolved under. Naming a program and naming where it runs are two directories and the interface carries one.
`git add -A' swept in a working-tree edit that pointed openkal at a checkout on my disk. The repository's own guard rejected it, which is what it is for.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of the openkal 0.10 move: mcpplibs/openkal#25.
openkalisthe shared dependency of every package here and a version requirement is exact —
an implementation left at 0.9.0 while a consumer moves to 0.10.0 does not get its
own older contract; the two are irreconcilable and nothing resolves at all.
Branch
declarations-0.10exists in every implementation so the specification'sown cross-repository job builds against this one.
The commit message states what this package does with each of the five new
declarations and why.