Skip to content
This repository has been archived by the owner on May 20, 2020. It is now read-only.

arm and windows support for fdbased link endpoint #6

Open
Archieeeeee opened this issue Jun 1, 2018 · 7 comments
Open

arm and windows support for fdbased link endpoint #6

Archieeeeee opened this issue Jun 1, 2018 · 7 comments

Comments

@Archieeeeee
Copy link

From my understanding, fdbased link endpoint only supports linux,amd64 mainly because the fd IO is based on file rawfile_unsafe.go, if using "golang.org/x/sys/" package to implement fd IO operation, more OS/arch will be supported.

func Read(fd int, p []byte) (n int, err error)
func Write(fd int, p []byte) (n int, err error)
func SetNonblock(fd int, nonblocking bool) (err error)

@Archieeeeee Archieeeeee changed the title arm and windows support for fdbased link endpoint support arm and windows support for fdbased link endpoint Jun 1, 2018
@iangudger
Copy link
Contributor

writev is used over write so that we don't have to re-allocate slices for performance reasons. In addition, because we know that the syscall won't block, we can use syscall.RawSyscall instead of syscall.Syscall for performance reasons as well.

@interarticle
Copy link

interarticle commented Jul 6, 2018

I think the use of SYS_WRITEV and RawSyscall are totally fine with respect to the title of the question, since these are supported by the built-in "syscall" library and will compile on GOARCH=arm64.

The question is why rawfile_unsafe.go needs to implement a custom assembly-version of blockingPoll(), which I think can be implemented instead as:

r1, _, err := syscall.Syscall(syscall.SYS_POLL, uintptr(fds), uintptr(nfds), uintptr(timeout))
return r1, err

The only difference I can tell between the custom blockingPoll() and the above version is the use of runtime·entersyscallblock instead of runtime·entersyscall before performing the syscall. Is there a strong performance/resource-consumption reason for using the former?

@iangudger
Copy link
Contributor

iangudger commented Jul 6, 2018

runtime·entersyscallblock has significantly better performance than runtime·entersyscall.

I have made it so that syscall.Syscall is now used on non-AMD64 Linux: a1b2fa9

@nl5887
Copy link

nl5887 commented Aug 13, 2018

Seems syscall.SYS_POLL is missing on arm64, whereas it is available on arm. There is a syscall.SYS_PPOLL available on arm64, if we don't use sigmask the syscall SYS_PPOLL behaves the same as SYS_POLL.

if the sigmask argument is specified as NULL, then no signal mask
       manipulation is performed (and thus ppoll() differs from poll() only
       in the precision of the timeout argument).

@nl5887
Copy link

nl5887 commented Aug 14, 2018

Netstack is working now on arm, arm64, amd64 with this commit honeytrap@dc46347.

I'll work on Gerrit to submit the commit.

@iangudger
Copy link
Contributor

@nl5887, any update?

@tamird
Copy link
Contributor

tamird commented Feb 7, 2020

This is all working now, I think. Can this be closed?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants