0.7.0

openkal-musl 0.7.0 — the reported crash, and what adopting openkal 0.9 exposed

The crash

rt_sigprocmask returned without writing the caller's old-mask buffer. A
program that read it acted on uninitialised stack. Three lines reproduce it and
the fix is one case in the dispatcher.

What links made possible, and what they exposed

symlinkat and readlinkat are answered through openkal 0.9's
kal_fs_link_create / kal_fs_link_read, and fstatat honours
AT_SYMLINK_NOFOLLOW — so stat and lstat are two questions again. One
symlink used to make a whole directory tree uncopyable through std::filesystem.

Then fs::remove_all on a directory holding a link returned ENOTEMPTY and left
the tree standing, while every operation it is built from behaved correctly.
O_NOFOLLOW on a link must report ELOOP; this port resolved (openkal offers no
opening that declines to) and answered ENOENT, and libc++ reads ENOENT as
"the entry is already gone". The enquiry that answers it is the one openkal 0.9
added.

openkal's granularity is not this library's page size

kal_memory_granularity() is the coarsest quantum a caller must respect, and an
implementation for a machine with no memory management unit answers one —
correctly. libc.page_size is a different thing wearing the same name. Given
one, the allocator asked for one-byte extents; over openkal-opensbi a program
printed three of its four lines and stopped. The answer is now taken as a floor.

The probe's assertion had said "a positive power of two", and one is both.

Also: node identity from kal_node_info rather than constants, the environment
copied out, getpgid/getpgrp/getsid, membarrier, and the child table
raised from 64 to 256.