Submit custom syscalls to golang

[cmaglie]

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 of syscall.

@albenik (or anyone esle) do you have any experience/opinion on that?

[albenik]

I did a little research while working on some new features for go-serial and found these issues:

1. https://github.com/golang/go/issues/12853
2. https://github.com/golang/go/issues/13104

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.

[albenik]

https://github.com/cwchiu/go-winapi I did not look closely at the package yet. Jut drop it here for history.

Pros

1. No need to write/generate own wrappers to windows api calls at least

Cons

1. External dependency.
2. Most of api calls where already implemented in go-serial, so it may be unnecessary work

[albenik]

Have to migrate unix codebase to golang.org/x/sys https://github.com/bugst/go-serial/pull/29