Closed cmaglie closed 3 months ago
I did a little research while working on some new features for go-serial
and found these issues:
and I think there is no way now to add a new syscalls to golang core packages. Moreover as I understood, syscall
/ golang.org/x/sys
is a packages only for most common syscalls used in golang core and related packages. For any other cases the code generation is a right way.
And about migration to golang.org/x/sys
I think it is not urgent but necessary improvement.
https://github.com/cwchiu/go-winapi I did not look closely at the package yet. Jut drop it here for history.
go-serial
, so it may be unnecessary workHave to migrate unix codebase to golang.org/x/sys
https://github.com/bugst/go-serial/pull/29
Some steps forward are being made with the x/sys/windows
package, see #187.
I'm closing this one since it makes no more sense to keep it open.
I'm wondering if we can submit the missing syscalls (that we generate with mksyscall & friend) to upstream golang developers to be added to the
syscall
package, so they could be removed from this library.After some research here's what I've found:
syscall
is a frozen package, is kept alive just for the go v1 compatibility promise, here the notice coming from https://golang.org/pkg/syscall/:NOTE: This package is locked down. Code outside the standard Go repository should be migrated to use the corresponding package in the golang.org/x/sys repository. That is also where updates required by new systems or versions should be applied. See https://golang.org/s/go1.4-syscall for more information.
The new golang.org/x/sys package looks promising but we should first migrate the library to use
golang.org/x/sys
instead ofsyscall
.@albenik (or anyone esle) do you have any experience/opinion on that?