Thanks for the review,
Part of the benefit I believe of syscall/zx is the
potentially-completely-unstable interface is not mixed into the
syscall package. As is, the syscall package with GOOS=fuchsia
introduces very few new exported symbols, and those I believe meet a
decent standard of stability. That means there's a package-level
cordon, zx, on which we can write "here be dragons."
> Also I have to say that names like syscall/zx and syscall/zx/fdio do
> not to me say "Fuschia." They seem rather cryptic. And it sounds
> like the names have already changed once.
Names are distracting, but the short story: this change has been a few
months in the works, and approximately no-one was excited about it.
Another top-level rename like this would be extraordinary, and I would
bet against it. (I delayed this email until it was almost done, and
now wish I had waited another week until I had converted the Go port
and never mentioned it.)
I suppose the names are cryptic. The micro-kernel and a minimal set of
drivers and user-land programs to get a text terminal are bundled
together in a sub-project called Zircon. It works quite well on its
own, as a single git repository with its own makefile-based build
system, independent of the rest of Fuchsia. So the name tends to get
The short-name for Zircon is zx. The x stands for awesome.
Inside Zircon, libfido is implements the protocols for supporting a
subset of POSIX file descriptors. The C library is tiny and almost
everyone uses it via libc, so not a lot of effort was put into making
its name easily recognizable. That's a good argument for saying this
package should be internal to the Go standard library, the reason I
didn't originally suggest it is several other Go programs in Fuchsia
use it for various interesting reasons. (One is a file system
implementation, and so serves the fdio protocol.)
> So in an ideal world I think that we would not add new syscall
> packages at all, but would instead add golang.org/x/sys/fuschia
> perhaps with zx and fdio packages underneath it for more convenient
> naming by users of the packages. Of course we would need to access
> this functionality from the standard library runtime and perhaps the
> syscall package, but ideally we would do that using internal packages
> that are not part of the Go standard library API.
Answered further below,
> At this point I need to say that one thing I do not understand is to
> what degree the current syscall package is usable on Fuschia.
Some of the higher-level wrappers work now, such as syscall.Open,
syscall.OpenAt, syscall.ParseDirent. (That's where the fake fd mapping
table lives, using fdio.)
Others will work at some point, such as syscall.Pipe (which would use
fdio to create a Unix-looking pipe out of a zx.Socket object).
Even more could theoretically work, such as the network syscalls that
look like libc functions such as Accept4. However I skipped over those
making the net package work, by directly calling into the fdio
package. I think it makes the net implementation better.
Unix-isms such as Getpid, Getgid, etc will never be meaningful.
Linux-isms are way out.
> So I would like to understand whether it is possible to create
> internal packages in the standard library that implement the features
> needed by the standard library, and to have golang.org/x/sys/fuschia
> packages that provide the useful functionality for user packages by
> reaching into the standard library. Perhaps this packages could be
> largely generated using build tags and go:linkname tricks, much as
is largely generated.
> I'm not saying we must do things this way, but I'd like to at least consider it.
I think that is possible. It will complicate the plumbing through the
Fuchsia build system in a couple of ways which is why I haven't
considered it until now. In particular, it has been very useful to
have one place to update Go system calls that a standard call to gn,
the build tool, would propagate through the entire system. To keep
that property the act of copying golang.org/x/sys
into the standard
library will have to be part of the Fuchsia build system.
So it will be some work, but I don't see any major problems yet. I
will spend some time experimenting and see if any big problems come
On the topic of the src/vendor/golang_org tree, looking at some git
history it appears these files are updated by writing new commits,
with messages that do not always mention what commit hash in the
original repository the code came from. (Not to pick on anyone in
particular, here's the first example that comes up in a reverse
, many of the other
upstream references are curtailed-hashes) That seems odd given that
git is quite good at merging, and I would expect these update CLs to
be merge CLs (two parent commit hashes, one the top of the go
repository, the other the top of the other repository being merged
in). Do we avoid that for some reason? A gerrit limitation?