Hi all,
Cinap said out in the other thread that nsec had been added and then
abandoned because it wasn't right. That turns out only to be half wrong -
it's not true today but it probably should be true in the future. We do
need a time-related special system call, but not that one.
I just saw a Go program crash because it observed monotonic time move
backward. That happened because on Plan 9, Go does not have easy access to
monotonic time, only Unix time. And when Unix time moves backward (like
timesync makes it do) then Go sees that as monotonic time moving backward.
The ironic thing is that #c/bintime has all the info Go needs, but Go
stopped using it.
The nsec system call was added to avoid needing to keep #c/bintime open in
all programs, avoid the problems of it accidentally using a standard fd (0
1 2) etc. But nsec is too specialized. bintime returns more than just Unix
nanoseconds. The right answer would have been to add a readbintime(p, n)
system call that acts like pread(/dev/bintime, p, n, 0), dispatching to the
kernel's readbintime function. I suggest we actually do that, which would
make monotonic time access work right.
While we are avoiding pre-opened file descriptors, the other thing modern
operating systems have come to realize is that /dev/random is important
enough to be able to access without a file descriptor. It would be good to
add a readcrypto(p, n) system call at the same time.
Perhaps there should not be two new system calls. Perhaps it should be one
new readspecial(id, p, n) system call.
Or perhaps there should be no new system calls, and instead pread should
accept a few distinguished negative file descriptors. Obviously fd=-1 has
to keep returning an error, but perhaps we should define that -2 is
#c/bintime and -3 is #c/random. Or if -2 is too close to -1, we could use
-1000 and -1001.
Personally I think the negative numbers are a bit too special, and I'd be
inclined to add two new system calls kread(kfd, data, n, off) and
kwrite(kfd, data, n, off), which are like pread and pwrite except that they
operate on "kernel file descriptors", which are small integers that are
always open and refer to specific kernel resources. The initial set of
kernel file descriptors are
0 #c/bintime
1 #c/random
This set could be extended over time; use of an unrecognized kfd would
return an error. This approach solves the "keep special fds open" problem
directly, without abandoning Plan 9's "everything is a file" quite as much
as nsec(2) does or readbintime(2) or readcrypto(2) would.
Thoughts?
Best,
Russ
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T59810df4fe34a033-Mc872d415f55dab215c26a530
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
