-
Notifications
You must be signed in to change notification settings - Fork 18k
x/sys/unix, windows: needs to track update to syscall #10150
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
cc @davecheney @adg |
I looked at windows related syscall package changes only. I can see 3. syscall: use go generate to build zsyscall_windows.go I have (had for a while ready for review) correspondent go.sys change syscall: Readlink doesn't handle junction on windows I dropped ball with this change. I will take care of it. syscall: make mksyscall_windows.go to work even when output does not uses unsafe This change does not need to be copied to go.sys. Only z*.go go.sys files needs to be re-generated. That has already happened in unrelated go.sys change. Alex |
I would propose to remove networking-related stuff from sys/unix; specifically the following:
Simply net sub repository seems to be right place for them. Thoughts? |
Mikioh: I don't know enough about networking to guarantee whether this is OK, but that sounds reasonable to me. Alex: 2530 LGTM. Thanks. |
https://go-review.googlesource.com/#/c/4913/ also needs to be applied |
https://go-review.googlesource.com/7543 also needs to be applied |
Those libraries, routing message parsers, netlink message parsers, berkeley packat filter are linux packet filter, are subsets and just for the net package of standard library. It would be better keeping, extending them at the net sub repository instead of here. Updates golang/go#10150. Change-Id: I1ca437bea2e2be7f7f8f6496d4db291629f49136 Reviewed-on: https://go-review.googlesource.com/7581 Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-by: Rob Pike <r@golang.org>
https://go-review.googlesource.com/8022/ also needs to be applied. |
Some Linux architectures (e.g. arm64) don't have the getpgrp syscall, use getpgid(0) to emulate it. Update golang/go#10150. This brings CL 8022 that has been applied to the syscall package to x/sys. Change-Id: I24c6d7e8b5b2f075ca4e68b142b2e03ab8a43342 Signed-off-by: Shenghou Ma <minux@golang.org> Reviewed-on: https://go-review.googlesource.com/8023 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
https://go-review.googlesource.com/8022 has been applied to x/sys by https://go-review.googlesource.com/8023 |
https://go-review.googlesource.com/#/c/8721/ handles 6350 and 6385 |
https://go-review.googlesource.com/#/c/8720/ handles 2167 |
Related issue golang/go#10150 Change-Id: I38e3e13238624655bb828d501bc865ff8a4312e9 Reviewed-on: https://go-review.googlesource.com/7493 Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
This style of bug is hard to follow or close. N smaller, closable bugs might be better. |
I like having it in one. http://golang.org/cl/8723 |
Perhaps a milestone? Whatever github has to group issues. |
This is a copy of http://golang.org/cl/9870 in the syscall package. This is in preparation for arm64 support, as the arm64 Linux kernel does not have an inotify_init system call, only inotify_init1. Update golang/go#10150. Change-Id: I9224a094af79adbb2f5714ad977b195d5a941eb0 Reviewed-on: https://go-review.googlesource.com/10036 Reviewed-by: Rob Pike <r@golang.org>
https://golang.org/cl/9870/ I will create a new bug with only the remaining ones, since people seem offended by this particular noise source when there is so much other noise out there. |
Since 1.4, my hand scan of the changes to the core repo's syscall package yields these CLs, many of which need to be applied to the go.sys repo:
https://go-review.googlesource.com/#/c/1372/
https://go-review.googlesource.com/#/c/1640/
https://go-review.googlesource.com/#/c/1930/
https://go-review.googlesource.com/#/c/1932/
https://go-review.googlesource.com/#/c/1940/
https://go-review.googlesource.com/#/c/2123/
https://go-review.googlesource.com/#/c/2307/
https://go-review.googlesource.com/#/c/2589/
https://go-review.googlesource.com/#/c/2746/
https://go-review.googlesource.com/#/c/2810/
https://go-review.googlesource.com/#/c/2815/
https://go-review.googlesource.com/#/c/2816/
https://go-review.googlesource.com/#/c/2817/
https://go-review.googlesource.com/#/c/3014/
https://go-review.googlesource.com/#/c/3983/
https://go-review.googlesource.com/#/c/4164/
https://go-review.googlesource.com/#/c/4330/https://go-review.googlesource.com/#/c/5005/
https://go-review.googlesource.com/#/c/5287/
https://go-review.googlesource.com/#/c/5288/
https://go-review.googlesource.com/#/c/5576/
https://go-review.googlesource.com/#/c/5833/
https://go-review.googlesource.com/#/c/5835/
https://go-review.googlesource.com/#/c/5836/
https://go-review.googlesource.com/#/c/5837/
https://go-review.googlesource.com/#/c/6350/
https://go-review.googlesource.com/#/c/6372/
https://go-review.googlesource.com/#/c/6385/
https://go-review.googlesource.com/#/c/6391/https://go-review.googlesource.com/#/c/7123/
This is not a perfect list. Some may be missing and some are internal/syscall and might not apply.
These CLs (and whatever follow, which should be added to this bug) need to be examined and, if appropriated, adapted and applied to go.sys.
More fundamentally, we also need to stop these packages from diverging so much in future. Some process may be required to encourage updating.
From a higher perspective, I am surprised at the amount of churn in a supposedly quiet package.
The text was updated successfully, but these errors were encountered: