path: root/sys/contrib/cloudabi/cloudabi_vdso_x86_64.S
Commit message (Collapse)AuthorAgeFilesLines
* Drop cloudabiKonstantin Belousov2021-09-211-449/+0
| | | | | | | | | | | | | According to https://github.com/NuxiNL/cloudlibc: CloudABI is no longer being maintained. It was an awesome experiment, but it never got enough traction to be sustainable. There is no reason to keep it in FreeBSD. Approved by: ed (private mail) Reviewed by: emaste Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D31923
* Import the latest CloudABI definitions, version 0.16.Ed Schouten2017-10-181-23/+11
| | | | | | | | | | | | | | | | | | | | | | | | | The most important change in this release is the removal of the poll_fd() system call; CloudABI's equivalent of kevent(). Though I think that kqueue is a lot saner than many of its alternatives, our experience is that emulating this system call on other systems accurately isn't easy. It has become a complex API, even though I'm not convinced this complexity is needed. This is why we've decided to take a different approach, by looking one layer up. We're currently adding an event loop to CloudABI's C library that is API compatible with libuv (except when incompatible with Capsicum). Initially, this event loop will be built on top of plain inefficient poll() calls. Only after this is finished, we'll work our way backwards and design a new set of system calls to optimize it. Interesting challenges will include integrating asynchronous I/O into such a system call API. libuv currently doesn't aio(4) on Linux/BSD, due to it being unreliable and having undesired semantics. Obtained from: https://github.com/NuxiNL/cloudabi Notes: svn path=/head/; revision=324727
* Complete the CloudABI networking refactoring.Ed Schouten2017-08-301-24/+6
| | | | | | | | | | | | | | Now that all of the packaged software has been adjusted to either use Flower (https://github.com/NuxiNL/flower) for making incoming/outgoing network connections or can have connections injected, there is no longer need to keep accept() around. It is now a lot easier to write networked services that are address family independent, dual-stack, testable, etc. Remove all of the bits related to accept(), but also to getsockopt(SO_ACCEPTCONN). Notes: svn path=/head/; revision=323015
* Sync CloudABI compatibility against the latest upstream version (v0.13).Ed Schouten2017-08-251-27/+7
| | | | | | | | | | | | | | | | | | | With Flower (CloudABI's network connection daemon) becoming more complete, there is no longer any need for creating any unconnected sockets. Socket pairs in combination with file descriptor passing is all that is necessary, as that is what is used by Flower to pass network connections from the public internet to listening processes. Remove all of the kernel bits that were used to implement socket(), listen(), bindat() and connectat(). In principle, accept() and SO_ACCEPTCONN may also be removed, but there are still some consumers left. Obtained from: https://github.com/NuxiNL/cloudabi MFC after: 1 month Notes: svn path=/head/; revision=322885
* Upgrade to the latest sources generated from the CloudABI specification.Ed Schouten2017-07-261-34/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The CloudABI specification has had some minor changes over the last half year. No substantial features have been added, but some features that are deemed unnecessary in retrospect have been removed: - mlock()/munlock(): These calls tend to be used for two different purposes: real-time support and handling of sensitive (cryptographic) material that shouldn't end up in swap. The former use case is out of scope for CloudABI. The latter may also be handled by encrypting swap. Removing this has the advantage that we no longer need to worry about having resource limits put in place. - SOCK_SEQPACKET: Support for SOCK_SEQPACKET is rather inconsistent across various operating systems. Some operating systems supported by CloudABI (e.g., macOS) don't support it at all. Considering that they are rarely used, remove support for the time being. - getsockname(), getpeername(), etc.: A shortcoming of the sockets API is that it doesn't allow you to create socket(pair)s, having fake socket addresses associated with them. This makes it harder to test applications or transparently forward (proxy) connections to them. With CloudABI, we're slowly moving networking connectivity into a separate daemon called Flower. In addition to passing around socket file descriptors, this daemon provides address information in the form of arbitrary string labels. There is thus no longer any need for requesting socket address information from the kernel itself. This change also updates consumers of the generated code accordingly. Even though system calls end up getting renumbered, this won't cause any problems in practice. CloudABI programs always call into the kernel through a kernel-supplied vDSO that has the numbers updated as well. Obtained from: https://github.com/NuxiNL/cloudabi Notes: svn path=/head/; revision=321514
* Rewrite the vDSOs for CloudABI in assembly.Ed Schouten2016-08-211-0/+511
The reason why the old vDSOs were written in C using inline assembly was purely because they were embedded in the C library directly as static inline functions. This was practical during development, because it meant you could invoke system calls without any library dependencies. The vDSO was simply a copy of these functions. Now that we require the use of the vDSO, there is no longer any need for embedding them in C code directly. Rewriting them in assembly has the advantage that they are closer to ideal (less useless branching, less assumptions about registers remaining unclobbered by the kernel, etc). They are also easier to build, as they no longer depend on the C type information for CloudABI. Obtained from: https://github.com/NuxiNL/cloudabi Notes: svn path=/head/; revision=304554