What is the state of syscall vs. x/sys?

[Nathan Youngman]

Hi,

Is syscall really frozen?

Back before the launch of Go 1.4, there was a proposal to freeze syscall and move maintenance to the x/sys subrepo which was created in August 2014.

https://docs.google.com/document/d/1QXzI9I1pOfZPujQzxhyRy6EeHYTQitKKjHfpq0zpxZs/edit

Since that time there has been numerous commits to the syscall package:

After the release of Go 1.4: https://github.com/golang/go/commits/master/src/syscall

Back when it was pkg/src around the time of the freeze: https://github.com/golang/go/commits/release-branch.go1.4/src/pkg/syscall

Of course x/sys has seen numerous commits as well: https://github.com/golang/sys/commits/master and indeed it is copied into internal/sys as the proposal intended.

This all leaves me a little confused as which library to use. The latest updates to x/sys could potentially work with previous releases of Go, but are all the patches to syscall also applied to x/sys?

~

Now for the story of how this came to light. The fsnotify library did not work on linux/arm64 or on power pc architectures.

Riku Voipio submitted a CL to x/sys https://go-review.googlesource.com/#/c/21971/ and proposed that fsnotify switch to use it.

Meanwhile Lynn Boger submitted a CL to syscall and got it fast-tracked into the Go 1.6.2 release. https://go-review.googlesource.com/#/c/22207/

I take full responsibility for this little mishap. As the "project manager" for fsnotify, I should've been paying closer attention to these CLs, as I'm the one who knew they were both going on. The result is that switching to x/sys has broken power pc support worse than it was before. Now the fine folks at IBM are having to resubmit CLs to x/unix for power pc.

It will all work out in the end, but it does raise several questions.

~

The only thing I really want to know is whether switching to x/sys for unix (and eventually windows) is the right move.

Thanks,

Nathan.

[Andrew Gerrand]

On 22 April 2016 at 13:06, Nathan Youngman <he...@nathany.com> wrote:

Is syscall really frozen?

The policy is that syscall should only be changed to support the standard library.

I believe the commits since that proposal all meet that criterion.

[Rob Pike]

Yes, you should switch to x/sys. Some things crept into syscall under the covers, others went in because it's the job of that package to support the main repo and changes were required. But external packages should be using x/sys.

-rob

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nathan Youngman]

Thanks for clarifying.

Nathan.

--

Nathan Youngman 
Email: he...@nathany.com
Web: https://nathany.com

[Nathan Youngman]

The release notes for Go 1.10 contain additional functions in syscall:

https://tip.golang.org/doc/go1.10#syscall

I continue to be confused by the purpose and plans for golang.org/x/sys fork of syscall.

If syscall is receiving additions, then why not also include changes such as the following there:

https://github.com/golang/go/issues/15393

Then fsnotify can (eventually) go back to depending on the standard library syscall instead.

Nathan.

Tracking issue: https://github.com/fsnotify/fsnotify/issues/224

Thanks for clarifying.

Nathan.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Brad Fitzpatrick]

x/sys is still where new stuff goes. The changes to std syscall are:

1) SysProcAttr, which is special. It can't live in x/sys because things in std use it:

https://golang.org/pkg/os/#ProcAttr.Sys

https://golang.org/pkg/os/exec/#Cmd.SysProcAttr

2) And UtimesNano has been available on all Unix geese since Go 1.1. This is just fixing an omission.

[Nathan Youngman]

Okay. Thank you.

Thanks for clarifying.

Nathan.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Nathan Youngman 
Email: he...@nathany.com
Web: https://nathany.com

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.