#
303975 |
|
11-Aug-2016 |
gjb |
Copy stable/11@r303970 to releng/11.0 as part of the 11.0-RELEASE cycle.
Prune svn:mergeinfo from the new branch, and rename it to RC1.
Update __FreeBSD_version.
Use the quarterly branch for the default FreeBSD.conf pkg(8) repo and the dvd1.iso packages population.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
302408 |
|
08-Jul-2016 |
gjb |
Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle. Prune svn:mergeinfo from the new branch, as nothing has been merged here.
Additional commits post-branch will follow.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
#
297613 |
|
06-Apr-2016 |
ed |
Make CloudABI's way of doing TLS more friendly to userspace emulators.
We're currently seeing how hard it would be to run CloudABI binaries on operating systems cannot be modified easily (Windows, Mac OS X). The idea is that we want to just run them without any sandboxing. Now that CloudABI executables are PIE, this is already a bit easier, but TLS is still problematic:
- CloudABI executables want to write to the %fs, which typically requires extra system calls by the emulator every time it needs to switch between CloudABI's and its own TLS.
- If CloudABI executables overwrite the %fs base unconditionally, it also becomes harder for the emulator to store a backup of the old value of %fs. To solve this, let's no longer overwrite %fs, but just %fs:0.
As CloudABI's C library does not use a TCB, this space can now be used by an emulator to keep track of its internal state. The executable can now safely overwrite %fs:0, as long as it makes sure that the TCB is copied over to the new TLS area.
Ensure that there is an initial TLS area set up when the process starts, only containing a bogus TCB. We don't really care about its contents on FreeBSD.
Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D5836
|
#
297468 |
|
31-Mar-2016 |
ed |
Sync in the latest CloudABI system call definitions.
Some time ago I made a change to merge together the memory scope definitions used by mmap (MAP_{PRIVATE,SHARED}) and lock objects (PTHREAD_PROCESS_{PRIVATE,SHARED}). Though that sounded pretty smart back then, it's backfiring. In the case of mmap it's used with other flags in a bitmask, but for locking it's an enumeration. As our plan is to automatically generate bindings for other languages, that looks a bit sloppy.
Change all of the locking functions to use separate flags instead.
Obtained from: https://github.com/NuxiNL/cloudabi
|
#
297247 |
|
24-Mar-2016 |
ed |
Replace the CloudABI system call table by a machine generated version.
The type definitions and constants that were used by COMPAT_CLOUDABI64 are a literal copy of some headers stored inside of CloudABI's C library, cloudlibc. What is annoying is that we can't make use of cloudlibc's system call list, as the format is completely different and doesn't provide enough information. It had to be synced in manually.
We recently decided to solve this (and some other problems) by moving the ABI definitions into a separate file:
https://github.com/NuxiNL/cloudabi/blob/master/cloudabi.txt
This file is processed by a pile of Python scripts to generate the header files like before, documentation (markdown), but in our case more importantly: a FreeBSD system call table.
This change discards the old files in sys/contrib/cloudabi and replaces them by the latest copies, which requires some minor changes here and there. Because cloudabi.txt also enforces consistent names of the system call arguments, we have to patch up a small number of system call implementations to use the new argument names.
The new header files can also be included directly in FreeBSD kernel space without needing any includes/defines, so we can now remove cloudabi_syscalldefs.h and cloudabi64_syscalldefs.h. Patch up the sources to include the definitions directly from sys/contrib/cloudabi instead.
|