]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit
Upgrade to the latest sources generated from the CloudABI specification.
authored <ed@FreeBSD.org>
Wed, 26 Jul 2017 06:57:15 +0000 (06:57 +0000)
committered <ed@FreeBSD.org>
Wed, 26 Jul 2017 06:57:15 +0000 (06:57 +0000)
commitfeffd686029c113ca4a4d0d85eaa1dd013bab509
tree2d65cbb326a7946d952095aaabef8ce4a077fe98
parent819a09c0c9bac3ad53001cc9ffafb92b3a5659d9
Upgrade to the latest sources generated from the CloudABI specification.

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
27 files changed:
sys/compat/cloudabi/cloudabi_fd.c
sys/compat/cloudabi/cloudabi_mem.c
sys/compat/cloudabi/cloudabi_sock.c
sys/compat/cloudabi/cloudabi_util.h
sys/compat/cloudabi32/cloudabi32_proto.h
sys/compat/cloudabi32/cloudabi32_sock.c
sys/compat/cloudabi32/cloudabi32_syscall.h
sys/compat/cloudabi32/cloudabi32_syscalls.c
sys/compat/cloudabi32/cloudabi32_sysent.c
sys/compat/cloudabi32/cloudabi32_systrace_args.c
sys/compat/cloudabi64/cloudabi64_proto.h
sys/compat/cloudabi64/cloudabi64_sock.c
sys/compat/cloudabi64/cloudabi64_syscall.h
sys/compat/cloudabi64/cloudabi64_syscalls.c
sys/compat/cloudabi64/cloudabi64_sysent.c
sys/compat/cloudabi64/cloudabi64_systrace_args.c
sys/contrib/cloudabi/cloudabi32_types.h
sys/contrib/cloudabi/cloudabi64_types.h
sys/contrib/cloudabi/cloudabi_types_common.h
sys/contrib/cloudabi/cloudabi_vdso_aarch64.S
sys/contrib/cloudabi/cloudabi_vdso_armv6.S
sys/contrib/cloudabi/cloudabi_vdso_i686.S
sys/contrib/cloudabi/cloudabi_vdso_i686_on_64bit.S
sys/contrib/cloudabi/cloudabi_vdso_x86_64.S
sys/contrib/cloudabi/syscalls32.master
sys/contrib/cloudabi/syscalls64.master
usr.bin/truss/syscalls.c