Closed helsaawy closed 2 years ago
This seems like a change that should be split across multiple PRs. For instance can we add sockets
package, and then use it in another PR?
I'd also like to understand better what the motivation is for these changes. What can a user of go-winio not do without these changes?
This seems like a change that should be split across multiple PRs. For instance can we add
sockets
package, and then use it in another PR?I'd also like to understand better what the motivation is for these changes. What can a user of go-winio not do without these changes?
Without the sockets
package, a user wouldn't be able to call GetPeerName
, Bind
, or ConnectEx
on an arbitrary socket type (the syscall
packages only allow them on types implemented internal to them). We had our own bind
internally here, but it wasnt exported and required handling raw pointers.
Those three (GetPeerName
, Bind
, andConnectEx
) are fairly useless on their own, but they allow use to easily define our own Dial
for HV sockets.
I could add sockets
alone, but I think it would look fairly unnecessary, as without Hvsock defining its own socket type, it would appear fairly redundant with golang's socket functions.
That said, I can split this into sockets
and HV sockets updates (or HV sockets feature additions and bug fixes).
Added:
Dial()
andDialContext()
to dial a specific Hyper-V socket at a known address (along with a correspondingHvsockDialer
struct.Bug fixes:
socketError
used bybind
was incorrect, it should beint32(-1)
, notuintptr(^0)
Created a
sockets
package, currently only with syscalls toBind
,ConnectEx
andGetSockName
, bypassingsyscall/windows
restrictions on the types that cane be usedSigned-off-by: Hamza El-Saawy hamzaelsaawy@microsoft.com