This large commit address several issues
- removed 386 directory: Jehanne is 64bit only
- simplified kernel options management
- rewritten boot process
- ported memory related stuff from 9front's 9/pc64
- removed devacpi
- removed old code
- deep refactor of awake syscall
- removed MCACHE support for mount
- fix libc's setjmp/longjmp
This commit introduce a special rendezvous point at (void*)~0 that
cannot be reached by any process, since it's not added to the
rendezvous group.
This turns the rendezvous syscall to a cheap way to block until
either a note or a wakeup from awake(2) occurs.
This new feature is used in libc's sleep: the test qa/kern/fork_chain
has shown that using a stack address as rendezvous point is not safe enougth
for sleep, since two different process forked from the same function can
call sleep with the same base pointer. This lead the wakeup variable in
jehanne_sleep to have the same address on both process.
TODO add a test that show this behaviour in the old code.
To enable -O2 compilation we have to disable some optimizations:
- strict-aliasing (TODO: introduce required unions to enable this)
- aggressive-loop-optimizations
- array-bounds
Affected builds are
- sys/src/cmd/dossrv/build.json
- sys/src/cmd/ip/build.json
- sys/src/lib/authsrv/build.json
- sys/src/lib/memdraw/build.json
This way sleep() knows that it should not interrupt the process
to serve awake().
Also rename Proc.insyscall to Proc.inkernel since that's the meaning
of the flag, which is only read to serve awake()'s mechanics and
to accounttime(). Indeed faultAmd64 was setting insyscall to 1.
The "write on closed pipe" note should be posted only
if the write occurred on a closed pipe.
Before this fix, on any interrupt caused the note to be sent,
despite the pipe being open and fully working.
Awake can now interrupt several blocking syscalls (even
during note handling).
Among others, it can interrupt await, pread and pwrite.
It cannot interrupt several others for different reasons:
- awake cannot be interrupted by awake;
- syscalls like remove and create can be used for kernel comunication
and it would be hard to know if the effect occurred in the
receiving fs if they were interrupted;
- other syscalls do not need awake since they just provide access
to kernel infos (eg seek or fd2path)
NOTE: awakes registered before a note cannot occur during the note
handling and will be deferred till the next call to noted.
Giacomo Tesio