MFC r348446:makesyscalls.sh: always use absolute path for syscalls.confsyscalls.conf is included using "." which per the Open Group: If file does not contain a <slash>, the shell shall use the
MFC r348446:makesyscalls.sh: always use absolute path for syscalls.confsyscalls.conf is included using "." which per the Open Group: If file does not contain a <slash>, the shell shall use the search path specified by PATH to find the directory containing file.POSIX shells don't fall back to the current working directory.Submitted by: Nathaniel Wesley Filardo <[email protected]>Reviewed by: bdrewerySponsored by: DARPA, AFRLDifferential Revision: https://reviews.freebsd.org/D20476
show more ...
Regenerated assorted syscall related files after: - r327895: Implement 'domainset'... - r329876: Use linux types for linux-specific syscallsDiff generated with: find . -name syscalls.conf | xarg
Regenerated assorted syscall related files after: - r327895: Implement 'domainset'... - r329876: Use linux types for linux-specific syscallsDiff generated with: find . -name syscalls.conf | xargs dirname | \ xargs -n1 -I DIR make -C DIR sysentApproved by: re (kib)Sponsored by: DARPA, AFRL
Don't use an .OBJDIR for 'make sysent'.Reported by: emaste, jhbSponsored by: Dell EMC
Use mallocarray(9) in CloudABI kernel code where possible.Submitted by: pfg@
Allow timed waits with relative timeouts on locks and condvars.Even though pthreads doesn't support this, there are various alternativeAPIs that use this. For example, uv_cond_timedwait() accepts
Allow timed waits with relative timeouts on locks and condvars.Even though pthreads doesn't support this, there are various alternativeAPIs that use this. For example, uv_cond_timedwait() accepts a relativetimeout. So does Rust's std::sync::Condvar::wait_timeout().Though I personally think that relative timeouts are bad (due toimprecision for repeated operations), it does seem that people wantthis. Extend the existing futex functions to keep track of whether anabsolute timeout is used in a boolean flag.MFC after: 1 month
Upgrade to CloudABI v0.17.Compared to the previous version, v0.16, there are a couple of minorchanges:- CLOUDABI_AT_PID: Process identifiers for CloudABI processes. Initially, BSD process ide
Upgrade to CloudABI v0.17.Compared to the previous version, v0.16, there are a couple of minorchanges:- CLOUDABI_AT_PID: Process identifiers for CloudABI processes. Initially, BSD process identifiers weren't exposed inside the runtime, due to them being pretty much useless inside of a cluster computing environment. When jobs are scheduled across systems, the BSD process number doesn't act as an identifier. Even on individual systems they may recycle relatively quickly. With this change, the kernel will now generate a UUIDv4 when executing a process. These UUIDs can be obtained within the process using program_getpid(). Right now, FreeBSD will not attempt to store this value. This should of course happen at some point in time, so that it may be printed by administration tools.- Removal of some unused structure members for polling. With the polling framework being simplified/redesigned, it turns out some of the structure fields were not used by the C library. We can remove these to keep things nice and tidy.Obtained from: https://github.com/NuxiNL/cloudabi
Import the latest CloudABI definitions, version 0.16.The most important change in this release is the removal of thepoll_fd() system call; CloudABI's equivalent of kevent(). Though I thinkthat kq
Import the latest CloudABI definitions, version 0.16.The most important change in this release is the removal of thepoll_fd() system call; CloudABI's equivalent of kevent(). Though I thinkthat kqueue is a lot saner than many of its alternatives, ourexperience is that emulating this system call on other systemsaccurately isn't easy. It has become a complex API, even though I'm notconvinced this complexity is needed. This is why we've decided to take adifferent approach, by looking one layer up.We're currently adding an event loop to CloudABI's C library that is APIcompatible with libuv (except when incompatible with Capsicum).Initially, this event loop will be built on top of plain inefficientpoll() calls. Only after this is finished, we'll work our way backwardsand design a new set of system calls to optimize it.Interesting challenges will include integrating asynchronous I/O intosuch a system call API. libuv currently doesn't aio(4) on Linux/BSD, dueto it being unreliable and having undesired semantics.Obtained from: https://github.com/NuxiNL/cloudabi
Complete the CloudABI networking refactoring.Now that all of the packaged software has been adjusted to either useFlower (https://github.com/NuxiNL/flower) for making incoming/outgoingnetwork con
Complete the CloudABI networking refactoring.Now that all of the packaged software has been adjusted to either useFlower (https://github.com/NuxiNL/flower) for making incoming/outgoingnetwork connections or can have connections injected, there is no longerneed to keep accept() around. It is now a lot easier to write networkedservices that are address family independent, dual-stack, testable, etc.Remove all of the bits related to accept(), but also togetsockopt(SO_ACCEPTCONN).
Sync CloudABI compatibility against the latest upstream version (v0.13).With Flower (CloudABI's network connection daemon) becoming morecomplete, there is no longer any need for creating any uncon
Sync CloudABI compatibility against the latest upstream version (v0.13).With Flower (CloudABI's network connection daemon) becoming morecomplete, there is no longer any need for creating any unconnectedsockets. Socket pairs in combination with file descriptor passing is allthat is necessary, as that is what is used by Flower to pass networkconnections 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() andSO_ACCEPTCONN may also be removed, but there are still some consumersleft.Obtained from: https://github.com/NuxiNL/cloudabiMFC after: 1 month
Upgrade to the latest sources generated from the CloudABI specification.The CloudABI specification has had some minor changes over the last halfyear. No substantial features have been added, but s
Upgrade to the latest sources generated from the CloudABI specification.The CloudABI specification has had some minor changes over the last halfyear. No substantial features have been added, but some features thatare 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 anyproblems in practice. CloudABI programs always call into the kernelthrough a kernel-supplied vDSO that has the numbers updated as well.Obtained from: https://github.com/NuxiNL/cloudabi
Make file descriptor passing for CloudABI's recvmsg() work.Similar to the change for sendmsg(), create a pointer size independentimplementation of recvmsg() and let cloudabi32 and cloudabi64 call
Make file descriptor passing for CloudABI's recvmsg() work.Similar to the change for sendmsg(), create a pointer size independentimplementation of recvmsg() and let cloudabi32 and cloudabi64 call intoit. In case userspace requests one or more file descriptors, callkern_recvit() in such a way that we get the control message headers inan mbuf. Iterate over all of the headers and copy the file descriptorsto userspace.
Make file descriptor passing work for CloudABI's sendmsg().Reduce the potential amount of code duplication between cloudabi32 andcloudabi64 by creating a cloudabi_sock_recv() utility function. The
Make file descriptor passing work for CloudABI's sendmsg().Reduce the potential amount of code duplication between cloudabi32 andcloudabi64 by creating a cloudabi_sock_recv() utility function. Thecloudabi32 and cloudabi64 modules will then only contain code to convertthe iovecs to the native pointer size.In cloudabi_sock_recv(), we can now construct an SCM_RIGHTS cmsghdr inan mbuf and pass that on to kern_sendit().
Regenerate all the system call tables to drop "created from" lines.One of the ibcs2 files contains some actual changes (new headers) asit hasn't been regenerated after older changes to makesyscall
Regenerate all the system call tables to drop "created from" lines.One of the ibcs2 files contains some actual changes (new headers) asit hasn't been regenerated after older changes to makesyscalls.sh.
Catch up with changes to structure member names.Pointer/length pairs are now always named ${name} and ${name}_len.
Regenerate sources based on the system call tables.
Regenerate syscall provider argument strings.
Add source files generated from the 32-bit system call table.
Add CPU independent code for running 32-bits CloudABI executables.Essentially, this is a literal copy of the code in sys/compat/cloudabi64,except that it now makes use of 32-bits datatypes and lim
Add CPU independent code for running 32-bits CloudABI executables.Essentially, this is a literal copy of the code in sys/compat/cloudabi64,except that it now makes use of 32-bits datatypes and limits. Insys/conf/files, we now need to take care to build the code insys/compat/cloudabi if either COMPAT_CLOUDABI32 or COMPAT_CLOUDABI64 isturned on.This change does not yet include any of the CPU dependent bits. Rightnow I have implementations for running i386 binaries both on i386 andx86-64, which I will send out for review separately.