These overlap a bit and will be refined as they develop, so bear with us :).

ZIP, bitcode, human-readable metadata, etc.

We provide new tools to operate on the format, but the format is designed to be easily created, inspected, and consumed for the cases our tools don't cover.

This is important for our own sanity, but also to ease adoption and construction of tools interacting with the format. More fundamentally, it is important to reuse good techniques when they exist, e.g., compression, archiving, file search, etc.

Software in this format is captured in sufficient completeness that it may be executed by the ALLVM Execution Engine without additional code components. We also encourage the inclusion of key resources necessary for execution, such as configuration files.

This has important implications regarding dynamically linked libraries: all the libraries used by an application must be included, directly or indirectly. For ease of generation, updating, and analysis modularity, and also to keep executable sizes reasonably small, we encourage shipping these as separate ALLVM format files, with linking deferred until run-time.

In order to facilitate analysis and transformations across software boundaries (as well as after shipping), all code in a system must be provided in virtual instruction set format. In particular, code traditionally shipped as native machine code must be in LLVM bitcode format.

For now this means code using assembly for any reason is not allowed, including the use of inline assembly as well as standalone assembly files.

This is likely too strict a requirement for all uses, and mechanisms for handling those will be provided in later versions of the format.

THIS GOAL IS UNCLEAR AND VAGUELY STATED: MAKE THIS CONCRETE.

(As much as possible!) Software requiring this is encouraged to evalute if it really needs the flexibility, and if so may elect to indicate this need with a flag.

While security is not a primary goal of the file format or core execution engine, ALLVM systems should enable the implemenation of secure systems enforcing higher-level security policies. Moreover, to enable and encourage aggressive full-software analysis and transformations (such as partial evaluation and full-system optimization) the behavior of the software must be constrained to the extent possible.

How this is most naturally described for software is yet to be determined, but for now includes:

• not being able to execute arbitrary code
• no self-modifying code
• JIT'd code must be generated by the ALLVM JIT or an "approved" language JIT, e.g., a JVM, .NET or other language implementation
• limited file system access
  • provided assets are available read-only
• All other data sources declared explicitly as input to the software

Packages and components within an ALLVM file are described using identifiers that uniquely describe their derivation tree. This is important for use in reproduction, caching, and reproducion-with-transform operations.

The purity model of these derivation trees is not yet determined, but for now it should be expected to be strong in theory, but in practice assume it's weak. AGAIN, THIS IS VAGUE AND NEEDS TO BE MADE CONCRETE.

Capture the majority of use cases with what's simplest; introduce complexities only if needed and to the minimal extent necessary.

The ALLVM format should enable sophisticated compiler analysis and transformations across arbitrary software boundaries, including application/library, application/OS, OS/device driver, and process/process. Some of these fundamentally must be done after shipping, but can be done offline, e.g., specialization of applications and the OS, or autotuning of a software stack, both of which can be done at install-time. Others are fundamentally dynamic, e.g., OS/device driver for dynamically loaded drivers, or process/process for the common case of distributed systems configured at startup time.

These fundamental constraints imply that the ALLVM file format must enable install-time, run-time, and potentially idle-time techniques to be applied across arbitrary system components. This directly motivates the need for all software to be available in IR form, stated above. It also motivates the need for ALLVM tools that can operate across arbitrary software boundaries.