Some devices return useful info on specific file remove (eg #0/pid, #0/ppid...)
so we need a tool to get such info.
rm -e '#0/pid' '#0/ppid'
#0/pid 65
#0/ppid 59
In Plan9 the create syscall fallback on a open(OTRUNC) if the
path provided already exists. This is actually a common requirement
as most programs (editors, cat...) simply requires that a file is
there and is empty, and doesn't care overwriting existing contents
(note that this is particularily sensible with something like fossil).
In Jehanne the application is responsible of actually handle this
"file exists" error but libc provides ocreate() to mimic the Plan9
behaviour. Note that ocreate introduce a subtle race too: the path
is walked several times if the file exists, thus it could misbehave
on concurrent namespace changes. However I guess this is not going to
happen often enough to care now.
NOTE we will probably address this rare race too, with a more drammatic change
to syscalls: a new walk() syscall that will provide an unopen fd.
Added wdir to devself and devproc:
- read '#0/wdir' to get the working directory of the calling process
NOTE that a read(fd, nil, -1) will return the negated length
of the working directory, just in case you want to
allocate the memory required
- read '/proc/n/wdir' to know the working directory of process n
(read(fd, nil, -1) still returns the negated length)
- write '#0/wdir' to change the working directory of the calling process
NOTE: no offset is allowed and the provided string must
be null terminated
- write '/proc/n/wdir' to change the working directory of process n
NOTE: no offset is allowed and the provided string must
be null terminated; moreover if another process change the working
directory change during the write, the current process will
receive an error.
In libc updated getwd() and chdir().
Also modified pwd to get advantage of the new file.
To test, run /arch/amd64/qa/kern/wdir.rc or simply try
% pwd
/usr/glenda
% echo -n /tmp > /proc/$pid/wdir
% pwd
/tmp
% cat '#0/wdir' && echo
/tmp
The expected use cases for wdir in devproc are rio and acme.
Also, note that we could theoretically remove the cd builtin
from rc and simply implement it as a rc function.
We don't do that to preserve rc portability to other OS.
Devself provides to each process access to its own structures.
So far it contains four files:
- pid
- ppid
- pipes used to implement pipe(2)
- segments used to implement segattach, segdetach and segfree
Jehanne is going to use a new file protocol, but Plan 9 is really
coupled with 9P2000.
Renamed fcall.h as 9P2000.h and introduced specific constants such
as NP_OREAD, NP_OWRITE and so on, so that we can use different values
in the kernel and new protocol.
Renamed devmnt to devninep, since it's actually a device serving 9P2000
file systems.
Also, fixed 9P2000 support in Jehanne, that was broken with the introduction
of OSTAT.
After the removal of dumb push in crt0 (commit 929014ebca5c738d3854758326de7abfb77c1ef1)
the first byte of the c integer is not zeroed anymore (which is correct).
But since ms.c reads and bit-match a single byte in c, when it's an int some test success/fail
due to the state of the unused bytes.
This makes the mouse turn crazy.
So we turn it into a char, so that bitmasks and tests work as expected.
Added cross-compiler to $PATH in continuous-build.sh
and enabled sudo in .travis.yml.
NOTES:
- travis is unable to update submodules pointing to commits out of their master branch,
so if you push to devtools, you need to push into master branch or your build will be broken
- travis caches conflicts with submodule managements, so we use tmp/toolchain instead of
hacking/cross/toolchain in .travis.yml and continuous-build.sh will mv binaries as required.
Note that libc is what distinguish "native" software from "non-native"
in Jehanne: further C libraries can be ported to Jehanne, but this libc
will remain the main building block of the system.
Also note that a few files have not been ported from Harvey:
- 9sys/pushtls.c
- port/rijndael.c
- port/rijndael.tbl
- port/sha2.c
Pushtls.c depends on libmp and libsec so libc is not the appropriate place
for it. The other three will be moved to libsec.
Giacomo Tesio