This creates more object files in the static library which reduces the size
of statically linked files as only the relevant object files are included.
In my experience, it reduced the size of the system initrd from 1.9 MiB to
1.6 MiB which is valuable.
Unfortunately this area is not standardized by POSIX. Linux uses an ioctl
which is not that bad, but I'd like to have a designated function. I'm not
sure if this facility is powerful enough and whether it should be improved.
Also note that I use a struct winsize as on Linux, but I use size_ts instead
for the heck of it. Perhaps I should use another name for the struct.
Programs were crashing randomly at startup on the kthread branch. After some
investigation, it turned out that the programs weren't correctly loaded by
the program loader in rare cases. Although, all investigation showed that
the program loader was correct and so was the interrupt routines (well,
almost, but nothing that could really trigger this). Yada yada, a few months
later I discovered that memcpy(3) was being corrupted by an interrupt handler
(which was correct). Turns out memcpy used stack space it hadn't allocated.
This is a Linux optimization that I had forgotten to disable with
-mno-red-zone in libmaxsi and thus interrupts just overwrote the stack of
optimized functions. Eek!
The string returned is now const - POSIX did not allow modifying the string
in any case, conforming applications should not break. If _SORTIX_SOURCE is
defined strerror(3) automatically redirects to sortix_strerror(3),
otherwise the application will receive the traditional function.
sfork(2) now calls sforkr(2) with the current registers.
This will prove useful in creating threads, where user-space now can fully
control what state the child will start in. This is unlike the Linux clone
system call that accepts a pointer to the child stack; this is more powerful
and somehow simpler. Note that this will create a rather raw thread; no
thread initization has been done by the standard thread API (when it is
implemented), so this feature shouldn't be used by programmers unless they
know what they are doing.
fork(2) now calls sfork(2) directly. Also removed fork(2) and sfork(2) from
the kernel as they are done using sforkr(2) now. So technically they aren't
system calls right now, but that could always change.
sfork is much like rfork except sharing is default for everything.
Eventually, I'll make a rfork(3) wrapper function around sfork(2) to
provide compatibility to BSD programs.
I don't like Linux clone(2): that's some messy function.
unsetenv(3), envlength(3), getenvindexed(3), and environ(7).
This provides the user-space foundation for environmental variables.
Note that this works over fork(2), but not execve(2) yet.
