Skip to content
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

Backward compatibility for systems that doesn't support accept4 #1465

Closed
zonyitoo opened this issue Feb 25, 2021 · 9 comments
Closed

Backward compatibility for systems that doesn't support accept4 #1465

zonyitoo opened this issue Feb 25, 2021 · 9 comments

Comments

@zonyitoo
Copy link
Contributor

zonyitoo commented Feb 25, 2021

When running on some old systems, like an old Android, they doesn't have the accept4 syscall. When running programs on these platforms, we will get an error: Function not implemented (os error 38).

It would be better to automatically fallback to accept when accept4 returns this errno ENOSYS.

@zonyitoo zonyitoo changed the title Backward compatibility to system that doesn't support accept4 Backward compatibility for systems that doesn't support accept4 Feb 25, 2021
@Thomasdezeeuw
Copy link
Collaborator

What Android version are you running. Because accept4(2) was added to Linux in 2.6.28. According to https://android.stackexchange.com/questions/51651/which-android-runs-which-linux-kernel Android 1.6 is based on 2.6.29. Which means this wouldn't work on Android 1.5, that way too old to support.

@jshearer
Copy link
Contributor

So it's not just restricted to x86 android then. I encountered this same issue, and fixed it for my use case: #1446. Maybe the conditional just needs to be expanded to match all of android, or somehow detect at runtime whether the syscall is supported? (though that would introduce some overhead...)

@zonyitoo
Copy link
Contributor Author

zonyitoo commented Feb 26, 2021

I was running on an Android Emulator (which is a x86 Android I believe).

@jshearer Your fixes are perfectly working on .apks that are built with x86 toolchain, but what if a .apk built with ARM toolchain and then ran on a x86 Android? :)

Maybe the conditional just needs to be expanded to match all of android, or somehow detect at runtime whether the syscall is supported?

Yup. See my PR.

But those Android that running on ARM platform do have the accept4 syscall. And not all x86 Android are shipped without the accept4 syscall.

@jshearer
Copy link
Contributor

jshearer commented Feb 26, 2021

but what if a .apk built with ARM toolchain and then ran on a x86 Android?

Is this with the new android 11 emulation layer? Because otherwise that shouldn't work, right? Different architectures and all that

@zonyitoo
Copy link
Contributor Author

zonyitoo commented Feb 26, 2021

I have no idea. I found this on an Emulator called MuMu. But accept4 works well on another x86 Emulator called BlueStacks.

Kernel version: 4.0.9-android-x86+luoweiqiao@a11-gz02-test.i.nease.net #1 Thu Jan 21 21:03:25 HKT 2021
Android version: 6.0.1

Actually most of the x86 Emulators can run ARM apks.

@jshearer
Copy link
Contributor

Actually most of the x86 Emulators can run ARM apks.

I did not know that! Neat

@Thomasdezeeuw
Copy link
Collaborator

I currently see this as more of a problem of the emulator than Mio. The Linux kernel has accept4(2) since version 2.6.28, so if the emulator reports 4.0.9 it should it. Furthermore Android 5.0 (API version 21), released in 2014, should also have accept4(2) according to android/ndk#1372. So this leads me to believe it's a problem with the emulator(s), not actual Android.

Also @zonyitoo I'm not going to accept #1466 in its current form as it has needless overhead for non-Android/emulator platforms.

@zonyitoo
Copy link
Contributor Author

Hmm, alright. It is reasonable.

@Thomasdezeeuw
Copy link
Collaborator

This was fixed mostly by #1446 for emulator. I don't there is anything actionable here.

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

Successfully merging a pull request may close this issue.

3 participants