-
Notifications
You must be signed in to change notification settings - Fork 108
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
Proposal: add x32 to the list of architectures that are built #165
Comments
Also (surprisingly?) linux/x32 seems to be properly supported as a platform by docker: |
Given that x32 is still a ports architecture (and from what I've seen, not a very popular one, and one that the kernel maintainers have considered dropping support for entirely 😬), I'd rather not put much effort into it -- I don't think it's even supported by Go, is it? (So you couldn't have a pure-x32 system that runs Docker successfully. 😞) |
Yes, it's not supported by Go and hence you can't run Docker natively, but I think the more useful case is running x32 binaries on a mostly AMD64 system, which an official image would facilitate. I thought it would be interesting for people to experiment with; i.e. 'build a multi-arch image with x32 if it works and see if it improves your performance/memory usage'. Agreed, it's not worth much effort, but I was hoping (since it basically already works) that it would be as easy as just adding another arch to some build script, assuming that it's possible to run with a kernel that supports x32. |
Re popularity, I suspect that the only reason x32 is ever likely to gain in popularity is if it becomes easy to use with Docker. |
Biggest blocker is probably that it is „only“ a port. While 4gb is not much system memory today it may be much for a container. ~10 years passed since x32 was realized. As you claim it already works (some)one now is invited to do some benchmarks with x32 containers on an x64 host - running typical low memory container applications (if they build that is) |
My concern is less that it's a ports architecture and more that the future of it is uncertain. There was an attempt as recently as four years ago (maybe even more recently than that?) to remove support for x32 from the kernel itself. Ultimately it didn't get removed, but I don't think the interest in or support for it has grown much since then. For example, https://wiki.debian.org/X32Port claims that Debian is desperately seeking porters for the architecture (and it isn't exactly a new call for porters). Several good links if you're interested in helping x32 become more official/supported within Debian (although from the thread I linked above, it sounds like the kernel could use some help/focus in this regard too):
IMO it's also interesting to compare https://buildd.debian.org/status/architecture.php?a=riscv64&suite=sid¬es=out-of-date to https://buildd.debian.org/status/architecture.php?a=x32&suite=sid¬es=out-of-date, for example (the former being a ports architecture we do build/publish for currently). That latter set contains concrete places the project could use some extra help to bring x32 closer to sustainable/supported. |
I totally agree that x32 is in a questionable state at the moment, and I'm (sadly) very unlikely to be the part of rescuing it, though I appreciate the links; any time I've thought of contributing to Debian I've been a little oppressed by the sheer weight of its complexity/history/etc. I'd still suggest that adding x32 to the docker builds would be an interesting thing to do if it doesn't cost much time/effort, and would increase the probability that x32 does become a well-maintained architecture. The widespread use of containers has meant there's a little more emphasis on being able to pack more things in, and the enthusiasm for 'minimal' docker images could potentially extend to using x32. Is there a cost/downside I'm missing from adding x32 here? That it gets added here and then dropped by Debian or the kernel? But in that case it could just be dropped again... |
@JoelLinn suggestions for benchmarks? You can easily check that it works if you use this base image and set |
Seems to work for me on the normal Debian kernel (well, with
syscall.x32=y
set, which might be a blocker...):The text was updated successfully, but these errors were encountered: