Re: [9fans] syscall 53

["Aram Hăvărneanu" <aram.h@mgk.ro>]

There are two separate issues here. First, there's the issue of
whether 9front and 9atom should incorporate the change.

For purely egoistic reasons, I'd like that, regardless of the
technical merits of the change. I regulary test labs software on
9front. It would be a pity if I couldn't do that anymore. I have
scripts that set up binds such as to create an environment that
matches both 9atom and the labs distribution. I use these scripts
to collaborate with other people on various projects where my
collaborators and myself use different distributions. This is not
just a thought experiment; this is happening right now, so it affects
me personally.

Simply put, this change is creating (significant) more work for me.
Now, this is not a good enough reason to import this change, but
perhaps if other people are affected in the same way it might be.

Second, there's the issue of the merit of this new system call.
Without more context I believe it's a mistake.

I know that Ron Minnich added a nanotime system call to NxM (or was
it nix?). I don't know why he did that. I heard rumors about
/dev/bintime adding too much jitter, or being too imprecise. The
context of these complains was the Go port to plan9/amd64.

I don't know how much jitter /dev/bintime adds, but I don't think
it matters anyway. If you are latency-sensitive you probably also
want a monotonic clock with relative timing, so /dev/bintime is not
the right tool.

In any case, Go doesn't require an ultra-precise clock and right
now doesn't require so many time calls compared to when the port
was started. The context of the complaints were in some Go *tests*.
The *tests* were written with Linux in mind where gettimeofday is
a fake system call that uses the vdso(7) mappings. The *tests* were
wrong, at least for non-Linux systems.

There was another complaint about /dev/bintime. Some people claimed
that using it leaked file descriptors in multithreaded programs. I
don't understand why this problem can't be solved by opening it
close-on-exec. In fact, this problem doesn't exist in the port of
Go to Plan 9 anymore (although the fix was different)...

In short, I can't justify this new system call. I'm happy to be
educated, however.

-- 
Aram Hăvărneanu